ProHoster > Blogs > Administrācija > Izplatīts riteņpāru reģistrs: pieredze ar Hyperledger audumu

Izplatīts riteņpāru reģistrs: pieredze ar Hyperledger audumu

Labdien, strādāju DRD KP projekta komandā (izplatÄ«ts datu reÄ£istrs riteņu komplektu dzÄ«ves cikla uzraudzÄ«bai). Å eit es vēlos dalÄ«ties mÅ«su komandas pieredzē, izstrādājot uzņēmuma blokķēdi Å”im projektam tehnoloÄ£iju ierobežojumu apstākļos. Es galvenokārt runāŔu par Hyperledger Fabric, taču Å”eit aprakstÄ«to pieeju var ekstrapolēt uz jebkuru atļautu blokķēdi. MÅ«su pētÄ«juma galvenais mērÄ·is ir sagatavot uzņēmuma blokķēdes risinājumus tā, lai galaprodukts bÅ«tu patÄ«kami lietojams un to nebÅ«tu pārāk grÅ«ti uzturēt.

Å eit nebÅ«s atklājumu, negaidÄ«tu risinājumu un netiks izcelti unikāli notikumi (jo man tādu nav). Es tikai vēlos padalÄ«ties ar savu pieticÄ«go pieredzi, parādÄ«t, ka ā€œtas bija iespējamsā€ un, iespējams, komentāros palasÄ«t par citu cilvēku pieredzi, pieņemot labus un ne tik labus lēmumus.

Problēma: blokķēdes vēl netiek mērogotas

MÅ«sdienās daudzu izstrādātāju centieni ir vērsti uz to, lai blokķēde kļūtu par patiesi ērtu tehnoloÄ£iju, nevis par bumbu ar laika degli skaistā iesaiņojumā. Stāvokļa kanāli, optimistisks apkopojums, plazma un sadalÄ«Å”ana, iespējams, kļūs par ikdienu. Kādu dienu. Vai varbÅ«t TON atkal atliks palaiÅ”anu uz seÅ”iem mēneÅ”iem, un nākamā plazmas grupa beigs pastāvēt. Mēs varam ticēt nākamajam ceļvedim un naktÄ« lasÄ«t izcilas baltās grāmatas, bet Å”eit un tagad mums kaut kas jādara ar to, kas mums ir. Padari sÅ«dus.

MÅ«su komandai izvirzÄ«tais uzdevums paÅ”reizējā projektā kopumā izskatās Ŕādi: ir daudz subjektu, kas sasniedz vairākus tÅ«kstoÅ”us, kuri nevēlas veidot attiecÄ«bas uz uzticÄ«bas pamata; Ir nepiecieÅ”ams izveidot DLT risinājumu, kas darbosies uz parastajiem personālajiem datoriem bez Ä«paŔām veiktspējas prasÄ«bām un nodroÅ”inās lietotāja pieredzi, kas nav sliktāka par jebkuru centralizētu grāmatvedÄ«bas sistēmu. Risinājuma pamatā esoÅ”ajai tehnoloÄ£ijai ir jāsamazina iespēja ļaunprātÄ«gi manipulēt ar datiem ā€“ tāpēc blokķēde ir Å”eit.

Saukļi no baltajām grāmatām un plaÅ”saziņas lÄ«dzekļiem mums sola, ka nākamā attÄ«stÄ«ba ļaus mums veikt miljoniem darÄ«jumu sekundē. Kas tas Ä«sti ir?

Mainnet Ethereum paÅ”laik darbojas ar ~30 tps. Å Ä« iemesla dēļ vien ir grÅ«ti uztvert to kā blokķēdi, kas jebkādā veidā ir piemērota korporatÄ«vajām vajadzÄ«bām. Starp atļautajiem risinājumiem ir etaloni, kas rāda 2000 tps (Kvorums) vai 3000 tps (Hyperledger audums, publikācijā ir nedaudz mazāk, taču jāņem vērā, ka etalons tika veikts ar veco konsensa dzinēju). Bija radikālas auduma apstrādes mēģinājums, kas deva ne tos sliktākos rezultātus, 20000 XNUMX tps, bet pagaidām tas ir tikai akadēmisks pētÄ«jums, kas gaida savu stabilu realizāciju. Maz ticams, ka korporācija, kas var atļauties uzturēt blokķēdes izstrādātāju nodaļu, samierināsies ar Ŕādiem rādÄ«tājiem. Bet problēma ir ne tikai caurlaidspēja, bet arÄ« latentums.

Latentums

Aizkave no darÄ«juma uzsākÅ”anas brīža lÄ«dz tās galÄ«gajai apstiprināŔanai sistēmā ir atkarÄ«ga ne tikai no ātruma, kādā ziņojums iziet cauri visiem validācijas un pasÅ«tÄ«Å”anas posmiem, bet arÄ« no bloka veidoÅ”anas parametriem. Pat ja mÅ«su blokķēde ļauj mums veikt saistÄ«bas ar ātrumu 1000000 10 488 tps, bet prasa XNUMX minÅ«tes, lai Ä£enerētu XNUMX MB bloku, vai mums tas kļūs vieglāk?

SÄ«kāk apskatÄ«sim darÄ«jumu dzÄ«ves ciklu programmā Hyperledger Fabric, lai saprastu, kur tiek pavadÄ«ts laiks un kā tas ir saistÄ«ts ar bloku Ä£enerÄ“Å”anas parametriem.

Izplatīts riteņpāru reģistrs: pieredze ar Hyperledger audumu
ņemts no Å”ejienes: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

(1) Klients izveido transakciju, nosÅ«ta to apstiprinoÅ”ajiem partneriem, pēdējie simulē darÄ«jumu (piemēro ķēdes koda veiktās izmaiņas paÅ”reizējam stāvoklim, bet neuzņemas saistÄ«bas virsgrāmatā) un saņem RWSet - atslēgu nosaukumus, versijas un vērtÄ«bas ā€‹ā€‹Å†emts no kolekcijas CouchDB, (2) indoseri nosÅ«ta atpakaļ klientam parakstÄ«tu RWSet, (3) klients vai nu pārbauda visu nepiecieÅ”amo vienaudžu (endosoru) parakstu esamÄ«bu, un pēc tam nosÅ«ta darÄ«jumu pasÅ«tÄ«Å”anas dienestam. , vai nosÅ«ta to bez verifikācijas (pārbaude joprojām notiks vēlāk), pasÅ«tÄ«Å”anas pakalpojums veido bloku un (4) nosÅ«ta atpakaļ visiem vienaudžiem, ne tikai apstiprinātājiem; vienaudži pārbauda, ā€‹ā€‹vai lasÄ«Å”anas komplekta atslēgu versijas atbilst versijām datu bāzē, vai visiem atbalstÄ«tājiem ir paraksti, un visbeidzot veic bloku.

Bet tas vēl nav viss. Vārdi ā€œpasÅ«tÄ«tājs veido blokuā€ slēpj ne tikai transakciju secÄ«bu, bet arÄ« 3 secÄ«gus tÄ«kla pieprasÄ«jumus no lÄ«dera sekotājiem un atpakaļ: vadÄ«tājs pievieno ziņojumu žurnālam, nosÅ«ta to sekotājiem, pēdējais pievieno. uz viņu žurnālu, nosÅ«ta vadÄ«tājam apstiprinājumu par veiksmÄ«gu replikāciju, vadÄ«tājs apstiprina ziņojumu, nosÅ«ta apstiprinājumu sekotājiem, sekotāji apņemas. Jo mazāks ir bloka lielums un izveides laiks, jo biežāk pasÅ«tÄ«Å”anas dienestam bÅ«s jāpanāk vienprātÄ«ba. Hyperledger Fabric bloku veidoÅ”anai ir divi parametri: BatchTimeout ā€” bloka veidoÅ”anas laiks un BatchSize ā€” bloka lielums (transakciju skaits un paÅ”a bloka lielums baitos). TiklÄ«dz kāds no parametriem sasniedz limitu, tiek atbrÄ«vots jauns bloks. Jo vairāk pasÅ«tÄ«juma mezglu, jo ilgāks laiks bÅ«s nepiecieÅ”ams. Tāpēc jums ir jāpalielina BatchTimeout un BatchSize. Bet, tā kā RWSets ir versijas, jo lielāku bloku veidojam, jo ā€‹ā€‹lielāka ir MVCC konfliktu iespējamÄ«ba. Turklāt, palielinoties BatchTimeout, UX katastrofāli pasliktinās. SekojoŔā shēma Å”o problēmu risināŔanai man Ŕķiet saprātÄ«ga un paÅ”saprotama.

Kā izvairÄ«ties no bloka pabeigÅ”anas gaidÄ«Å”anas un nezaudēt iespēju izsekot darÄ«juma statusam

Jo ilgāks veidoÅ”anās laiks un bloka izmērs, jo lielāka ir blokķēdes caurlaidspēja. Viens no otra tieÅ”i neizriet, taču jāatceras, ka, lai panāktu vienprātÄ«bu RAFT, ir nepiecieÅ”ami trÄ«s tÄ«kla pieprasÄ«jumi no vadÄ«tāja lÄ«dz sekotājiem un atpakaļ. Jo vairāk pasÅ«tÄ«juma mezglu, jo ilgāks laiks bÅ«s nepiecieÅ”ams. Jo mazāks ir bloka veidoÅ”anās lielums un laiks, jo vairāk ir Ŕādas mijiedarbÄ«bas. Kā palielināt Ä£enerÄ“Å”anas laiku un bloka izmēru, nepalielinot sistēmas reakcijas laiku gala lietotājam?

Pirmkārt, mums ir kaut kā jāatrisina MVCC konflikti, ko izraisa liels bloka izmērs, kas var ietvert dažādus RWSets ar vienu un to paÅ”u versiju. AcÄ«mredzot klienta pusē (attiecÄ«bā uz blokķēdes tÄ«klu tas varētu bÅ«t aizmugursistēma, un es to domāju) jums ir nepiecieÅ”ams MVCC konfliktu apstrādātājs, kas var bÅ«t vai nu atseviŔķs pakalpojums, vai parasts dekorators virs zvana, kas iniciē darÄ«jumu ar atkārtoÅ”anas loÄ£iku.

Atkārtot mēģinājumu var īstenot ar eksponenciālu stratēģiju, taču tad latentums samazināsies tikpat eksponenciāli. Tāpēc jums vajadzētu izmantot vai nu randomizētu atkārtotu mēģinājumu noteiktos nelielos limitos, vai arī pastāvīgu mēģinājumu. Ar aci uz iespējamām sadursmēm pirmajā variantā.

Nākamais solis ir padarÄ«t klienta mijiedarbÄ«bu ar sistēmu asinhronu, lai tā negaidÄ«tu 15, 30 vai 10000000 sekundes, kuras mēs iestatÄ«sim kā BatchTimeout. Bet tajā paŔā laikā ir jāsaglabā iespēja pārbaudÄ«t, vai darÄ«juma iniciētās izmaiņas tiek/nav ierakstÄ«tas blokķēdē.
DarÄ«juma statusa saglabāŔanai var izmantot datu bāzi. VienkārŔākā iespēja ir CouchDB, pateicoties tās lietoÅ”anas vienkārŔībai: datu bāzei ir UI, REST API, un jÅ«s varat viegli iestatÄ«t tās replikāciju un sadalÄ«Å”anu. Varat vienkārÅ”i izveidot atseviŔķu kolekciju tajā paŔā CouchDB instancē, kas izmanto Fabric, lai saglabātu savu pasaules stāvokli. Mums ir jāsaglabā Ŕāda veida dokumenti.

{
 Status string // Š”тŠ°Ń‚ŃƒŃ трŠ°Š½Š·Š°ŠŗцŠøŠø: "pending", "done", "failed"
 TxID: string // ID трŠ°Š½Š·Š°ŠŗцŠøŠø
 Error: string // optional, сŠ¾Š¾Š±Ń‰ŠµŠ½ŠøŠµ Š¾Š± Š¾ŃˆŠøŠ±ŠŗŠµ
}

Å is dokuments tiek ierakstÄ«ts datu bāzē pirms darÄ«juma nosÅ«tÄ«Å”anas vienaudžiem, entÄ«tijas ID tiek atgriezts lietotājam (tas pats ID tiek izmantots kā atslēga), ja tā ir izveides darbÄ«ba, un pēc tam tiek parādÄ«ti lauki Statuss, TxID un Error. atjaunināta, tiklÄ«dz no vienaudžiem tiek saņemta atbilstoÅ”a informācija.

Izplatīts riteņpāru reģistrs: pieredze ar Hyperledger audumu

Å ajā shēmā lietotājs negaida, lÄ«dz beidzot izveidosies bloks, 10 sekundes vērojot ekrānā griežamo riteni, viņŔ saņem tÅ«lÄ«tēju atbildi no sistēmas un turpina strādāt.

Mēs izvēlējāmies BoltDB, lai saglabātu darÄ«jumu statusus, jo mums ir nepiecieÅ”ams ietaupÄ«t atmiņu un nevēlamies tērēt laiku tÄ«kla mijiedarbÄ«bai ar atseviŔķu datu bāzes serveri, it Ä«paÅ”i, ja Ŕī mijiedarbÄ«ba notiek, izmantojot vienkārÅ”a teksta protokolu. Starp citu, neatkarÄ«gi no tā, vai izmantojat CouchDB, lai ieviestu iepriekÅ” aprakstÄ«to shēmu vai vienkārÅ”i saglabātu pasaules stāvokli, jebkurā gadÄ«jumā ir lietderÄ«gi optimizēt veidu, kā dati tiek glabāti CouchDB. Pēc noklusējuma CouchDB b-koka mezglu izmērs ir 1279 baiti, kas ir daudz mazāks par diska sektora izmēru, kas nozÄ«mē, ka gan koka lasÄ«Å”anai, gan lÄ«dzsvaroÅ”anai bÅ«s nepiecieÅ”ama lielāka fiziska piekļuve diskam. Optimālais izmērs atbilst standartam Izvērstais formāts un ir 4 kilobaiti. Lai optimizētu, mums ir jāiestata parametrs btree_chunk_size ir vienāds ar 4096 CouchDB konfigurācijas failā. BoltDB Ŕāda manuāla iejaukÅ”anās Tas neprasa.

Pretspiediens: bufera stratēģija

Taču ziņojumu var bÅ«t daudz. Vairāk, nekā sistēma spēj, koplietot resursus ar duci citu pakalpojumu, izņemot diagrammā redzamos, un tam visam vajadzētu darboties nevainojami pat iekārtās, kurās Intellij Idea palaiÅ”ana bÅ«tu ārkārtÄ«gi nogurdinoÅ”a.

Komunikācijas sistēmu, ražotāja un patērētāja, dažādu jaudu problēma tiek risināta dažādos veidos. Paskatīsimies, ko mēs varētu darīt.

NomeÅ”ana: Mēs varam apgalvot, ka spējam apstrādāt ne vairāk kā X darÄ«jumus T sekundēs. Visi pieprasÄ«jumi, kas pārsniedz Å”o ierobežojumu, tiek atmesti. Tas ir diezgan vienkārÅ”i, bet tad jÅ«s varat aizmirst par UX.

KontrolÄ“Å”ana: patērētājam ir jābÅ«t kaut kādai saskarnei, caur kuru atkarÄ«bā no slodzes viņŔ var kontrolēt ražotāja TPS. Nav slikti, bet tas uzliek pienākumu klienta izstrādātājiem, kas veido slodzi, lai ieviestu Å”o saskarni. Tas mums ir nepieņemami, jo blokķēde nākotnē tiks integrēta daudzās jau sen pastāvoŔās sistēmās.

BuferÄ“Å”ana: Tā vietā, lai mēģinātu pretoties ievades datu straumei, mēs varam buferēt Å”o straumi un apstrādāt to vajadzÄ«gajā ātrumā. AcÄ«mredzot tas ir labākais risinājums, ja vēlamies nodroÅ”ināt labu lietotāja pieredzi. Mēs ieviesām buferi, izmantojot rindu RabbitMQ.

Izplatīts riteņpāru reģistrs: pieredze ar Hyperledger audumu

Shēmai ir pievienotas divas jaunas darbÄ«bas: (1) pēc API pieprasÄ«juma saņemÅ”anas rindā tiek ievietots ziņojums ar transakcijas izsaukÅ”anai nepiecieÅ”amajiem parametriem, un klients saņem ziņojumu, ka darÄ«jums ir pieņemts sistēma, (2) aizmugursistēma nolasa datus ar ātrumu, kas norādÄ«ts konfigurācijā no rindas; uzsāk darÄ«jumu un atjaunina datus statusa krātuvē.
Tagad jÅ«s varat palielināt veidoÅ”anas laiku un bloķēt jaudu, cik vien vēlaties, slēpjot aizkavÄ“Å”anos no lietotāja.

Citi instrumenti

Å eit nekas netika teikts par ķēdes kodu, jo, kā likums, tajā nav ko optimizēt. Ķēdes kodam jābÅ«t pēc iespējas vienkārŔākam un droŔākam ā€” tas ir viss, kas no tā tiek prasÄ«ts. Ietvars palÄ«dz mums vienkārÅ”i un droÅ”i rakstÄ«t ķēdes kodu CCKit no S7 Techlab un statiskā analizatora atdzÄ«vināt^CC.

Turklāt mÅ«su komanda izstrādā utilÄ«tu komplektu, lai padarÄ«tu darbu ar Fabric vienkārÅ”u un patÄ«kamu: blokķēdes pētnieks, lietderÄ«ba priekÅ” automātiskas tÄ«kla konfigurācijas izmaiņas (organizāciju pievienoÅ”ana/noņemÅ”ana, RAFT mezgli), utilÄ«ta sertifikātu atsaukÅ”ana un identitātes noņemÅ”ana. Ja vēlaties dot savu ieguldÄ«jumu, laipni lÅ«dzam.

Secinājums

Å Ä« pieeja ļauj viegli nomainÄ«t Hyperledger Fabric ar Quorum, citiem privātajiem Ethereum tÄ«kliem (PoA vai pat PoW), ievērojami samazināt faktisko caurlaidspēju, bet tajā paŔā laikā uzturēt normālu UX (gan pārlÅ«kprogrammas lietotājiem, gan integrētajām sistēmām). Aizstājot Fabric ar Ethereum shēmā, jums bÅ«s jāmaina tikai atkārtota mēģinājuma pakalpojuma/dekoratora loÄ£ika no MVCC konfliktu apstrādes uz atomieroču palielināŔanu un atkārtotu nosÅ«tÄ«Å”anu. Buferizācija un statusa glabāŔana ļāva atsaistÄ«t reakcijas laiku no bloka veidoÅ”anas laika. Tagad jÅ«s varat pievienot tÅ«kstoÅ”iem pasÅ«tÄ«juma mezglu un nebaidÄ«ties, ka bloki tiek veidoti pārāk bieži un ielādēt pasÅ«tÄ«Å”anas pakalpojumu.

BÅ«tÄ«bā tas ir viss, ar ko es gribēju dalÄ«ties. PriecāŔos, ja tas kādam palÄ«dzēs darbā.

Avots: www.habr.com

Pievieno komentāru