В viimane artikkel vaatasime RabbitMQ klastrite tõrketaluvust ja kõrget saadavust. Nüüd süveneme Apache Kafkasse.

Siin on replikatsiooni ühikuks partitsioon. Igal teemal on üks või mitu jaotist. Igal sektsioonil on juht, jälgijatega või ilma. Teema loomisel määrate partitsioonide arvu ja replikatsioonikoefitsiendi. Tavaline väärtus on 3, mis tähendab kolme koopiat: üks juht ja kaks järgijat.

Riis. 1. Neli sektsiooni on jagatud kolme maakleri vahel

Kõik lugemis- ja kirjutamissoovid lähevad juhile. Jälgijad saadavad juhile perioodiliselt taotlusi uusimate sõnumite saamiseks. Tarbijad ei pöördu kunagi järgijate poole; viimased eksisteerivad ainult koondamise ja tõrketaluvuse huvides.

Partition rike

Kui maakler ebaõnnestub, kukuvad sageli läbi ka mitme sektsiooni juhid. Igas neist saab juhiks järgija teisest sõlmest. Tegelikult see alati nii ei ole, kuna sünkroonimistegur mõjutab ka: kas on sünkroonitud jälgijaid ja kui ei, siis kas sünkroniseerimata koopiale üleminek on lubatud. Aga ärgem tehkem praegu asju keeruliseks.

Maakler 3 lahkub võrgustikust ja maakleri 2 sektsiooni 2 jaoks valitakse uus juht.

Riis. 2. Maakler 3 sureb ja tema järgija maakleril 2 valitakse partitsiooni 2 uueks juhiks

Siis lahkub maakler 1 ja sektsioon 1 kaotab samuti oma juhi, kelle roll läheb üle maaklerile 2.

Riis. 3. Üks maakler on jäänud. Kõik juhid on ühe maakleri peal, mille koondamine on null

Kui maakler 1 naaseb võrku, lisab see neli jälgijat, pakkudes igale partitsioonile mõningast koondamist. Kuid kõik liidrid jäid ikkagi maaklerile 2.

Riis. 4. Liidrid jäävad maaklerile 2

Kui maakler 3 ilmub, oleme tagasi kolme koopia juurde partitsiooni kohta. Kuid kõik juhid on endiselt maakler 2 peal.

Riis. 5. Juhtide tasakaalustamata paigutus pärast maaklerite 1 ja 3 taastamist

Kafkal on tööriist juhtide paremaks tasakaalustamiseks kui RabbitMQ. Seal tuli kasutada kolmanda osapoole pistikprogrammi või skripti, mis muutis põhisõlme migreerimise eeskirju, vähendades migratsiooni ajal liiasust. Lisaks pidime suurte järjekordade puhul leppima sünkroonimise ajal kättesaamatusega.

Kafkal on juhirolli jaoks eelistatud koopiad. Kui teemasektsioonid luuakse, püüab Kafka juhte sõlmede vahel ühtlaselt jaotada ja märgib need esimesed juhid eelistatuks. Aja jooksul võivad liidrid serveri taaskäivitamise, rikete ja ühenduvuse rikete tõttu sattuda teistesse sõlmedesse, nagu ülalkirjeldatud äärmuslikul juhul.

Selle parandamiseks pakub Kafka kahte võimalust.

• Variant auto.leader.rebalance.enable=true võimaldab kontrolleri sõlmel liidrid automaatselt eelistatud koopiatele tagasi määrata ja seeläbi ühtse jaotuse taastada.
• Administraator saab skripti käivitada kafka-preferred-replica-election.sh käsitsi ümbermääramiseks.

Riis. 6. Koopiad pärast tasakaalustamist

See oli ebaõnnestumise lihtsustatud versioon, kuid tegelikkus on keerulisem, kuigi siin pole midagi liiga keerulist. Kõik taandub sünkroonitud koopiatele (In-Sync Replicas, ISR).

Sünkroonitud koopiad (ISR)

ISR on partitsiooni koopiate komplekt, mida peetakse sünkroonituks (sünkroonituks). Juht on olemas, aga järgijaid ei pruugi olla. Jälgija loetakse sünkroonituks, kui ta on teinud täpsed koopiad kõigist liidri sõnumitest enne intervalli möödumist replica.lag.time.max.ms.

Jälgija eemaldatakse ISR-i komplektist, kui see:

• ei esitanud intervalli valimise taotlust replica.lag.time.max.ms (arvatavasti surnud)
• ei õnnestunud intervalli jooksul värskendada replica.lag.time.max.ms (peetakse aeglaseks)

Jälgijad esitavad proovivõtutaotlusi intervalli jooksul replica.fetch.wait.max.ms, mis vaikimisi on 500 ms.

ISR-i eesmärgi selgeks selgitamiseks peame vaatama tootja kinnitusi ja mõningaid ebaõnnestumise stsenaariume. Tootjad saavad valida, millal maakler saadab kinnituse:

• acks=0, kinnitust ei saadeta
• acks=1, kinnitus saadetakse pärast seda, kui juht on kirjutanud teate oma kohalikku logisse
• acks=all, kinnitus saadetakse pärast seda, kui kõik ISR-i koopiad on sõnumi kohalikesse logidesse kirjutanud

Kafka terminoloogias, kui ISR ​​on sõnumi salvestanud, on see "kohustuslik". Acks=all on kõige turvalisem valik, kuid lisab ka täiendavat viivitust. Vaatame kahte näidet ebaõnnestumise kohta ja seda, kuidas erinevad "ack"-valikud ISR-i kontseptsiooniga suhtlevad.

Acks=1 ja ISR

Selles näites näeme, et kui juht ei oota, kuni kõigi jälgijate iga sõnum salvestatakse, on juht ebaõnnestumise korral võimalik andmete kadu. Sünkroonimata jälgija juurde navigeerimise saab seadistustega lubada või keelata unclean.leader.election.enable.

Selles näites on tootja väärtuseks acks=1. Sektsioon on jaotatud kõigi kolme maakleri vahel. Maakler 3 on taga, sünkroniseeris liidriga kaheksa sekundit tagasi ja on nüüd taga 7456 sõnumit. Maakler 1 jäi maha vaid sekundiga. Meie produtsent saadab sõnumi ja saab kiiresti tagasikiidu, ilma aeglaste või surnud jälgijateta, mida juht ei oota.

Riis. 7. ISR kolme koopiaga

Broker 2 ebaõnnestub ja tootja saab ühenduse veateate. Pärast juhtkonna üleminekut maaklerile 1 kaotame 123 sõnumit. Maakleri 1 järgija kuulus ISR-i, kuid ei olnud langedes liidriga täielikult sünkroonitud.

Riis. 8. Sõnumid lähevad kaotsi, kui see kokku jookseb

Konfiguratsioonis bootstrap.servers Tootjal on loetletud mitu maaklerit ja ta võib küsida teiselt maaklerilt, kes on uus sektsiooni juht. Seejärel loob see ühenduse vahendajaga 1 ja jätkab sõnumite saatmist.

Riis. 9. Sõnumite saatmine jätkub pärast väikest pausi

Maakler 3 on veelgi tagapool. See esitab toomistaotlusi, kuid ei saa sünkroonida. Selle põhjuseks võib olla aeglane võrguühendus maaklerite vahel, salvestusprobleem jne. See eemaldatakse ISR-ist. Nüüd koosneb ISR ühest koopiast – liidrist! Tootja jätkab sõnumite saatmist ja kinnituste vastuvõtmist.

Riis. 10. Maakleri 3 jälgija eemaldatakse ISR-ist

Maakler 1 langeb ja liidriroll läheb maaklerile 3, kaotades 15286 sõnumit! Tootja saab ühenduse veateate. Üleminek liidriks väljaspool ISR-i oli võimalik ainult tänu seadistusele unclean.leader.election.enable=true. Kui see on sisse installitud vale, siis üleminekut ei toimu ja kõik lugemis- ja kirjutamistaotlused lükatakse tagasi. Sel juhul ootame, kuni maakler 1 naaseb oma tervete andmetega koopias, mis võtab taas juhtimise üle.

Riis. 11. Maakler 1 kukub. Kui ilmneb rike, läheb suur hulk sõnumeid kaotsi

Produtsent loob ühenduse viimase maakleriga ja näeb, et tema on nüüd sektsiooni juht. Ta hakkab maaklerile 3 sõnumeid saatma.

Riis. 12. Pärast väikest pausi saadetakse sõnumid uuesti sektsiooni 0

Nägime, et peale lühikeste katkestuste uute ühenduste loomiseks ja uue juhi otsimiseks saatis tootja pidevalt sõnumeid. See konfiguratsioon tagab kättesaadavuse järjepidevuse (andmete turvalisuse) arvelt. Kafka kaotas tuhandeid sõnumeid, kuid võttis jätkuvalt vastu uusi kirjutisi.

Acks=kõik ja ISR

Kordame seda stsenaariumi uuesti, kuid koos acks=kõik. Broker 3 keskmine latentsusaeg on neli sekundit. Tootja saadab sõnumiga acks=kõik, ja nüüd ei saa kiiret vastust. Juht ootab, kuni kõik ISR-i koopiad sõnumi salvestavad.

Riis. 13. ISR kolme koopiaga. Üks on aeglane, mis põhjustab salvestamise viivitusi

Pärast neljasekundilist täiendavat viivitust saadab maakler 2 acki. Kõik koopiad on nüüd täielikult värskendatud.

Riis. 14. Kõik koopiad salvestavad sõnumid ja saadavad ack

Broker 3 jääb nüüd veelgi maha ja eemaldatakse ISR-ist. Latentsusaeg on oluliselt vähenenud, kuna ISR-is pole jäänud aeglaseid koopiaid. Maakler 2 ootab nüüd ainult vahendajat 1 ja tema keskmine viivitus on 500 ms.

Riis. 15. Maakleri 3 koopia eemaldatakse ISR-ist

Seejärel maakler 2 kukub ja juhtkond läheb edasi vahendajale 1 ilma sõnumite kadumiseta.

Riis. 16. Maakler 2 kukub

Tootja leiab uue juhi ja hakkab talle sõnumeid saatma. Latentsusaeg väheneb veelgi, kuna ISR koosneb nüüd ühest koopiast! Seetõttu valik acks=kõik ei lisa koondamist.

Riis. 17. Maakleri 1 koopia võtab juhtpositsiooni ilma sõnumeid kaotamata

Siis maakler 1 jookseb kokku ja juht läheb maaklerile 3, kaotades 14238 sõnumit!

Riis. 18. Broker 1 sureb ja juhiüleminek ebapuhta seadistusega põhjustab ulatuslikku andmekadu

Me ei saanud seda valikut installida unclean.leader.election.enable tähendusse tõsi. Vaikimisi on see võrdne vale. Seaded acks=kõik с unclean.leader.election.enable=true pakub juurdepääsetavust koos täiendava andmeturbega. Kuid nagu näete, võime sõnumid siiski kaotada.

Aga mis siis, kui tahame andmete turvalisust suurendada? Võite panna unclean.leader.election.enable = false, kuid see ei kaitse meid tingimata andmete kadumise eest. Kui juht kukkus kõvasti ja võttis andmed kaasa, siis sõnumid lähevad ikka kaotsi, pluss saadavus kaob seni, kuni administraator olukorra taastab.

Parem on tagada, et kõik sõnumid oleksid üleliigsed, ja muul juhul visake salvestis ära. Siis on vähemalt maakleri seisukohalt andmete kadumine võimalik vaid kahe või enama samaaegse rikke korral.

Acks=all, min.insync.replicas ja ISR

Teema konfiguratsiooniga min.insync.replicas Tõstame andmeturbe taset. Käime uuesti läbi eelmise stsenaariumi viimase osa, kuid seekord koos min.insync.replicas=2.

Seega on vahendajal 2 koopiajuht ja vahendaja 3 järgija eemaldatakse ISR-ist.

Riis. 19. ISR kahest koopiast

Maakler 2 kukub ja juhtkond läheb edasi vahendajale 1 ilma sõnumite kadumiseta. Kuid nüüd koosneb ISR ainult ühest koopiast. See ei vasta kirjete vastuvõtmise miinimumarvule ja seetõttu vastab maakler kirjutamiskatsele veaga NotEnoughReplicas.

Riis. 20. ISR-ide arv on üks väiksem kui failis min.insync.replicas määratud

See konfiguratsioon ohverdab saadavuse järjepidevuse nimel. Enne sõnumi kinnitamist tagame, et see on kirjutatud vähemalt kahele koopiale. See annab tootjale palju rohkem enesekindlust. Siin on sõnumi kadumine võimalik ainult siis, kui kaks koopiat ebaõnnestuvad samaaegselt lühikese aja jooksul, kuni sõnum kopeeritakse täiendavale jälgijale, mis on ebatõenäoline. Aga kui olete üliparanoiline, saate määrata replikatsiooniteguriks 5 ja min.insync.replicas 3. Siin peab rekordi kaotamiseks kukkuma kolm maaklerit korraga! Loomulikult maksate selle töökindluse eest täiendava latentsusajaga.

Kui juurdepääsetavus on andmete turvalisuse tagamiseks vajalik

Nagu ka korpus RabbitMQ-ga, mõnikord on juurdepääsetavus andmete turvalisuse tagamiseks vajalik. Peate mõtlema järgmisele.

• Kas väljaandja saab lihtsalt veateate tagastada ja lasta ülesvoolu teenusel või kasutajal hiljem uuesti proovida?
• Kas avaldaja saab sõnumi salvestada kohapeal või andmebaasi, et hiljem uuesti proovida?

Kui vastus on eitav, siis kättesaadavuse optimeerimine parandab andmete turvalisust. Kui valite salvestamata jätmise asemel saadavuse, kaotate vähem andmeid. Seega taandub kõik tasakaalu leidmisele ja otsus sõltub konkreetsest olukorrast.

ISR-i tähendus

ISR-komplekt võimaldab teil valida optimaalse tasakaalu andmeturbe ja latentsuse vahel. Näiteks tagage kättesaadavus enamiku koopiate tõrke korral, minimeerides surnud või aeglaste koopiate mõju latentsusaja osas.

Me valime tähenduse ise replica.lag.time.max.ms vastavalt teie vajadustele. Põhimõtteliselt tähendab see parameeter, kui suure viivitusega oleme nõus millal vastu võtma acks=kõik. Vaikeväärtus on kümme sekundit. Kui see on teie jaoks liiga pikk, saate seda vähendada. Siis suureneb ISR-i muutuste sagedus, kuna jälgijaid eemaldatakse ja lisatakse sagedamini.

RabbitMQ on lihtsalt peeglite komplekt, mida tuleb kopeerida. Aeglased peeglid lisavad latentsusaega ja surnud peeglid võivad oodata, kuni paketid, mis kontrollivad iga sõlme saadavust (võrgumärk), reageerivad. ISR on huvitav viis nende latentsusprobleemide vältimiseks. Kuid me riskime koondamise kaotamisega, kuna ISR võib kahaneda ainult liidriks. Selle ohu vältimiseks kasutage seadet min.insync.replicas.

Kliendiühenduse garantii

Seadetes bootstrap.servers tootja ja tarbija saavad klientide ühendamiseks määrata mitu maaklerit. Idee seisneb selles, et kui üks sõlm läheb alla, jääb mitu varu, millega klient saab ühenduse avada. Need ei pruugi olla sektsioonijuhid, vaid lihtsalt hüppelaud esialgseks laadimiseks. Klient saab neilt küsida, milline sõlm hostib lugemise/kirjutamise partitsiooni juhti.

RabbitMQ-s saavad kliendid ühenduse luua mis tahes sõlmega ja sisemine marsruutimine saadab päringu sinna, kuhu see peab minema. See tähendab, et saate RabbitMQ ette paigaldada koormuse tasakaalustaja. Kafka nõuab klientidelt ühenduse loomist sõlmega, mis majutab vastavat partitsioonijuhti. Sellises olukorras ei saa te koormuse tasakaalustajat installida. Nimekiri bootstrap.servers On oluline, et kliendid saaksid pärast riket õigetele sõlmedele juurde pääseda ja neid leida.

Kafka konsensuse arhitektuur

Siiani pole me arvestanud, kuidas klaster maakleri kukkumisest teada saab ja uut juhti valitakse. Et mõista, kuidas Kafka võrgusektsioonidega töötab, peate esmalt mõistma konsensuse arhitektuuri.

Iga Kafka klaster on juurutatud koos Zookeeperi klastriga, mis on hajutatud konsensuse teenus, mis võimaldab süsteemil jõuda konsensusele teatud oleku osas, eelistades järjepidevust kättesaadavuse asemel. Lugemis- ja kirjutamistoimingute heakskiitmiseks on nõutav enamiku Zookeeperi sõlmede nõusolek.

Zookeeper salvestab klastri oleku:

• Teemade loend, jaotised, konfiguratsioon, praegused juhtkoopiad, eelistatud koopiad.
• Klastri liikmed. Iga maakler pingib Zookeeperi klastrit. Kui see ei saa teatud aja jooksul pingi, registreerib Zookeeper maakleri kättesaamatuks.
• Kontrolleri põhi- ja varusõlmede valimine.

Kontrolleri sõlm on üks Kafka vahendajatest, kes vastutab koopiajuhtide valimise eest. Zookeeper saadab vastutavale töötlejale teateid klastri liikmelisuse ja teema muudatuste kohta ning vastutav töötleja peab nende muudatustega tegelema.

Näiteks võtame uue teema kümne partitsiooniga ja kordusteguriga 3. Kontroller peab valima igale partitsioonile juhi, püüdes liidreid maaklerite vahel optimaalselt jaotada.

Iga sektsiooni kontrolleri jaoks:

• uuendab Zookeeperis infot ISRi ja juhi kohta;
• Saadab käsu LeaderAndISRCmand igale maaklerile, kes majutab selle partitsiooni koopiat, teavitades maaklereid ISR-ist ja juhist.

Kui juhiga maakler kukub, saadab Zookeeper kontrollerile teate ja see valib uue juhi. Jällegi, kontroller värskendab esmalt Zookeeperit ja saadab seejärel käsu igale maaklerile, teavitades neid juhivahetusest.

Iga juht vastutab ISRide värbamise eest. Seaded replica.lag.time.max.ms määrab, kes sinna siseneb. Kui ISR ​​muutub, edastab juht uue teabe Zookeeperile.

Loomaaiapidajat teavitatakse alati muudatustest, et ebaõnnestumise korral läheks juhtkond sujuvalt üle uuele juhile.

Riis. 21. Kafka konsensus

Replikatsiooniprotokoll

Replikatsiooni üksikasjade mõistmine aitab teil paremini mõista võimalikke andmekao stsenaariume.

Proovivõtupäringud, logi lõpu nihe (LEO) ja kõrgveemärk (HW)

Arvasime, et jälgijad saadavad juhile perioodiliselt toomistaotlusi. Vaikimisi on intervall 500 ms. See erineb RabbitMQ-st selle poolest, et RabbitMQ-s ei algata replikatsiooni mitte järjekorrapeegel, vaid ülem. Meister lükkab muudatused peeglitele.

Juht ja kõik järgijad salvestavad logi lõpu nihke (LEO) ja Highwater (HW) sildi. LEO-märk salvestab viimase sõnumi nihke kohalikus koopias ja HW hoiab viimase kinnistamise nihet. Pidage meeles, et kinnistamise oleku jaoks peab sõnum säilima kõigis ISR-i koopiates. See tähendab, et LEO on tavaliselt HW-st veidi ees.

Kui juht saab sõnumi, salvestab ta selle kohapeal. Jälgija esitab toomise taotluse, edastades oma LEO. Seejärel saadab juht sellest LEO-st algava hulga sõnumeid ja edastab ka praeguse HW. Kui juht saab teabe, et kõik koopiad on sõnumi antud nihkega salvestanud, liigutab ta HW-märki. Ainult juht saab HW-d liigutada ja seega teavad kõik jälgijad oma päringu vastustes praegust väärtust. See tähendab, et jälgijad võivad liidrist maha jääda nii sõnumite kui ka HW teadmiste poolest. Tarbijad saavad sõnumeid ainult kuni praeguse HW-ni.

Pange tähele, et "püsinud" tähendab mällu, mitte kettale kirjutamist. Jõudluse tagamiseks sünkroonib Kafka kettaga kindla intervalliga. RabbitMQ-l on ka selline intervall, kuid see saadab väljaandjale kinnituse alles pärast seda, kui master ja kõik peeglid on teate kettale kirjutanud. Kafka arendajad otsustasid jõudluse huvides saata acki niipea, kui sõnum on mällu kirjutatud. Kafka kihla, et koondamine kompenseerib riski salvestada lühiajaliselt kinnitatud sõnumid ainult mällu.

Juhi ebaõnnestumine

Kui juht langeb, teavitab Zookeeper sellest kontrollerit ja valib uue liidri koopia. Uus juht seab oma LEO järgi uue HW märgi. Seejärel saavad jälgijad teavet uue juhi kohta. Olenevalt Kafka versioonist valib jälgija ühe kahest stsenaariumist.

1. See kärbib kohaliku logi teadaolevaks HW-ks ja saadab uuele juhile sõnumite päringu pärast seda märki.
2. Saadab juhile taotluse saada teada HW ajal, mil ta juhiks valiti, ja seejärel kärbib logi selle nihkeni. Seejärel hakkab see esitama perioodilisi toomistaotlusi alates sellest nihkest.

Jälgijal võib olla vaja logi kärpida järgmistel põhjustel.

• Kui juht ebaõnnestub, võidab Zookeeperiga registreeritud ISR-i komplekti esimene järgija valimised ja saab juhiks. Kõik ISR-i jälgijad, ehkki neid peetakse sünkroonis, ei pruugi olla saanud endiselt juhilt kõigi sõnumite koopiaid. On täiesti võimalik, et esiletoodud jälgijal pole kõige ajakohasemat koopiat. Kafka tagab, et koopiate vahel ei esineks erinevusi. Seega, et vältida lahknevusi, peab iga jälgija kärpima oma logi uue juhi HW väärtuseks tema valimise ajal. See on veel üks põhjus, miks seadistada acks=kõik nii oluline järjepidevuse jaoks.
• Sõnumid kirjutatakse perioodiliselt kettale. Kui kõik klastri sõlmed ebaõnnestuvad korraga, salvestatakse erinevate nihketega koopiad ketastele. Võimalik, et kui maaklerid uuesti võrku tulevad, jääb valituks osutunud uus juht oma jälgijate taha, sest ta salvestati kettale enne teisi.

Taasühinemine klastriga

Klastriga uuesti liitudes teevad koopiad sama, mis juhi ebaõnnestumise korral: nad kontrollivad juhi koopiat ja kärbivad oma logi selle HW-ks (valimise ajal). Võrdluseks käsitleb RabbitMQ taasühendatud sõlme täiesti uutena. Mõlemal juhul loobub maakler olemasolevast olekust. Kui kasutatakse automaatset sünkroonimist, siis peab juht uude peeglisse kopeerima absoluutselt kogu praeguse sisu meetodil "las kogu maailm ootab". Juht ei aktsepteeri selle toimingu ajal ühtegi lugemis- ega kirjutamisoperatsiooni. Selline lähenemine tekitab probleeme suurtes järjekordades.

Kafka on hajutatud logi ja üldiselt salvestab see rohkem sõnumeid kui RabbitMQ järjekord, kus andmed pärast lugemist järjekorrast eemaldatakse. Aktiivsed järjekorrad peaksid jääma suhteliselt väikeseks. Kuid Kafka on logi, millel on oma säilituspoliitika, mis võib määrata päevade või nädalate pikkuse perioodi. Järjekorra blokeerimine ja täielik sünkroonimine on hajutatud logi puhul täiesti vastuvõetamatu. Selle asemel kärbivad Kafka järgijad oma logi lihtsalt juhi HW-ks (tema valimise ajal), kui nende koopia on juhist ees. Tõenäolisemal juhul, kui jälgija on taga, hakkab ta lihtsalt esitama toomistaotlusi, alustades oma praegusest LEO-st.

Uued või uuesti liitunud jälgijad alustavad väljaspool ISR-i ega osale kohustustes. Nad töötavad lihtsalt grupi kõrval, saades sõnumeid nii kiiresti kui võimalik, kuni jõuavad juhile järele ja sisenevad ISR-i. Puudub lukustus ja pole vaja kõiki oma andmeid ära visata.

Ühenduse kaotus

Kafkal on rohkem komponente kui RabbitMQ-l, seega on sellel klastri lahtiühendamisel keerulisem käitumine. Kuid Kafka oli algselt mõeldud klastrite jaoks, seega on lahendused väga hästi läbi mõeldud.

Allpool on toodud mitu ühenduvuse ebaõnnestumise stsenaariumi.

• 1. stsenaarium: jälgija ei näe juhti, kuid näeb siiski loomaaiapidajat.
• 2. stsenaarium: juht ei näe jälgijaid, kuid näeb siiski Zookeeperit.
• 3. stsenaarium: jälgija näeb juhti, kuid ei näe loomaaiapidajat.
• 4. stsenaarium: juht näeb jälgijaid, kuid ei näe loomaaiapidajat.
• 5. stsenaarium: jälgija on täiesti eraldi nii teistest Kafka sõlmedest kui ka Zookeeperist.
• 6. stsenaarium: juht on täiesti eraldi nii teistest Kafka sõlmedest kui ka Zookeeperist.
• 7. stsenaarium: Kafka kontrolleri sõlm ei näe teist Kafka sõlme.
• 8. stsenaarium: Kafka kontroller ei näe Zookeeperit.

Igal stsenaariumil on oma käitumine.

1. stsenaarium: jälgija ei näe juhti, kuid näeb siiski Zookeeperit

Riis. 22. 1. stsenaarium: kolme koopia ISR

Ühenduvustõrge eraldab vahendaja 3 vahendajatest 1 ja 2, kuid mitte Zookeeperist. Broker 3 ei saa enam hankimistaotlusi saata. Pärast aja möödumist replica.lag.time.max.ms see eemaldatakse ISR-ist ega osale sõnumite kinnitamises. Kui ühenduvus on taastatud, jätkab see taotluste toomist ja liitub ISR-iga, kui ta liidrile järele jõuab. Zookeeper jätkab pingide vastuvõtmist ja eeldab, et maakler on elus ja terve.

Riis. 23. 1. stsenaarium: maakler eemaldatakse ISR-ist, kui temalt ei saada intervalli replica.lag.time.max.ms jooksul toomistaotlust

Puudub jagatud aju või sõlmede peatamine nagu RabbitMQ-s. Selle asemel vähendatakse koondamist.

2. stsenaarium: juht ei näe jälgijaid, kuid näeb siiski Zookeeperit

Riis. 24. Stsenaarium 2. Juht ja kaks järgijat

Võrguühenduse rike eraldab liidri jälgijatest, kuid maakler näeb siiski Zookeeperit. Nagu esimeses stsenaariumis, väheneb ISR, kuid seekord ainult liidrini, kuna kõik järgijad lõpetavad toomistaotluste saatmise. Jällegi pole loogilist jaotust. Selle asemel kaob uute sõnumite liiasus kuni ühenduse taastamiseni. Zookeeper saab jätkuvalt pinge ja usub, et maakler on elus ja terve.

Riis. 25. Stsenaarium 2. ISR on kahanenud ainult liidrini

Stsenaarium 3. Jälgija näeb juhti, kuid ei näe loomaaiapidajat

Jälgija on eraldatud Zookeeperist, kuid mitte liidriga maaklerist. Selle tulemusel jätkab jälgija toomistaotluste esitamist ja on ISR-i liige. Zookeeper ei saa enam pinge ja registreerib maakleri krahhi, kuid kuna see on ainult jälgija, siis pärast taastumist pole tagajärgi.

Riis. 26. 3. stsenaarium: jälgija jätkab juhile toomistaotluste saatmist

Stsenaarium 4. Juht näeb jälgijaid, kuid ei näe loomaaiapidajat

Riis. 27. Stsenaarium 4. Juht ja kaks järgijat

Liider on eraldatud Zookeeperist, kuid mitte jälgijatega vahendajatest.

Riis. 28. Stsenaarium 4: juht isoleeritud loomaaiapidajast

Mõne aja pärast registreerib Zookeeper maakleri tõrke ja teavitab sellest kontrollerit. Ta valib oma järgijate hulgast uue juhi. Algne juht arvab aga jätkuvalt, et ta on juht ja võtab ka edaspidi vastu kandeid acks=1. Jälgijad ei saada talle enam toomistaotlusi, seega peab ta neid surnuks ja proovib ISR-i enda jaoks kahandada. Kuid kuna sellel pole Zookeeperiga ühendust, ei saa see seda teha ja keeldub sel hetkel täiendavaid kandeid vastu võtmast.

Сообщения acks=kõik ei saa kinnitust, sest ISR lülitab esmalt sisse kõik koopiad ja sõnumid ei jõua nendeni. Kui esialgne juht proovib neid ISR-ist eemaldada, ei saa ta seda teha ja lõpetab sõnumite vastuvõtmise.

Kliendid märkavad peagi juhi muutust ja hakkavad kirjeid uude serverisse saatma. Kui võrk on taastatud, näeb algne juht, et ta pole enam juht, ja kärbib logi HW väärtuseks, mis uuel juhil oli ebaõnnestumise ajal, et vältida logi lahknemist. Seejärel hakkab see uuele juhile hankimistaotlusi saatma. Kõik algse liidri kirjed, mida uuele juhile ei kopeerita, lähevad kaotsi. See tähendab, et sõnumid, mida algne juht nende paari sekundi jooksul, mil kaks juhti töötasid, ei tunnistanud, lähevad kaduma.

Riis. 29. Stsenaarium 4. Maakleri 1 liider muutub pärast võrgu taastamist jälgijaks

5. stsenaarium: jälgija on täiesti eraldi nii teistest Kafka sõlmedest kui ka Zookeeperist

Jälgija on täielikult isoleeritud nii teistest Kafka sõlmedest kui ka Zookeeperist. Ta lihtsalt eemaldab end ISR-ist, kuni võrk taastub, ja jõuab siis teistele järele.

Riis. 30. 5. stsenaarium: isoleeritud jälgija eemaldatakse ISR-ist

6. stsenaarium: juht on täiesti eraldi nii teistest Kafka sõlmedest kui ka Zookeeperist

Riis. 31. Stsenaarium 6. Juht ja kaks järgijat

Juht on täielikult isoleeritud oma järgijatest, kontrollerist ja loomaaiapidajast. Lühiajaliselt jätkab see kannete vastuvõtmist alates acks=1.

Riis. 32. Stsenaarium 6: liidri isoleerimine teistest Kafka ja Zookeeperi sõlmedest

Pärast aegumist pole taotlusi saanud replica.lag.time.max.ms, proovib see ISR-i iseendaks kahandada, kuid ei saa seda teha, kuna Zookeeperiga puudub side, siis lõpetab ta kirjutiste vastuvõtmise.

Vahepeal märgib Zookeeper isoleeritud maakleri surnuks ja kontrolör valib uue juhi.

Riis. 33. Stsenaarium 6. Kaks juhti

Algne juht võib mõne sekundi jooksul sissekandeid vastu võtta, kuid seejärel lõpetab sõnumite vastuvõtmise. Kliente värskendatakse iga 60 sekundi järel uusimate metaandmetega. Neid teavitatakse juhi vahetusest ja nad hakkavad uuele juhile kandeid saatma.

Riis. 34. 6. stsenaarium: Tootjad lähevad üle uuele juhile

Kõik kinnitatud kirjed, mille algne juht tegi pärast ühenduse katkemist, lähevad kaotsi. Kui võrk on taastatud, avastab algne juht Zookeeperi kaudu, et ta pole enam juht. Seejärel kärbib see oma logi valimise ajal uue juhi HW-ks ja hakkab saatma taotlusi jälgijana.

Riis. 35. 6. stsenaarium: algsest juhist saab pärast võrguühenduse taastamist järgija

Sellises olukorras võib loogiline eraldamine toimuda lühiajaliselt, kuid ainult siis acks=1 и min.insync.replicas ka 1. Loogiline eraldamine lõpeb automaatselt kas peale võrgu taastamist, kui esialgne juht mõistab, et ta pole enam juht või kui kõik kliendid mõistavad, et juht on muutunud ja hakkavad uuele juhile kirjutama – olenevalt sellest, kumb juhtub varem. Igal juhul lähevad mõned sõnumid kaotsi, kuid ainult koos acks=1.

Sellel stsenaariumil on veel üks variant, kus vahetult enne võrgu jagunemist jäid järgijad maha ja juht tihendas ISR-i ainult iseendaks. Seejärel muutub see ühenduse katkemise tõttu isoleerituks. Valitakse uus juht, kuid esialgne juht jätkab kannete vastuvõtmist, isegi acks=kõik, sest peale tema pole ISR-is kedagi teist. Need kirjed lähevad pärast võrgu taastamist kaotsi. Ainus viis seda võimalust vältida on min.insync.replicas = 2.

7. stsenaarium: Kafka kontrolleri sõlm ei näe teist Kafka sõlme

Üldjuhul, kui ühendus Kafka sõlmega on kadunud, ei saa kontroller sellele liidri muutmise teavet edastada. Halvimal juhul toob see kaasa lühiajalise loogilise eraldumise, nagu stsenaariumis 6. Enamasti ei saa maakler lihtsalt liidrikandidaadiks, kui viimane ebaõnnestub.

8. stsenaarium: Kafka kontroller ei näe Zookeeperit

Zookeeper ei saa kukkunud kontrollerilt pingi ja valib kontrolleriks uue Kafka sõlme. Algne kontroller võib end sellisena edasi esitleda, kuid ta ei saa Zookeeperilt märguandeid, seega pole tal mingeid ülesandeid täita. Kui võrk on taastatud, saab ta aru, et ta pole enam kontroller, vaid temast on saanud tavaline Kafka sõlm.

Järeldused stsenaariumitest

Näeme, et jälgijate ühenduvuse kaotamine ei too kaasa sõnumite kadumist, vaid lihtsalt vähendab ajutiselt liiasust, kuni võrk taastub. Loomulikult võib see ühe või mitme sõlme kaotsimineku korral põhjustada andmete kadumise.

Kui juht eraldatakse Zookeeperist ühenduse katkemise tõttu, võib see põhjustada sõnumite kadumist acks=1. Suhtlemise puudumine Zookeeperiga põhjustab kahe juhi vahel lühikese loogilise lõhe. See probleem lahendatakse parameetri abil acks=kõik.

Parameeter min.insync.replicas kaheks või enamaks koopiaks annab täiendava kindlustunde, et sellised lühiajalised stsenaariumid ei too kaasa sõnumite kadumist nagu stsenaariumi 6 puhul.

Kaotatud sõnumite kokkuvõte

Loetleme kõik viisid, kuidas saate Kafkas andmeid kaotada.

• Mis tahes juhi rike, kui sõnumid kinnitati kasutades acks=1
• Igasugune ebapuhas juhtimise üleminek, see tähendab järgijale väljaspool ISR-i, isegi koos acks=kõik
• Juhi isoleerimine Zookeeperist, kui sõnumid kinnitati kasutades acks=1
• Täielik isolatsioon liidrist, kes on juba ISR-i grupi iseendaks kahandanud. Kõik sõnumid lähevad kaotsi acks=kõik. See kehtib ainult siis, kui min.insync.replicas=1.
• Kõigi partitsioonisõlmede samaaegsed tõrked. Kuna teateid kinnitatakse mälust, ei pruugita mõnda veel kettale kirjutada. Pärast serverite taaskäivitamist võivad mõned sõnumid puududa.

Ebapuhtaid juhiüleminekuid saab vältida, kui need keelatakse või tagatakse vähemalt kaks koondamist. Kõige vastupidavam konfiguratsioon on kombinatsioon acks=kõik и min.insync.replicas rohkem kui 1.

RabbitMQ ja Kafka töökindluse otsene võrdlus

Usaldusväärsuse ja kõrge kättesaadavuse tagamiseks rakendavad mõlemad platvormid esmase ja sekundaarse replikatsioonisüsteemi. RabbitMQ-l on aga Achilleuse kand. Pärast riket uuesti ühendades loobuvad sõlmed oma andmetest ja sünkroonimine blokeeritakse. See kahekordne segadus seab kahtluse alla RabbitMQ suurte järjekordade pikaealisuse. Peate leppima kas vähendatud koondamisega või pikkade blokeerimisaegadega. Koondamise vähendamine suurendab massilise andmekao ohtu. Kui aga järjekorrad on väikesed, saab koondamise huvides toime tulla lühikeste (paar sekundit) mittekättesaadavuse perioodidega, kasutades korduvaid ühenduskatseid.

Kafkal seda probleemi pole. See jätab andmed kõrvale ainult juhi ja järgija lahknemise punktist. Kõik jagatud andmed salvestatakse. Lisaks ei blokeeri replikatsioon süsteemi. Liider jätkab postituste vastuvõtmist, kuni uus jälgija järele jõuab, nii et devopsi jaoks muutub klastriga liitumine või uuesti liitumine tühiseks ülesandeks. Muidugi on replikatsiooni ajal endiselt probleeme, nagu võrgu ribalaius. Kui lisate korraga mitu jälgijat, võib teil tekkida ribalaiuse piirang.

RabbitMQ on töökindluse poolest Kafkast parem, kui klastris mitu serverit korraga ebaõnnestuvad. Nagu me juba ütlesime, saadab RabbitMQ väljaandjale kinnituse alles pärast seda, kui juht ja kõik peeglid on sõnumi kettale kirjutanud. Kuid see lisab täiendavat latentsust kahel põhjusel:

• fsync iga paarisaja millisekundi järel
• Peegli tõrget saab märgata alles pärast seda, kui iga sõlme (nettick) saadavust kontrollivate pakettide eluiga on möödas. Kui peegel aeglustab või kukub, lisab see viivitust.

Kafka panus seisneb selles, et kui sõnum on salvestatud mitmesse sõlme, saab see teateid kinnitada kohe, kui need mällu jõuavad. Seetõttu on oht igat tüüpi sõnumite kaotamiseks (isegi acks=kõik, min.insync.replicas=2) samaaegse rikke korral.

Üldiselt on Kafka tarkvara parem jõudlus ja see on algusest peale loodud klastrite jaoks. Usaldusväärsuse huvides saab jälgijate arvu suurendada 11-ni. Replikatsioonitegur 5 ja minimaalne koopiate arv sünkroonimisel min.insync.replicas=3 muudab sõnumi kadumise väga haruldaseks sündmuseks. Kui teie infrastruktuur toetab seda replikatsioonisuhet ja liiasuse taset, saate selle valiku valida.

RabbitMQ klasterdamine on hea väikeste järjekordade jaoks. Kuid isegi väikesed järjekorrad võivad tiheda liikluse korral kiiresti kasvada. Kui järjekorrad muutuvad suureks, peate tegema raskeid valikuid kättesaadavuse ja töökindluse vahel. RabbitMQ klasterdamine sobib kõige paremini ebatüüpilisteks olukordadeks, kus RabbitMQ paindlikkusest tulenevad eelised kaaluvad üles kõik selle rühmitamise puudused.

Üks vastumürk RabbitMQ haavatavusele suurte järjekordade vastu on jagada need paljudeks väiksemateks järjekordadeks. Kui te ei nõua kogu järjekorra täielikku järjestamist, vaid ainult asjakohaseid sõnumeid (näiteks konkreetse kliendi sõnumid) või ei telli üldse midagi, siis on see valik vastuvõetav: vaadake minu projekti Tasakaalustaja järjekorda jagada (projekt on alles algusjärgus).

Lõpuks ärge unustage mitmeid vigu nii RabbitMQ kui ka Kafka klastrite ja replikatsiooni mehhanismides. Aja jooksul on süsteemid muutunud küpsemaks ja stabiilsemaks, kuid ükski sõnum pole kunagi 100% kaitstud kadumise eest! Lisaks juhtub andmekeskustes suuremahulisi õnnetusi!

Kui mul jäi midagi kahe silma vahele, eksisin või kui te mõne punktiga ei nõustu, kirjutage julgelt kommentaaridesse või võtke minuga ühendust.

Minult küsitakse sageli: “Mida valida, Kafka või RabbitMQ?”, “Milline platvorm on parem?”. Tõde on see, et see sõltub teie olukorrast, praegusest kogemusest jne. Ma kõhklen oma arvamust avaldamas, sest oleks liigne lihtsustus soovitada ühte platvormi kõigi kasutusjuhtude ja võimalike piirangute jaoks. Kirjutasin selle artiklite sarja, et saaksite oma arvamuse kujundada.

Tahan öelda, et mõlemad süsteemid on selles valdkonnas liidrid. Ma võin olla veidi kallutatud, sest oma projektidega seotud kogemuste põhjal hindan tavaliselt selliseid asju nagu sõnumite järjekord ja usaldusväärsus.

Näen teisi tehnoloogiaid, millel puudub see töökindlus ja garanteeritud tellimine, siis vaatan RabbitMQ-d ja Kafkat ning mõistan mõlema süsteemi uskumatut väärtust.

Allikas: www.habr.com