В azken artikulua RabbitMQ clustering-a aztertu dugu akatsen tolerantzia eta erabilgarritasun handia lortzeko. Orain sakon dezagun Apache Kafkan.

Hemen erreplikazio-unitatea partizioa da. Gai bakoitzak atal bat edo gehiago ditu. Atal bakoitzak lider bat dauka jarraitzaileekin edo jarraitzailerik gabe. Gai bat sortzean, partizio-kopurua eta erreplikazio-koefizientea zehazten dituzu. Ohiko balioa 3 da, hau da, hiru erreplika esan nahi du: lider bat eta bi jarraitzaile.

Arroza. 1. Lau atal hiru artekarien artean banatzen dira

Irakurtzeko eta idazteko eskaera guztiak liderra doaz. Jarraitzaileek aldian-aldian eskaerak bidaltzen dizkiote liderrari azken mezuak jasotzeko. Kontsumitzaileak ez dira inoiz jarraitzaileengana jotzen; azken hauek erredundantziarako eta akatsen tolerantziarako soilik existitzen dira.

Banaketa huts egitea

Broker batek huts egiten duenean, hainbat ataletako buruzagiek askotan huts egiten dute. Horietako bakoitzean, beste nodo bateko jarraitzaile bat bihurtzen da lider. Izan ere, ez da beti horrela gertatzen, sinkronizazio faktoreak ere eragiten baitu: jarraitzaile sinkronizatuak dauden ala ez, eta ez bada, sinkronizatu gabeko erreplika batera aldatzea onartzen den. Baina ez ditzagun gauzak zaildu oraingoz.

3. artekariak sarea uzten du, eta 2. ataleko buruzagi berri bat hautatzen da 2. artekarian.

Arroza. 2. 3. artekaria hil egiten da eta 2. artekariko bere jarraitzailea 2. partizioaren buruzagi berri gisa hautatzen da.

Orduan 1. artekariak uzten du eta 1. atalak liderra ere galtzen du, zeinaren rola 2. artekariari pasatzen zaio.

Arroza. 3. Broker bat geratzen da. Lider guztiak broker batean daude zero erredundantziarekin

Broker 1 sarera itzultzen denean, lau jarraitzaile gehitzen ditu, partizio bakoitzari erredundantzia pixka bat emanez. Baina buruzagi guztiak 2. artekarian jarraitzen zuten.

Arroza. 4. Liderrak 2. artekarian jarraitzen dute

Broker 3 agertzen denean, partizio bakoitzeko hiru errepliketara itzuliko gara. Baina lider guztiak broker 2an jarraitzen dute.

Arroza. 5. Liderrak kokatzea desorekatua 1 eta 3 artekariak zaharberritu ondoren

Kafkak RabbitMQ-k baino liderra hobeto orekatzeko tresna bat du. Bertan, nodo maisua migratzeko politikak aldatzen zituen hirugarrenen plugin edo script bat erabili behar izan duzu migrazioan zehar erredundantzia murriztuz. Gainera, ilara handietarako erabilgarritasunik eza onartu behar izan dugu sinkronizazioan.

Kafkak "erreplika hobetsien" kontzeptua du lider rolerako. Gai-partizioak sortzen direnean, Kafkak liderrak nodoetan uniformeki banatzen saiatzen da eta lehen lider horiek hobetsi bezala markatzen ditu. Denborarekin, zerbitzariaren berrabiarazi, hutsegite eta konektibitate-matxurengatik, liderrak beste nodo batzuetan amai daitezke, goian deskribatutako muturreko kasuan bezala.

Hau konpontzeko, Kafkak bi aukera eskaintzen ditu:

• Aukera auto.leader.rebalance.enable=egia kontroladore-nodoari liderrak automatikoki berriro esleitzeko aukera ematen dio gogoko errepliketara eta, ondorioz, banaketa uniformea ​​berreskuratzeko.
• Administratzaileak scripta exekutatu dezake kafka-preferred-replica-election.sh eskuzko biresleipenerako.

Arroza. 6. Erreplikak orekatu ondoren

Hau porrotaren bertsio sinplifikatu bat izan zen, baina errealitatea konplexuagoa da, nahiz eta hemen ez dagoen ezer konplikatuegirik. Guztia sinkronizatutako errepliketan datza (Sync Replicas, ISR).

Erreplika sinkronizatuak (ISR)

ISR bat "sinkronizatuta" (sinkronizatuta) kontsideratzen den partizio baten errepliken multzoa da. Lider bat dago, baina baliteke jarraitzailerik ez egotea. Jarraitzaile bat sinkronizatutzat joko da, baldin eta liderren mezu guztien kopia zehatzak egin baditu tartea iraungi baino lehen erreplika.lag.denbora.gehienez.ms.

Jarraitzaile bat ISR multzotik kentzen da:

• ez zuen tarterako aukeratzeko eskaerarik egin erreplika.lag.denbora.gehienez.ms (hilda ustez)
• tartean ez zen eguneratzea lortu erreplika.lag.denbora.gehienez.ms (moteltzat jotzen da)

Jarraitzaileek laginketa-eskaerak egiten dituzte tartean replica.fetch.wait.max.ms, 500 ms-koa lehenetsita.

ISRren helburua argi eta garbi azaltzeko, ekoizlearen baieztapenak eta hutsegite eszenatoki batzuk aztertu behar ditugu. Ekoizleek artekariak baieztapena noiz bidaltzen duen aukeratu dezakete:

• acks=0, berrespena ez da bidali
• acks=1, berrespena bidaltzen da liderrak mezu bat idatzi ondoren bere tokiko erregistroan
• acks=guztiak, berrespena bidaliko da ISRko erreplika guztiek mezua erregistro lokaletan idatzi ondoren

Kafkaren terminologian, ISRk mezu bat gorde badu, "konpromisoa" da. Acks=all aukerarik seguruena da, baina atzerapen gehigarria ere gehitzen du. Ikus ditzagun porrotaren bi adibide eta 'ack' aukera ezberdinek ISR kontzeptuarekin nola elkarreragiten duten.

Acks=1 eta ISR

Adibide honetan, ikusiko dugu liderrak ez badu jarraitzaile guztien mezu guztiak gorde arte itxaroten, orduan datuak galtzea posible dela liderrak huts egiten badu. Sinkronizatu gabeko jarraitzaile batera nabigatzea gaitu edo desgaitu daiteke ezarpenaren bidez zikin.lider.hauteskundea.gaitu.

Adibide honetan, fabrikatzaileak acks=1 balioa du. Atala hiru artekarien artean banatzen da. Broker 3 atzean dago, duela zortzi segundo liderrekin sinkronizatu zen eta orain 7456 mezu atzean dago. Broker 1 segundo bakarrera geratu zen. Gure ekoizleak mezu bat bidaltzen du eta azkar jasotzen du ack bat, liderrak itxaroten ez dituen jarraitzaile motel edo hildakoen gainkosturik gabe.

Arroza. 7. ISR hiru erreplikarekin

Broker 2 huts egiten du eta ekoizleak konexio-errore bat jasotzen du. Lidergoa 1. artekariari pasa ondoren, 123 mezu galtzen ditugu. 1. broker-eko jarraitzailea ISRren parte zen, baina ez zegoen liderrekin guztiz sinkronizatuta erori zenean.

Arroza. 8. Mezuak galtzen dira huts egiten denean

Konfigurazioan bootstrap.zerbitzariak Fabrikatzaileak hainbat artekari ditu zerrendatuta eta atalburu berria den beste broker bati galdetu diezaioke. Ondoren, 1. broker-arekin konexioa ezartzen du eta mezuak bidaltzen jarraitzen du.

Arroza. 9. Atsedenaldi labur baten ondoren mezuak bidaltzeari ekiten zaio berriro

Broker 3 are atzerago dago. Bertaratze-eskaerak egiten ditu baina ezin du sinkronizatu. Baliteke hori artekarien arteko sare-konexio motela izatea, biltegiratze-arazoa, etab. ISR-tik kentzen da. Orain ISR erreplika bakarraz osatuta dago: liderra! Fabrikatzaileak mezuak bidaltzen eta baieztapenak jasotzen jarraitzen du.

Arroza. 10. 3. artekariaren jarraitzailea ISRtik kentzen da

Broker 1 jaisten da eta lidergo rola broker 3 doa 15286 mezu galerarekin! Fabrikatzaileak konexio-errore mezu bat jasotzen du. ISRtik kanpo liderra igarotzea ezarpenagatik bakarrik posible izan zen unclean.leader.election.enable=egia. Bertan instalatuta badago false, orduan trantsizioa ez litzateke gertatuko eta irakurtzeko eta idazteko eskaera guztiak baztertuko lirateke. Kasu honetan, broker 1 erreplikan bere datu osoekin itzuliko den itxarongo dugu, lidergoa berriro hartuko duena.

Arroza. 11. Broker 1 erortzen da. Hutsegite bat gertatzen denean, mezu ugari galtzen dira

Ekoizleak azken artekariarekin lotura bat ezartzen du eta orain sekzioko liderra dela ikusten du. 3. agenteari mezuak bidaltzen hasten da.

Arroza. 12. Atsedenaldi labur baten ondoren, mezuak berriro bidaltzen dira 0 atalera

Ikusi genuen, konexio berriak ezartzeko eta lider berri bat bilatzeko etenaldi laburrez gain, fabrikatzaileak etengabe mezuak bidaltzen zituela. Konfigurazio honek erabilgarritasuna bermatzen du koherentziaren kaltetan (datuen segurtasuna). Kafkak milaka mezu galdu zituen baina idazketa berriak onartzen jarraitu zuen.

Acks=guztiak eta ISR

Errepikatu dezagun eszenatoki hau berriro, baina horrekin acks=guztiak. Broker 3k lau segundoko batez besteko latentzia du. Fabrikatzaileak mezu bat bidaltzen du acks=guztiak, eta orain ez du erantzun azkarrik jasotzen. Liderra ISRko erreplika guztiek mezua gordetzeko zain dago.

Arroza. 13. ISR hiru erreplikarekin. Bata motela da eta grabaketa atzerapenak eragiten ditu

Lau segundoko atzerapen gehigarriaren ondoren, 2. agenteak ack bat bidaltzen du. Erreplika guztiak guztiz eguneratuta daude orain.

Arroza. 14. Erreplika guztiek mezuak gordetzen dituzte eta ack bidali

Broker 3 orain atzerago geratzen da eta ISRtik kendu egiten da. Latentzia nabarmen murrizten da ISRn ez baitago erreplika geldorik geratzen. Broker 2 orain broker 1 bakarrik itxaroten du, eta batez beste 500 ms-ko atzerapena du.

Arroza. 15. 3. artekariaren erreplika ISR-tik kentzen da

Ondoren, 2. artekaria erortzen da eta lidergoa 1. artekarira pasatzen da mezurik galdu gabe.

Arroza. 16. Broker 2 erortzen da

Fabrikatzaileak lider berri bat aurkitzen du eta mezuak bidaltzen hasten da. Latentzia are gehiago murrizten da ISR-a erreplika bakarraz osatuta dagoelako! Beraz, aukera acks=guztiak ez du erredundantzia gehitzen.

Arroza. 17. 1. broker-en erreplika hartzen du lidergoa mezuak galdu gabe

Orduan 1. artekariak huts egiten du eta lidergoa 3. artekarira doa 14238 mezu galduta!

Arroza. 18. Broker 1 hiltzen da eta gidaritza-trantsizioak ezarpen garbiarekin datu-galera handia eragiten du

Ezin izan dugu aukera instalatu zikin.lider.hauteskundea.gaitu esanahian sartu Egia. Berez berdina da false. Ezarpenak acks=guztiak с unclean.leader.election.enable=egia irisgarritasuna eskaintzen du datuen segurtasun gehigarriarekin. Baina ikusten duzuenez, oraindik mezuak gal ditzakegu.

Baina zer gertatzen da datuen segurtasuna areagotu nahi badugu? Jar dezakezu unclean.leader.election.enable = faltsua, baina horrek ez gaitu nahitaez babestuko datuak galtzetik. Liderra gogor erori eta datuak berekin eramanez gero, mezuak galtzen dira oraindik, eta erabilgarritasuna galtzen da administratzaileak egoera berreskuratu arte.

Hobe da mezu guztiak erredundanteak direla ziurtatzea, eta, bestela, grabazioa baztertzea. Orduan, artekariaren ikuspuntutik bederen, aldi berean bi hutsegite edo gehiagoren kasuan soilik da posible datuak galtzea.

Acks=guztiak, min.insync.replicas eta ISR

Gaiaren konfigurazioarekin min.insync.erreplikak Datuen segurtasun maila handitzen ari gara. Goazen berriro aurreko eszenatokiaren azken zatia, baina oraingoan min.insync.replicas=2.

Beraz, 2. artekariak erreplika liderra du eta 3. artekariaren jarraitzailea ISRtik kentzen da.

Arroza. 19. ISR bi errepliketatik

Broker 2 erortzen da eta lidergoa 1 brokerra pasatzen da mezurik galdu gabe. Baina orain ISR erreplika bakarraz osatuta dago. Honek ez du betetzen erregistroak jasotzeko gutxieneko kopurua, eta, beraz, artekariak idazketa-saiakerari errore batekin erantzuten dio Not EnoughReplicas.

Arroza. 20. ISR kopurua min.insync.replicas-en zehaztutakoa baino bat txikiagoa da

Konfigurazio honek erabilgarritasuna sakrifikatzen du koherentziagatik. Mezu bat onartu aurretik, gutxienez bi errepliketan idatzita dagoela ziurtatzen dugu. Horrek fabrikatzaileari konfiantza handiagoa ematen dio. Hemen, mezua galtzea posible da bi erreplikek aldi berean huts egiten badute tarte laburrean mezua jarraitzaile gehigarri bati errepikatu arte, eta hori nekez da. Baina super paranoikoa bazara, erreplikazio-faktorea 5ean ezar dezakezu eta min.insync.erreplikak by 3. Hemen hiru artekariek aldi berean erori behar dute errekorra galtzeko! Noski, fidagarritasun hori latentzia gehigarrian ordaintzen duzu.

Datuen segurtasunerako irisgarritasuna beharrezkoa denean

In bezala RabbitMQ-rekin kasu, batzuetan irisgarritasuna beharrezkoa da datuen segurtasunerako. Hona hemen zer pentsatu behar duzun:

• Argitaratzaileak errore bat itzul dezake eta goranzko zerbitzua edo erabiltzailea geroago berriro saiatzea?
• Argitaletxeak gorde al dezake mezua lokalean edo datu-base batean geroago berriro saiatzeko?

Erantzuna ezezkoa bada, erabilgarritasuna optimizatzeak datuen segurtasuna hobetzen du. Datu gutxiago galduko dituzu grabatu ez beharrean erabilgarritasuna aukeratzen baduzu. Hala, oreka bilatzera dator dena, eta erabakia egoera zehatzaren araberakoa da.

ISRren esanahia

ISR suiteak datuen segurtasunaren eta latentziaren arteko oreka optimoa aukeratzeko aukera ematen du. Esate baterako, bermatu erabilgarritasuna erreplikaren gehiengoaren hutsegiteen kasuan, hildako edo motelen errepliken eragina gutxituz latentziari dagokionez.

Esanahia geuk aukeratzen dugu erreplika.lag.denbora.gehienez.ms zure beharren arabera. Funtsean, parametro honek esan nahi du zenbat atzerapena noiz onartzeko prest gauden acks=guztiak. Balio lehenetsia hamar segundo da. Hau luzeegia bada, murriztu dezakezu. Orduan, ISRn aldaketen maiztasuna handituko da, jarraitzaileak kendu eta sarriago gehituko baitira.

RabbitMQ errepikatu behar den ispilu multzo bat besterik ez da. Ispilu geldoek latentzia gehigarria sartzen dute, eta hildako ispiluek nodo bakoitzaren erabilgarritasuna egiaztatzen duten paketeek (tick garbia) erantzun arte itxaron dezakete. ISR latentzia arazo hauek saihesteko modu interesgarria da. Baina erredundantzia galtzeko arriskua dugu, ISR liderra baino ezin baita txikitu. Arrisku hori saihesteko, erabili ezarpena min.insync.erreplikak.

Bezeroaren konexioaren bermea

Ezarpenetan bootstrap.zerbitzariak ekoizleak eta kontsumitzaileak hainbat artekari zehaztu ditzakete bezeroak konektatzeko. Ideia da nodo bat jaisten denean, bezeroak konexio bat ireki dezan ordezko hainbat geratzen direla. Hauek ez dira zertan atalburuak, hasierako kargarako tranpolio bat besterik ez. Bezeroak galde diezaieke zein nodo duen irakurketa/idazketa partizioaren liderra.

RabbitMQ-n, bezeroak edozein nodotara konekta daitezke, eta barne bideratzeak eskaera joan behar duen lekura bidaltzen du. Horrek esan nahi du karga-orekatzailea instalatu dezakezula RabbitMQ-ren aurrean. Kafkak bezeroak dagokion partizioaren liderra ostatatzen duen nodora konektatzea eskatzen du. Egoera horretan, ezin duzu karga-orekatzailerik instalatu. Zerrenda bootstrap.zerbitzariak Ezinbestekoa da bezeroak hutsegite baten ondoren nodo egokiak sartzea eta aurkitzea.

Kafka Adostasun Arkitektura

Orain arte, ez dugu kontuan hartu klusterrak nola ikasten duen artekariaren erorketa eta buruzagi berria nola hautatzen den. Kafkak sareko partizioekin nola funtzionatzen duen ulertzeko, lehenik eta behin adostasun-arkitektura ulertu behar duzu.

Kafka kluster bakoitza Zookeeper kluster batekin batera zabaltzen da, hau da, adostasun-zerbitzu banatua, sistemari egoera jakin batean adostasuna lortzeko aukera ematen diona, koherentzia lehentasuna emanez erabilgarritasunari. Irakurketa eta idazketa eragiketak onartzeko Zookeeper nodo gehienen baimena behar da.

Zookeeper-ek klusterraren egoera gordetzen du:

• Gaien zerrenda, atalak, konfigurazioa, egungo lider-erreplikak, hobetsitako erreplikak.
• Klusterreko kideak. Agente bakoitzak Zookeeper multzoari ping egiten dio. Zehaztutako epe batean ping-a jasotzen ez badu, Zookeeper-ek brokera erabilgarri ez dagoela erregistratuko du.
• Kontrolagailurako nodo nagusiak eta ordezkoak hautatzea.

Kontrolagailu-nodoa erreplika liderrak hautatzeko ardura duen Kafka artekarietako bat da. Zookeeper-ek jakinarazpenak bidaltzen dizkio kontrolatzaileari kluster-kidetasunari eta gai-aldaketei buruz, eta kontrolatzaileak aldaketa horiei buruz jardun behar du.

Adibidez, har dezagun gai berri bat hamar partizio eta 3ko erreplikazio-faktorea dituena. Kontrolatzaileak partizio bakoitzeko lider bat aukeratu behar du, artekarien artean liderrak modu optimoan banatzen saiatuz.

Atalaren kontrolatzaile bakoitzeko:

• Zookeeper-en ISRri eta liderrari buruzko informazioa eguneratzen du;
• LeaderAndISRCommand bat bidaltzen dio partizio honen erreplika bat hartzen duen artekari bakoitzari, artekariei ISR ​​eta liderrari buruz informatuz.

Lider bat duen artekari bat erortzen denean, Zookeeper-ek jakinarazpen bat bidaltzen dio kontrolatzaileari, eta lider berria aukeratzen du. Berriz ere, kontrolatzaileak Zookeeper eguneratzen du lehenik eta gero komando bat bidaltzen dio artekari bakoitzari lidergo aldaketaren berri emanez.

Lider bakoitzak ISR-ak kontratatzeaz arduratzen da. Ezarpenak erreplika.lag.denbora.gehienez.ms bertan nor sartuko den zehazten du. ISR aldatzen denean, liderrak informazio berria transmititzen dio Zookeeper-i.

Zookeeper-ek edozein aldaketaren berri ematen du beti, hutsegiterik gertatuz gero, zuzendaritzak lider berri batera igarotzeko.

Arroza. 21. Kafkaren Adostasuna

Erreplika protokoloa

Erreplikazioaren xehetasunak ulertzeak datu-galera potentzialak hobeto ulertzen laguntzen dizu.

Laginketa-kontsultak, Log End Offset (LEO) eta Highwater Mark (HW)

Jarraitzaileak aldian-aldian liderrari erosketa-eskaerak bidaltzen dizkiotela uste genuen. Lehenetsitako tartea 500 ms-koa da. RabbitMQ-tik desberdina da RabbitMQ-n erreplikazioa ez dela ilararen ispiluak abiarazten, maisuak baizik. Maisuak aldaketak bultzatzen ditu ispiluetara.

Liderrak eta jarraitzaile guztiek Log End Offset (LEO) eta Highwater (HW) etiketa gordetzen dituzte. LEO markak azken mezuaren desplazamendua gordetzen du tokiko erreplikan, eta HW-k azken konpromezuaren desplazamendua gordetzen du. Gogoratu konpromezu egoerarako, mezua ISR erreplika guztietan mantendu behar dela. Horrek esan nahi du LEO normalean HW baino zertxobait aurretik dagoela.

Liderrak mezu bat jasotzen duenean, lokalean gordetzen du. Jarraitzaileak eskuratze eskaera bat egiten du bere LEO transmitituz. Orduan liderrak mezu sorta bat bidaltzen du LEO honetatik hasita eta uneko HWa ere transmititzen du. Liderrak erreplika guztiek mezua emandako desplazamenduan gordeta duten informazioa jasotzen duenean, HW marka mugitzen du. Liderrak bakarrik mugi dezake HWa, eta, beraz, jarraitzaile guztiek jakingo dute egungo balioa beren eskaeraren erantzunetan. Horrek esan nahi du jarraitzaileak liderren atzean geratu daitezkeela bai mezuan bai HW ezagutzan. Kontsumitzaileek egungo HWra arte soilik jasotzen dituzte mezuak.

Kontuan izan "iraunduta" esan nahi duela memorian idatzita, ez diskoan. Errendimendurako, Kafkak diskoarekin sinkronizatzen du tarte zehatz batean. RabbitMQ-k ere badu halako tarte bat, baina aitorpena bidaliko dio argitaratzaileari maisuak eta ispilu guztiek mezua diskoan idatzi dutenean soilik. Kafka garatzaileek, errendimendu arrazoiengatik, mezua memorian idatzi bezain laster ack bat bidaltzea erabaki zuten. Kafkak apustu egiten du erredundantziak memorian soilik onartutako mezuak laburki gordetzeko arriskua konpentsatzen duela.

Liderraren porrota

Lider bat erortzen denean, Zookeeper-ek kontrolatzaileari jakinarazten dio eta liderren erreplika berri bat hautatzen du. Lider berriak HW marka berria ezartzen du bere LEOaren arabera. Jarraitzaileek lider berriari buruzko informazioa jasotzen dute orduan. Kafkaren bertsioaren arabera, jarraitzaileak bi eszenatoki hauetako bat aukeratuko du:

1. Tokiko erregistroa HW ezagun batera moztuko du eta lider berriari eskaera bat bidaliko dio marka honen ondoren mezuak jasotzeko.
2. Liderrari eskaera bat bidaliko dio buruzagi hautatu zuten garaian HWa ezagutzeko, eta, ondoren, erregistroa desplazamendu honetara moztuko du. Ondoren, desplazamendu honetatik hasita aldian aldiko eskuratze eskaerak egiten hasiko da.

Baliteke jarraitzaile batek erregistroa moztu behar izatea arrazoi hauengatik:

• Lider batek huts egiten duenean, Zookeeper-en erregistratutako ISR multzoko lehen jarraitzaileak hauteskundeak irabazten ditu eta lider bihurtzen da. ISRko jarraitzaile guztiek, "sinkronizatuta" hartu arren, baliteke buruzagi ohiaren mezu guztien kopiarik ez izatea. Baliteke ageri den jarraitzaileak kopiarik eguneratuena ez izatea. Kafkak bermatzen du ez dagoela errepliken artean dibergentziarik. Horrela, desadostasunak saihesteko, jarraitzaile bakoitzak bere erregistroa moztu behar du bere hautapen unean lider berriaren HW baliora. Hau ezartzeko beste arrazoi bat da acks=guztiak hain garrantzitsua koherentziarako.
• Mezuak aldian-aldian idazten dira diskoan. Kluster-nodo guztiek aldi berean huts egiten badute, desplazamendu desberdinak dituzten erreplikak gordeko dira diskoetan. Baliteke artekariak sarean itzultzen direnean, aukeratutako buruzagi berria bere jarraitzaileen atzetik egotea, besteak baino lehen diskoan gordeta zegoelako.

Klusterrarekin elkarretaratzea

Klusterean berriro sartzen direnean, erreplikek lider batek huts egiten duenean bezala egiten dute: liderren erreplika egiaztatzen dute eta bere erregistroa bere HWra mozten dute (hauteskunde garaian). Alderatuz, RabbitMQ-k berdin tratatzen ditu bateratutako nodoak guztiz berri gisa. Bi kasuetan, artekariak lehendik dagoen edozein egoera baztertzen du. Sinkronizazio automatikoa erabiltzen bada, maisuak uneko eduki guztia erreplikatu behar du ispilu berrira "utzi mundu osoa itxaron" metodoan. Maisuak ez du irakurketa edo idazketa eragiketarik onartzen eragiketa honetan zehar. Planteamendu honek arazoak sortzen ditu ilara handietan.

Kafka banatutako erregistro bat da eta, oro har, RabbitMQ ilara batek baino mezu gehiago gordetzen ditu, non datuak ilaratik kentzen diren irakurri ondoren. Ilara aktiboak nahiko txikiak izan behar dira. Baina Kafka atxikipen-politika propioa duen erregistroa da, egun edo asteko epea ezar dezakeena. Ilararen blokeoa eta sinkronizazio osoa ikuspegia guztiz onartezina da banatutako erregistro baterako. Horren ordez, Kafkaren jarraitzaileek beren erregistroa buruzagiaren HWra moztu besterik ez dute (hautatzeko unean) haien kopia liderra baino lehenago badago. Litekeena den kasuetan, jarraitzailea atzean dagoenean, uneko LEOtik hasita eskuratze eskaerak egiten hasten da.

Jarraitzaile berriak edo berriro elkartu diren jarraitzaile ISRtik kanpo hasten dira eta ez dute konpromisoetan parte hartzen. Besterik gabe, taldearekin batera lan egiten dute, mezuak ahalik eta azkarren jasotzen dituzte liderra heldu eta ISRn sartu arte. Ez dago blokeorik eta ez dago zure datu guztiak bota beharrik.

Konektibitatearen galera

Kafkak RabbitMQ-k baino osagai gehiago ditu, beraz, jokabide multzo konplexuagoa du klusterra deskonektatzen denean. Baina Kafka hasiera batean klusterretarako diseinatu zen, beraz, irtenbideak oso ondo pentsatuta daude.

Jarraian, hainbat konexio-huts egoera daude:

• 1. eszenatokia: jarraitzaileak ez du liderra ikusten, baina hala ere Zookeeper ikusten du.
• 2. eszenatokia: liderrak ez du jarraitzailerik ikusten, baina oraindik Zookeeper ikusten du.
• 3. eszenatokia: Jarraitzaileak liderra ikusten du, baina ez du Zookeeper ikusten.
• 4. eszenatokia: liderrak jarraitzaileak ikusten ditu, baina ez du Zookeeper ikusten.
• 5. eszenatokia: jarraitzailea Kafka nodoetatik eta Zookeepertik guztiz bereizita dago.
• 6. eszenatokia: liderra Kafka nodoetatik eta Zookeepertik guztiz bereizita dago.
• 7. eszenatokia: Kafka kontrolagailu-nodoak ezin du beste Kafka-nodorik ikusi.
• 8. eszenatokia: Kafka kontrolatzaileak ez du Zookeeper ikusten.

Eszenatoki bakoitzak bere portaera du.

1. eszenatokia: jarraitzaileak ez du liderra ikusten, baina Zookeeper ikusten du

Arroza. 22. 1. eszenatokia: hiru errepliken ISR

Konektibitate-hutsak 3. artekaria 1. eta 2. artekarietatik bereizten du, baina ez Zookeepertik. 3. artekariak ezin ditu jasotzeko eskaerak bidali. Denbora pasa ondoren erreplika.lag.denbora.gehienez.ms ISRtik kentzen da eta ez du parte hartzen mezu-konpromisoetan. Konektibitatea berrezarritakoan, berreskurapen-eskaerei ekingo die eta ISR-ra sartuko da liderra heltzen denean. Zookeeper-ek ping-ak jasotzen jarraituko du eta artekaria bizirik dagoela suposatuko du.

Arroza. 23. 1. eszenatokia: agentea ISRtik kentzen da bertatik jasotze-eskaerarik jasotzen ez bada replica.lag.time.max.ms tartean.

Ez dago RabbitMQ-n bezala zatitutako garuna edo nodo esekidurarik. Horren ordez, erredundantzia murrizten da.

2. eszenatokia: liderrak ez du jarraitzailerik ikusten, baina Zookeeper ikusten du

Arroza. 24. 2. eszenatokia. Liderra eta bi jarraitzaile

Sare-konektibitatearen matxura batek liderra jarraitzaileetatik bereizten du, baina artekariak Zookeeper ikus dezake oraindik. Lehenengo eszenatokian bezala, ISR txikiagotu egiten da, baina oraingoan liderrari bakarrik jarraitzaile guztiek eskuratze eskaerak bidaltzeari uzten diotelako. Berriz ere, ez dago zatiketa logikorik. Horren ordez, mezu berrien erredundantzia galtzen da konexioa berreskuratu arte. Zookeeper-ek ping-ak jasotzen jarraitzen du eta artekaria bizirik dagoela uste du.

Arroza. 25. 2. eszenatokia. ISR liderra baino ez da txikitu

3. eszenatokia. Jarraitzaileak liderra ikusten du, baina ez du Zookeeper ikusten

Jarraitzailea Zookeepertik bereizten da, baina ez liderra duen brokertik. Ondorioz, jarraitzaileak eskuratze eskaerak egiten eta ISRko kide izaten jarraitzen du. Zookeeper-ek jada ez du ping-ak jasotzen eta broker-kopuru bat erregistratzen du, baina jarraitzaile bat baino ez denez, ez dago ondoriorik berreskuratu ondoren.

Arroza. 26. 3. eszenatokia: jarraitzaileak liderrari eskuratze eskaerak bidaltzen jarraitzen du

4. eszenatokia. Liderrak jarraitzaileak ikusten ditu, baina ez du Zookeeper ikusten

Arroza. 27. 4. eszenatokia. Liderra eta bi jarraitzaile

Liderra Zookeepertik bereizten da, baina ez jarraitzaileak dituzten artekarietatik.

Arroza. 28. 4. eszenatokia: Zookeeperengandik isolatuta dagoen liderra

Denbora pixka bat igaro ondoren, Zookeeper-ek artekarien hutsegite bat erregistratuko du eta horren berri emango dio kontrolatzaileari. Bere jarraitzaileen artean lider berria aukeratuko du. Hala ere, jatorrizko liderrak liderra dela pentsatzen jarraituko du eta sarrerak onartzen jarraituko du ack=1. Jarraitzaileak jada ez dizkiote jasotzeko eskaerak bidaltzen, beraz, hildakotzat hartuko ditu eta ISR berera murrizten saiatuko da. Baina Zookeeper-ekin konexiorik ez duenez, ezin izango du hori egin, eta une horretan uko egingo dio sarrera gehiago onartzeari.

mezuak acks=guztiak ez du aitorpenik jasoko ISR-ak lehenik erreplika guztiak pizten dituelako eta mezuak ez direlako iristen. Jatorrizko liderra ISRtik kentzen saiatzen denean, ezin izango du hori egin eta mezurik onartzeari utziko dio.

Bezeroek laster nabarituko dute lider aldaketa eta erregistroak zerbitzari berrira bidaltzen hasten dira. Sarea leheneratu ondoren, jatorrizko liderrak ikusten du jada ez dela liderra eta bere log-a moztu egiten du lider berriak log-dibergentzia saihesteko huts unean zuen HW baliora. Orduan, lider berriari eskuratze eskaerak bidaltzen hasiko da. Lider berrira errepikatzen ez diren jatorrizko liderraren erregistro guztiak galtzen dira. Hau da, bi buruzagi lanean ari ziren segundo gutxi horietan jatorrizko liderrak aitortu ez zituen mezuak galduko dira.

Arroza. 29. 4. eszenatokia. 1. broker-eko liderra jarraitzaile bihurtzen da sarea leheneratu ondoren

5. eszenatokia: jarraitzailea Kafka nodoetatik eta Zookeepertik guztiz bereizita dago

Jarraitzailea guztiz isolatuta dago Kafka nodoetatik eta Zookeepertik. Besterik gabe, bere burua ISRtik kentzen du sarea leheneratu arte, eta gero besteekin harrapatzen ditu.

Arroza. 30. 5. eszenatokia: jarraitzaile isolatua ISRtik kentzen da

6. eszenatokia: liderra Kafka nodoetatik eta Zookeepertik guztiz bereizita dago

Arroza. 31. 6. eszenatokia. Liderra eta bi jarraitzaile

Liderra erabat isolatuta dago bere jarraitzaileengandik, kontrolatzaileengandik eta Zookeeperengandik. Epe laburrean, sarrerak onartzen jarraituko du ack=1.

Arroza. 32. 6. eszenatokia: liderra Kafka eta Zookeeper nodoetatik isolatzea

Iraungi ondoren eskaerarik jaso ez izana erreplika.lag.denbora.gehienez.ms, ISR bere baitara txikitzen saiatuko da, baina ezin izango du Zookeeper-ekin komunikaziorik ez dagoelako, orduan idazketak onartzeari utziko dio.

Bitartean, Zookeeper-ek agente isolatua hildako gisa markatuko du eta kontrolatzaileak buruzagi berria aukeratuko du.

Arroza. 33. Agertokia 6. Bi buruzagi

Jatorrizko liderrak sarrerak onar ditzake segundo batzuetan, baina gero mezuak onartzeari uzten dio. Bezeroak 60 segundoz behin eguneratzen dira azken metadatuekin. Lider-aldaketaren berri emango zaie eta lider berriari sarrerak bidaltzen hasiko dira.

Arroza. 34. 6. eszenatokia: fabrikatzaileak lider berri batera aldatzen dira

Konektibitatea galdu zenetik jatorrizko liderrak egindako sarrera baieztatu guztiak galduko dira. Sarea leheneratu ondoren, jatorrizko liderrak Zookeeper-en bidez ikusiko du jada ez dela liderra. Ondoren, bere erregistroa moztuko du hauteskunde garaian buruzagi berriaren HWra eta jarraitzaile gisa eskaerak bidaltzen hasiko da.

Arroza. 35. 6. agertokia: jatorrizko liderra jarraitzaile bihurtzen da sare-konektibitatea berrezarri ondoren

Egoera horretan, bereizketa logikoa epe laburrean gerta daiteke, baina bada bakarrik ack=1 и min.insync.erreplikak halaber, 1. Bereizketa logikoa automatikoki amaitzen da, sarea leheneratu ondoren, jatorrizko liderra liderra ez dela konturatzen denean edo bezero guztiak liderra aldatu dela konturatzen direnean eta lider berriari idazten hasten direnean, lehen gertatzen dena. Nolanahi ere, mezu batzuk galduko dira, baina horrekin bakarrik ack=1.

Eszenatoki honen beste aldaera bat dago non, sarea zatitu baino lehen, jarraitzaileak atzean geratu ziren eta liderrak ISR konprimitu zuen bere buruari. Orduan isolatu egiten da konektibitatea galtzearen ondorioz. Lider berri bat hautatzen da, baina jatorrizko buruzagiak sarrerak onartzen jarraitzen du, are gehiago acks=guztiak, ISRn bera izan ezik beste inor ez dagoelako. Erregistro hauek sarea leheneratu ondoren galduko dira. Aukera hau saihesteko modu bakarra da min.insync.replicas = 2.

7. agertokia: Kafka kontrolagailu-nodoak ezin du beste Kafka-nodo bat ikusi

Oro har, Kafka nodo batekin konexioa galtzen denean, kontrolatzaileak ezin izango dio hari lider-aldaketaren informaziorik transmititu. Kasurik txarrenean, horrek epe laburreko bereizketa logikoa ekarriko du, 6. eszenatokian bezala. Gehienetan, artekaria ez da lidergorako hautagai bihurtuko azken honek huts egiten badu.

8. eszenatokia: Kafka kontrolatzaileak ez du Zookeeper ikusten

Zookeeper-ek ez du ping bat jasoko eroritako kontrolagailutik eta Kafka nodo berri bat hautatuko du kontrolatzaile gisa. Jatorrizko kontrolatzaileak bere burua honela aurkezten jarraitu dezake, baina ez du Zookeeper-en jakinarazpenik jasotzen, beraz, ez du zereginik izango. Sarea leheneratu ondoren, jada ez dela kontrolatzaile bat konturatuko da, Kafka nodo arrunt bihurtu dela.

Eszenatokietatik ateratako ondorioak

Ikusten dugu jarraitzaileen konektibitatea galtzeak ez duela mezuak galtzen, baizik eta aldi baterako erredundantzia murrizten duela sarea leheneratu arte. Horrek, noski, datuak galtzea ekar dezake nodo bat edo gehiago galtzen badira.

Liderra Zookeeper-etik bereizten bada konektagarritasuna galtzearen ondorioz, honek mezuak galtzea eragin dezake. ack=1. Zookeeper-ekin komunikazio faltak zatiketa logiko laburra eragiten du bi buruzagiekin. Arazo hau parametroaren bidez konpontzen da acks=guztiak.

Parametroa min.insync.erreplikak bi erreplika edo gehiagotan epe laburreko agertoki horiek 6. agertokian bezala mezu galdurik eragingo ez duten ziurtasun gehigarria ematen du.

Galdutako mezuen laburpena

Zerrenda ditzagun Kafkan datuak galtzeko modu guztiak:

• Edozein lider hutsegite mezuak erabiliz baieztatzen badira ack=1
• Lidergoaren edozein trantsizio zikin, hau da, ISRtik kanpoko jarraitzaile batera, nahiz eta acks=guztiak
• Liderra Zookeepertik isolatzea mezuak erabiliz baieztatzen badira ack=1
• Dagoeneko ISR taldea bere baitara txikitu duen liderren isolamendu osoa. Mezu guztiak galduko dira, baita acks=guztiak. Hau egia bada bakarrik min.insync.replicas=1.
• Partizio-nodo guztien aldibereko hutsegiteak. Mezuak memoriatik onartzen direnez, baliteke batzuk oraindik diskoan ez idaztea. Zerbitzariak berrabiarazi ondoren, baliteke mezu batzuk falta izatea.

Lidergo trantsizio hutsak saihestu daitezke debekatuz edo gutxienez bi kaleratze ziurtatuz. Konfigurazio iraunkorrena konbinazio bat da acks=guztiak и min.insync.erreplikak 1tik gora.

RabbitMQ eta Kafkaren fidagarritasunaren konparaketa zuzena

Fidagarritasuna eta erabilgarritasun handia bermatzeko, bi plataformek lehen eta bigarren mailako erreplikazio sistema bat ezartzen dute. Hala ere, RabbitMQ-k Akilesen orpoa du. Hutsegite baten ondoren berriro konektatzen direnean, nodoek beren datuak baztertzen dituzte eta sinkronizazioa blokeatzen da. Kolpe bikoitz honek zalantzan jartzen du RabbitMQ-ko ilara handien iraupena. Erredundantzia murriztua edo blokeo denbora luzea onartu beharko duzu. Erredundantzia murrizteak datuen galera masiboa izateko arriskua areagotzen du. Baina ilarak txikiak badira, erredundantziaren mesedetan, erabilgarritasun-aldi laburrak (segundo batzuk) behin eta berriro konektatzeko saiakerak erabiliz aurre egin ahal izango dira.

Kafkak ez du arazo hori. Lideraren eta jarraitzailearen arteko dibergentzia puntutik soilik baztertzen ditu datuak. Partekatutako datu guztiak gordetzen dira. Gainera, erreplikazioak ez du sistema blokeatzen. Liderrak mezuak onartzen jarraitzen du jarraitzaile berriak harrapatzen duen bitartean, beraz, devopsentzat, klusterrean sartzea edo berriro sartzea lan hutsala bihurtzen da. Jakina, oraindik ere badaude sareko banda-zabalera bezalako arazoak erreplikazioan. Jarraitzaile anitz gehitzen badituzu aldi berean, baliteke banda zabalera muga bat topatzea.

RabbitMQ Kafkaren gainetik dago fidagarritasunean, kluster bateko hainbat zerbitzariek aldi berean huts egiten dutenean. Esan dugun bezala, RabbitMQ-k argitaletxeari baieztapena bidaltzen dio mezua maisuak eta ispilu guztiek diskoan idatzi ondoren. Baina honek latentzia gehigarria gehitzen du bi arrazoirengatik:

• fsync ehun milisegundo gutxitan behin
• Ispiluaren porrota nodo bakoitzaren erabilgarritasuna egiaztatzen duten paketeen bizitza iraungi eta gero bakarrik antzeman daiteke. Ispilua moteldu edo erortzen bada, horrek atzerapena gehitzen du.

Kafkaren apustua da mezu bat hainbat nodotan gordetzen bada, mezuak aitor ditzakeela memorian sartu bezain laster. Horregatik, edozein motatako mezuak galtzeko arriskua dago (baita acks=guztiak, min.insync.replicas=2) aldibereko hutsegite kasuetan.

Orokorrean, Kafkak softwarearen errendimendu hobea erakusten du eta klusterretarako oinarritik diseinatuta dago. Jarraitzaile kopurua 11ra igo daiteke fidagarritasuna lortzeko beharrezkoa bada. Erreplikazio-faktorea 5 eta sinkronizazioan gutxieneko erreplika kopurua min.insync.replicas=3 mezua galtzea oso gertaera arraroa bihurtuko da. Zure azpiegiturak erreplikazio-ratio eta erredundantzia-maila hau onartzen badu, aukera hau aukeratu dezakezu.

RabbitMQ clustering ona da ilara txikietarako. Baina ilara txikiak ere azkar hazi daitezke trafiko handia dagoenean. Ilarak handitzen direnean, aukera gogorrak egin beharko dituzu erabilgarritasunaren eta fidagarritasunaren artean. RabbitMQ clustering-a ohikoena ez den egoeretarako da, non RabbitMQ-ren malgutasunaren onurak bere clusteringaren desabantailak baino handiagoak diren.

RabbitMQ-k ilara handiekiko duen zaurgarritasunaren aurkako antidoto bat ilara txikiago askotan zatitzea da. Ez baduzu behar ilara osoa ordenatzea, baizik eta dagozkion mezuak soilik (adibidez, bezero zehatz baten mezuak) edo ezer eskatu ez baduzu, aukera hau onargarria da: begiratu nire proiektua Berreorekatzailea ilara banatzeko (proiektua hasierako fasean dago oraindik).

Azkenik, ez ahaztu RabbitMQ zein Kafkaren multzokatze- eta erreplikazio-mekanismoetan dauden akats batzuk. Denborarekin, sistemak helduagoak eta egonkorragoak bihurtu dira, baina mezurik ez da inoiz % 100ean seguru egongo galtzetik! Horrez gain, eskala handiko istripuak gertatzen dira datu-zentroetan!

Zerbait galdu badut, akatsen bat egin badut edo punturen batekin ados ez bazaude, idatzi iruzkin bat edo jarri nirekin harremanetan.

Askotan galdetzen didate: “Zer aukeratu, Kafka ala RabbitMQ?”, “Zein plataforma da hobea?”. Egia esan, zure egoeraren, egungo esperientziaren eta abarren araberakoa da. Zalantza dut nire iritzia ematea, gehiegizko sinplifikazioa izango litzatekeelako plataforma bakarra gomendatzea erabilera kasu eta muga posible guztietarako. Artikulu sorta hau idatzi dut zure iritzia era dezazun.

Esan nahi dut bi sistema liderrak direla arlo honetan. Agian alboratuta nago, proiektuekin dudan esperientziagatik, mezuen ordena eta fidagarritasuna bezalako gauzak baloratu ohi ditudalako.

Fidagarritasun hori eta ordenamendu bermatua ez duten beste teknologia batzuk ikusten ditut, orduan RabbitMQ eta Kafka-ra begiratu eta bi sistema hauen balio ikaragarriaz jabetzen naiz.

Iturria: www.habr.com