V eelmisel artiklil Oleme uurinud RabbitMQ klasterdamist, et tagada tõrkeotsing ja kõrge kättesaadavus. Nüüd sukeldume sügavamale Apache Kafka sellesse teema.

Siin on replikatsiooniks üksus jao (partition). Igal teema puhul on üks või mitu jao. Igas jaos on juht ja järgijad või ilma nendeta. Teema loomisel on määratud jao arv ja replikatsiooni koefitsient. Tavaline väärtus on 3, see tähendab kolme koopiat: üks juht ja kaks järgijat.

Joon. 1. Neli jaod on jaotatud kolme maaklerite vahel

Kõik lugemis- ja kirjutamisettepanekud suunatakse juhile. Järgijad saadavad perioodiliselt juhile päringuid viimaste sõnumite saamiseks. Tarbijad ei pöördu kunagi järgijate poole, viimased eksisteerivad ainult üleliigsuse ja tõrkeotsingu jaoks.

Jaotuse tõrge

Kui broker välja kukub, kaovad sageli mitme jao liidrid. Igas neist saab liidriks teise sõlme järgija. Tegelikult ei ole see alati nii, kuna mõjutab ka sünkroniseerimise tegur: kas on olemas sünkroniseeritud järgijad ja kui ei, siis kas on lubatud üleminek sünkroniseerimata replikale. Kuid ärme nüüd asju keeruliseks muuda.

Võrgust kaob broker 3 — ja jaos 2 valitakse uueks liidriks broker 2.

Joonis 2. Broker 3 sureb ning tema järgija broker 2-l valitakse uueks liidriks jaos 2.

Seejärel kaob broker 1 ning jao 1 kaotab samuti oma liidri, kelle roll läheb üle broker 2-le.

Joonis 3. Jäi alles üks broker. Kõik liidrid asuvad ühes brokeris nullräändusega.

Kui broker 1 naaseb võrku, lisab ta neli järgijat, tagades igale jaole teatud üleliigsuse. Kuid kõik liidrid on endiselt broker 2-l.

Joonis 4. Liidrid jäävad broker 2-le.

Kui broker 3 tõuseb, naaseme kolme replikaga jaosse. Kuid kõik liidrid jäävad endiselt broker 2-le.

Joonis 5. Liidrite tasakaalustamata jaotumine pärast brokerite 1 ja 3 taastamist.

Kafkal on tööriist, mis võimaldab kvaliteetsemat liidrite tasakaalustamist kui RabbitMQ. Seal tuli kasutada kolmandate osapoolte pluginaid või skripte, mis muutsid poliitikaid peamise sõlme migratsiooni ajal, vähendades üleliigset koormust. Suuremate järjekordade korral tuli leppida ka katkestustega sünkroonimise ajal.

Kafkal on kontseptsioon „eelisarvestitest“ liidri rolli jaoks. Teemasid luues püüab Kafka liidreid ühtlaselt sõlmedele jaotada ning märgistab need esimesed liidrid eelisarvustiteks. Aja jooksul, serverite taaskäivituste, tõrgete ja ühenduse katkemise tõttu võivad liidrid sattuda teistele sõlmedele, nagu eespool kirjeldatud äärmuslikul juhul.

Selle parandamiseks pakub Kafka kahte võimalust:

• Valik auto.leader.rebalance.enable=true see võimaldab kontrollerisõlmel automaatselt liidreid tagasi eelisarvestitele ümber jaotada, taastades seeläbi ühtlase jaotuse.
• Administraator võib käsitsi ümberjaotamiseks käivitada skripti kafka-preferred-replica-election.sh Kujutis 6. Replikad pärast tasakaalustamist

Joonis 6. Replika pärast ümbertasakaalustamist

See oli lihtsustatud versioon tõrkest, kuid reaalsus on keerulisem, kuigi siin pole midagi liiga keerulist. Kõik taandub sünkroniseeritud replikatele (In-Sync Replicas, ISR).

Sünkroniseeritud replikad (ISR)

ISR on jaotuse replikate kogum, mida peetakse „sünkroniseeritud“ (in-sync). Seal on juht ja järgijad võivad puududa. Järgija loetakse sünkroniseerituks, kui ta on teinud juhtide kõigi sõnumite täpsed koopiad enne intervalli lõppu. replica.lag.time.max.ms.

Järgija eemaldatakse ISR-ist, kui ta:

• ei ole intervalli jooksul päringut teinud replica.lag.time.max.ms (loetakse surnuks)
• ei ole intervalli jooksul suutnud uuendada replica.lag.time.max.ms (loetakse aeglaseks)

Järgijad teevad päringuid intervalli jooksul replica.fetch.wait.max.ms, mis vaikimisi on 500 ms.

ISR-i eesmärgi selgeks mõistmiseks tuleb vaadata tootja (producer) kinnitusprotsesse ja mõningaid tõrke stsenaariume. Tootjad võivad valida, millal maakler saadab kinnituse:

• acks=0, kinnitust ei saadeta
• acks=1, kinnitus saadetakse pärast seda, kui juht on sõnumi oma kohalikku logisse salvestanud.
• acks=all, kinnitatud saadetakse pärast seda, kui kõik repliigid ISR on salvestanud sõnumi kohalikes logides.

Kafka terminoloogias, kui ISR on salvestanud sõnumi, toimub selle 'commit'. Acks=all on kõige turvalisem võimalus, kuid toob kaasa ka lisaviivituse. Vaatleme kahte näidet tõrke kohta ja kuidas erinevad 'acks' valikud suhtlevad ISR kontseptsiooniga.

Acks=1 ja ISR

Selles näites näeme, et kui juht ei oota, kuni iga sõnum salvestatakse kõigilt järgijatest, võib juhi tõrke korral andmeid kaotada. Üleminek sünhroniseerimata järgijale võib olla lubatud või keelatud seade abil. unclean.leader.election.enable.

Selles näites on tootjal määratud väärtus acks=1. Jaotuse korraldavad kõik kolm maaklerit. Maakler 3 on ajas maha jäänud, ta on juhtiga sünkroonitud kaheksa sekundi eest ja praegu jääb 7456 sõnumi võrra maha. Maakler 1 on maha jäänud ainult ühe sekundi. Meie tootja saadab sõnumi ja saab kiiresti tagasi ack, ilma viivituseta aeglaste või surnud järgijate tõttu, keda juht ei oota.

Joon. 7. ISR kolme repliigiga

Broker 2 ei tööta ja tootja saab ühendusviga. Pärast juhi vahetumist Broker 1-ks kaotame 123 sõnumit. Järgneja Broker 1-s kuulus ISR-i, kuid ei sünkroonitud täielikult juhiga, kui see ebaõnnestus.

Joonis 8. Sõnumid kaovad tõrgumise korral.

Konfiguratsioonis bootstrap.servers on tootjal loetletud mitu brookera, ja ta võib teiselt brookerilt küsida, kes on saanud uue jaotuse juhi. Seejärel loob ta ühenduse Broker 1-ga ja jätkab sõnumite saatmist.

Joonis 9. Sõnumite saatmine taastatakse pärast lühikest katkestust.

Broker 3 jääb veelgi maha. Ta teeb päringuid, kuid ei suuda sünkroonida. See võib olla tingitud aeglasest võrgusideühendusest brokerite vahel, salvestamisprobleemidest jne. Ta eemaldatakse ISR-ist. Nüüd koosneb ISR ühest replikast — juhist! Toetaja jätkab sõnumite saatmist ja kinnituste saamist.

Joonis 10. Järgneja Broker 3 eemaldatakse ISR-ist.

Brokker 1 kukub ja liidri roll läheb brokkerile 3, kaotades 15286 sõnumit! Tootja saab ühenduse loomise tõrketeate. Liidri vahetus ISR-ist välja oli võimalik ainult seadistuse tõttu. unclean.leader.election.enable=true. Kui see on seadistatud false, siis vahetust ei toimuks ja kõik lugemis- ja kirjutamisettepanekud lükataks tagasi. Sel juhul ootame brokkert 1 naasmist koos tema puutumatute andmetega replikas, mis taasliidaks.

Joonis 11. Brokker 1 kukub. Rikke korral kaob suur hulk sõnumeid.

Tootja loob ühenduse viimase brokkeriga ja näeb, et see on nüüd jao liider. Ta hakkab saatma sõnumeid brokkerile 3.

Joonis 12. Pärast lühikest pausi saadetakse sõnumid taas jao 0.

Oleme näinud, et peale lühikestest katkestustest uute ühenduste loomisel ja uue juhi otsimisel, saatis tootja pidevalt sõnumeid. Selline konfiguratsioon tagab kättesaadavuse andmete järjepidevuse arvelt. Kafka kaotas tuhandeid sõnumeid, kuid jätkas uute kirgede vastuvõtmist.

Acks=all ja ISR

Korratakse seda stsenaariumi veelkord, kuid acks=all. Brokeri 3 viivitus on keskmiselt neli sekundit. Tootja saadab sõnumi acks=all, ja nüüd ei saa ta kiiret vastust. Juht ootab, kuni sõnum on kõikide replikate poolt ISR-is salvestatud.

Joonis 13. ISR kolme replikaga. Üks töötab aeglaselt, mis toob kaasa salvestamise viivituse.

Pärast nelja sekundi pikka täiendavat viivitust saadab broker 2 ack. Kõik replikad on nüüd täielikult ajakohased.

Joonis 14. Kõik replikad salvestavad sõnumid ja saadetakse ack.

Broker 3 jääb nüüd veelgi maha ja eemaldatakse ISR-ist. Viivitus väheneb märgatavalt, kuna ISR-is ei ole enam aeglaseid replikasid. Broker 2 ootab nüüd ainult broker 1, kellel on keskmine viivitus 500 ms.

Joonis 15. Replika brokeris 3 eemaldatakse ISR-ist.

Siis kukub broker 2 ja juhtimine läheb brokerile 1 ilma sõnumite kaota.

Joonis 16. Broker 2 kukub.

Tootja leiab uue juhi ja hakkab talle sõnumeid saatma. Viivitus väheneb veelgi, kuna nüüd koosneb ISR ühest replikast! Seetõttu valik acks=all ei lisa üleliigsust.

Joonis 17. Replika brokeris 1 võtab juhtimise ilma sõnumite kaota.

Siis kukub broker 1 ja juhtimine läheb brokerile 3 koos 14238 sõnumi kaotusega!

Joonis 18. Broker 1 sureb, samas kui juhtimise üleminek unclean seadistusega viib ulatuslikku andmekadudeni

Me ei peaks võib-olla valikut seadma unclean.leader.election.enable väärtuse true. Vaikimisi on see false. Seadistus acks=all koos unclean.leader.election.enable=true tagab kergelt suurendatud andmete turvalisuse. Kuid nagu näete, võime ikkagi sõnumeid kaotada.

Aga mis siis, kui soovime andmete turvalisust suurendada? Saame seada unclean.leader.election.enable = false, kuid see ei kaitse meid tingimata andmekadude eest. Kui juht on kõvasti langend ja viis andmed endaga, siis sõnumid on endiselt kadunud, lisaks kaob kergelt kättesaadavus, kuni administraator olukorra taastab.

Parim on tagada, et kõik sõnumid oleksid üleliigsed, vastasel juhul tuleks loobuda salvestamisest. Nii on vähemalt brokeri seisukohast andmekadu võimalik ainult kahe või enama samaaegse tõrke korral.

Acks=all, min.insync.replicas ja ISR

Teema konfiguratsiooniga min.insync.replicas suurendame andmete turvalisuse taset. Vaadakem veel kord üle eelmise stsenaariumi viimane osa, kuid seekord koos min.insync.replicas=2.

Nii et brokeril 2 on repliikide juht ja järgija brokeril 3 on ISR-ist eemaldatud.

Joonis 19. ISR, kus on kaks repliiki

Broker 2 kukub ja juhtpositsioon läheb Broker 1-ile ilma sõnumite kaotuseta. Kuid nüüd koosneb ISR vaid ühest replikast. See ei vasta minimaalsetele nõuetele kirje saamiseks ja seetõttu vastab broker kirjutamiskatses veaga. NotEnoughReplicas.

Joonis 20. ISR number on üks vähem kui min.insync.replicas-s.

See konfiguratsioon ohverdab kättesaadavuse järjepidevuse nimel. Enne sõnumi kinnitamise võimaldamist tagame, et see salvestatakse vähemalt kahele replikale. See annab tootjale palju suurema kindluse. Siin on sõnumite kaotamine võimalik ainult juhul, kui kaks replikat ebaõnnestuvad samal ajal lühikese aja jooksul, kuni sõnum ei ole lisajälgijale replitseeritud, mis on ebatõenäoline. Kuid kui olete superparanoiline, võite seada replikatsioonikordaja 5, ja min.insync.replicas 3. Siin peab korraga kolm brookerit kokku kukkuma, et kirje kaotada! Muidugi maksate sellise usaldusväärsuse eest täiendava viivituse.

Kui kättesaadavus on vajalik andmete turvalisuse tagamiseks

Nii nagu RabbitMQ puhul, mõnikord on kättesaadavus vajalik andmete turvalisuse tagamiseks. Tuleb mõelda järgnevatele asjadele:

• Kas saab väljaandja lihtsalt vea tagastada, nii et kõrgem teenus või kasutaja proovib hiljem uuesti?
• Kas avaldaja saab sõnumi kohapeal või andmebaasis salvestada, et hiljem uuesti proovida?

Kui vastus on eitav, siis kergendab kättesaadavuse optimeerimine andmete turvalisust. Te kaotate vähem andmeid, kui valite kättesaadavuse, mitte kirjutise keelamise. Kõik sõltub tasakaalu leidmisest ja otsus sõltub konkreetsest olukorrast.

ISR mõte

ISR komplekt võimaldab leida parima tasakaalu andmete turvalisuse ja latentsuse vahel. Näiteks tagab see kättesaadavuse enamikus koopia rikeolukordades, minimeerides samal ajal surnud või aeglaste koopia mõju latentsuse osas.

Me ise valime väärtuse replica.lag.time.max.ms vastavalt oma vajadustele. Sisuliselt tähendab see parameeter, kui suure latentsuse oleme valmis aktsepteerima acks=all. Vaikimisi on see kümme sekundit. Kui see on teie jaoks liiga kaua, saate seda vähendada. Sel juhul suureneb ISR-i muutuste sagedus, kuna järgijad eemaldatakse ja lisatakse sagedamini.

RabbitMQ on lihtsalt peeglite komplekt, mida tuleb replikeerida. Aeglasemad peeglid toovad kaasa lisaläbivuse, ja surnud peeglite vastust võib oodata kuni pakettide eluea möödumiseni, mis kontrollib iga sõlme saadavust (net tick). ISR on huvitav viis nende edasilükkamiste probleemide vältimiseks. Kuid me riskime, et kaotame üleliigsuse, kuna ISR võib langeda ainult liidri tasemele. Selle riski vältimiseks kasutage konfiguratsiooni. min.insync.replicas.

Kliendiühenduse garantii

Seadetes bootstrap.servers tootjana ja tarbijana saab määrata mitu brokermüüjat kliendi ühendamiseks. Idee on selles, et ühe sõlme väljalülitamisel on paar varusõlme, millega klient saab ühenduse luua. Need ei pea olema osa liidrist, vaid lihtsalt platvorm alglaadimiseks. Klient võib küsida nende käest, millisel sõlmel asub jaotuse liider lugemiseks/kirjutamiseks.

RabbitMQ-s saavad kliendid ühenduda iga sõlmega, samas kui sisemine marsruutimine saadab päringud õigesse kohta. See tähendab, et saate seadistada RabbitMQ ette koormuse tasakaalustaja. Kafka nõuab, et kliendid ühenduksid sõlmega, kus asub vastava jao juht. Sellises olukorras ei saa koormuse tasakaalustajat paigaldada. Loend bootstrap.servers on kriitilise tähtsusega, et kliendid saaksid pöörduda sobivate sõlmede poole ja leida need pärast rikkeid.

Kafka konsensuse arhitektuur

Kuni praeguseni ei ole me arutanud, kuidas klaster saab teada brokermi kukkumisest ja kuidas valitakse uus juht. Et mõista, kuidas Kafka töötab võrgu jagunemistega, tuleb esmalt mõista konsensuse arhitektuuri.

Iga Kafka klaster paigaldatakse koos Zookeeperi klastriga — see on jaotatud konsensuse teenus, mis võimaldab süsteemil saavutada konsensust mingis eelnevalt määratletud seisundis, andes prioriteedi järjepidevusele üle kättesaadavuse. Lugemist ja kirjutamist käsitlevate toimingute heakskiitmiseks nõutakse enamiku Zookeeperi sõlmede nõusolekut.

Zookeeper salvestab klandi seisundi:

• Teemade, jaotuste, konfiguratsiooni, praeguste juhtide ja eelistatud koopiate nimekiri.
• Klastri liikmed. Iga maakler pings Zookeperisse. Kui see ei saa teatud aja jooksul pinget, registreerib Zookeeper maakleri mitteühtlasena.
• Peamise ja varu sõlme valimine kontrollerile.

Kontroller sõlm on üks Kafka maakleritest, mis vastutab replikate juhtide valimise eest. Zookeeper saadab kontrollerile teateid klastri liikmetest ja teema muudatustest, ning kontroller peab tegutsema vastavalt nendele muudatustele.

Näiteks võtame uue teema, millel on kümme jaotust ja replikatsiooni koefitsient 3. Kontroller peab valima iga jaotuse juhi, püüdes optimaalselt jaotada juhte maaklerite vahel.

Iga jaotuse puhul kontroller:

• uuendab Zookeeperis teavet ISR ja juhi kohta;
• saadetakse kätte LeaderAndISRCommand igale maaklerile, mis majutab selle jaotuse koopiat, teavitades maaklereid ISR ja juhist.

Kui maakler, kellele juht kuulub, kukub, saadab Zookeeper teate kontrollerile, kes valib uue juhi. Kontroller värskendab esmalt Zookeeperit ja seejärel saadab igale maaklerile käsku, teavitades neid juhtimismuutusest.

Iga juht vastutab ISR-i määramise eest. Konfiguratsioon replica.lag.time.max.ms määreb, kes sinna kuulub. ISR-i muutumisel edastab juht Zookeeperile uue teabe.

Zookeeper on alati teadlik kõigist muutustest, et juhtimine saaks sujuvalt uuele juhile üle minna juhuks, kui esinevad probleemid.

Joon. 21. Kafka konsensus

Replikatsiooniprotokoll

Replikatsiooni üksikasjade mõistmine aitab paremini mõista võimalikke andmete kadu stsenaariume.

Tõmbepäringud, Log End Offset (LEO) ja Highwater Mark (HW)

Oleme arutanud, et järgijad saadavad perioodiliselt juhile tõmbepäringuid (fetch). Vaikeintervall on 500 ms. See erineb RabbitMQ-st, kus replikatsioon algatatakse mitte järjekorra peeglist, vaid peameistrist. Peameister edastab muudatused peeglitele.

Juht ja kõik jälgijad säilitavad logi lõpu nihke (Log End Offset, LEO) ja Highwater (HW) märgi. LEO märk hoiab kohaliku koopia viimase sõnumi nihet, samas kui HW tähistab viimase commit'i nihet. Pidage meeles, et 'commit' oleku puhul peab sõnum olema salvestatud kõigis replikates ISR. See tähendab, et LEO on tavaliselt HW-st veidi ettepoole.

Kui juht saab sõnumi, salvestab ta selle kohapeal. Jälgija esitab päringu, edastades oma LEO. Siis saadab juht sõnumite paketi alates sellest LEO-st ning edastab ka hetkelise HW. Kui juht saab kinnituse, et kõik replikad on salvestanud sõnumi antud nihkega, liigutab ta HW märk. Ainult juht saab HW-d liigutada, ja seega saavad kõik jälgijad oma päringute vastustes praeguse väärtuse teada. See tähendab, et jälgijad võivad jääda juhist maha nii sõnumite kui ka HW teadlikkuse osas. Tarbijad saavad sõnumeid ainult kuni praeguse HW-ni.

Pange tähele, et „salvestatud“ (persisted) tähendab mälu, mitte ketast. Toimivuse nimel synchroniseerib Kafka andmed kettale teatud intervalli järel. RabbitMQ-l on samuti selline intervall, kuid see saadab kinnituse veebilehe omanikule alles pärast seda, kui peamine ja kõik peeglid on sõnumi kettale salvestanud. Kafka arendajad otsustasid toimivuse kaalutlustel saata ack kohe, kui sõnum on mällu salvestatud. Kafka loodab, et üleliigsus kompenseerib lühiajalise riski, et kinnitatud sõnumid on ainult mälus.

Juhi nõrgenemine

Kui juht kukub välja, teavitab Zookeeper kontrollerit, kes valib uue juhi repliigi. Uus juht määrab uue HW märgi vastavalt oma LEO-le. Seejärel saavad järgijad teavet uue juhi kohta. Sõltuvalt Kafka versioonist valib järgija ühe kahest stsenaariumist:

1. Lõikab kohaliku logi teadaoleva HW-ni ja saadab uuele juhile päringu sellest märgist pärast sõnumeid.
2. Saadetakse liidrile päring, et teada saada HW tema valimise hetkel liidriks, ja seejärel kärbitakse logi kuni selle nihkeni. Alustatakse seejärel perioodilisi päringuid valimise korraldamiseks, alustades sellest nihkest.

Järgneval võib olla vajalik logi kärpida järgmiste põhjuste tõttu:

• Kui liider ebaõnnestub, siis esimene järgija ISR-kogumist, kes on registreeritud Zookeeperis, võidab valimised ja saab liidriks. Kõik järgijad ISR-is, kuigi neid peetakse „sünkroniseerituks“, ei pruugi endiselt vana liidrilt kõiki sõnumeid koopiaid saada. On täiesti võimalik, et valitud järgijal ei ole kõige ajakohasemat koopiat. Kafka garanteerib, et replika vahel ei ole erinevusi. Seetõttu peab iga järgija oma logi kärpima uue liidri HW väärtuseni tema valimise hetkel, et vältida erinevusi. See on veel üks põhjus, miks seadistamine acks=all on ühtsuse jaoks nii oluline.
• Sõnumid salvestatakse perioodiliselt kettale. Kui kõik klastris olevad sõlmed ebaõnnestuvad, jäävad kettale salvestatud koopiad erineva nihkega. On täiesti võimalik, et kui maaklerid naasevad võrku, valitakse uus juht, kes võib oma jälgijatest maha jääda, kuna ta salvestati kettale enne teisi.

Taaskoondumine klasstriga

Klastriga taaskoondumisel saavad koopiad samamoodi nagu juhi ebaõnnestumise korral: nad kontrollivad juhi koopiat ja lõikavad oma logi tema HW (valimise hetkel) järgi. Võrdluseks, RabbitMQ peab taaskoondunud sõlmi täiesti uuteks. Mõlemas juhul heidab maakler tagasi kõik olemasolevad olekud. Kui kasutatakse automaatset sünkroniseerimist, peab juht koondama absoluutselt kõik praegused andmed uude peegeldusse viisil, et 'kogu maailmal aitab'. Selle operatsiooni ajal ei aktsepteeri juht mingeid lugemis- või kirjutamisoperatsioone. See lähenemine tekitab probleeme suurtes järjekordades.

Kafka on jaotatud logi, mis hoiab kokku rohkem sõnumeid kui RabbitMQ järjekord, kus andmed pärast lugemist järjekorrast eemaldatakse. Aktiivsed järjekorrad peavad olema suhteliselt väikesed. Kuid Kafka on log, millel on oma salvestuspoliitika, mis võib määrata säilitamise kestuse päevades või nädalates. Järjekorra blokeerimise ja täieliku sünkroniseerimise lähenemine on jaotatud logi jaoks absoluuselt vastuvõetamatu. Selle asemel kärbivad Kafka jälgijad lihtsalt oma logi HW juhtpositsioonile (selle valimise ajal), kui nende koopia juhist ette jääb. Tõenäolisemas olukorras, kus jälgija on taga, hakkab ta lihtsalt küsima andmeid, alustades oma praegusest LEO-st.

Uued või uuesti ühendatud jälgijad alustavad väljaspool ISR-i ega osale komiteerimistes. Nad töötavad lihtsalt grupi kõrval, saades sõnumeid nii kiiresti kui võimalik, kuni nad juhtidest järgi jõuavad ja ISR-i sisse astuvad. Siin ei ole blokeerimist ja ei ole vaja kõiki oma andmeid välja visata.

Ühenduse rikkumine

Kafkal on rohkem komponente kui RabbitMQ-l, mistõttu on siin keerukam käitumiste kogum, kui klastris tekib ühenduse katkemine. Kuid Kafka on algselt loodud klastreid silmas pidades, seetõttu on lahendused hästi läbi mõeldud.

Allpool on mõned ühenduse katkemise stsenaariumid:

• Stsenaarium 1. Järgneja ei näe liidrit, kuid näeb Zookeeperit.
• Stsenaarium 2. Liider ei näe ühtegi järgnejat, kuid näeb Zookeeperit.
• Stsenaarium 3. Järgneja näeb liidrit, kuid ei näe Zookeeperit.
• Stsenaarium 4. Liider näeb järgnejaid, kuid ei näe Zookeeperit.
• Stsenaarium 5. Järgneja on täielikult eraldatud nii teistest Kafka sõlmedest kui ka Zookeeperist.
• Stsenaarium 6. Liider on täielikult eraldatud nii teistest Kafka sõlmedest kui ka Zookeeperist.
• Stsenaarium 7. Kafka kontroller ei näe teist Kafka sõlme.
• Stsenaarium 8. Kafka kontroller ei näe Zookeeperit.

Iga stsenaariumi jaoks on ettenähtud oma käitumine.

Stsenaarium 1. Järgneja ei näe liidrit, kuid näeb Zookeeperit

Joon. 22. Stsenaarium 1. ISR kolme koopiaga

Ühenduse katkemine eraldab maakler 3 maakleritest 1 ja 2, kuid mitte Zookeeperist. Maakler 3 ei saa enam päringutele vastata. Aja möödudes replica.lag.time.max.ms ta eemaldatakse ISR-ist ja ei osale sõnumite kinnitamisel. Kui ühendus taastatakse, jätkub ta päringute tegemine ja liitub ISR-iga, kui on saavutanud juhi. Zookeeper jätkab pingide saamist ja arvab, et maakler on elus ja terve.

Joonis 23. Stsenaarium 1. Maakler eemaldatakse ISR-ist, kui temalt ei saa päringut saada vahemikus replica.lag.time.max.ms

Ei ole mingit loogilist jagunemist (split-brain) ega sõlme peatamist nagu RabbitMQ-s. Selle asemel vähendatakse üleliigsust.

Stsenaarium 2. Juht ei näe ühtki jälgijat, kuid näeb jätkuvalt Zookeeperi

Joonis 24. Stsenaarium 2. Juht ja kaks jälgijat

Võrguühenduse katkestamine eraldab juhi jälgijatest, kuid maakler näeb ikka veel Zookeeperi. Nagu esimeses stsenaariumis, kokku tõmbub ISR, kuid seekord ainult juhini, kuna kõik jälgijad lõpetavad päringute saatmise. Taaskord ei ole mingit loogilist jagunemist. Selle asemel tekib uute sõnumite korral üleliigsuse kadu, kuni ühendus taastatakse. Zookeeper jätkab pingide saamist ja arvab, et maakler on elus ja terve.

Joonis 25. Stsenaarium 2. ISR on kokku tõmbunud ainult juhini

Skenaario 3. Jälgija näeb liidrit, aga ei näe Zookeeperi

Jälgija eraldub Zookeeperist, kuid mitte liidri brokerist. Selle tulemusena jätkab jälgija päringute tegemist ja jääb ISR-i liikmeks. Zookeeper ei saa enam pingeid ja registreerib brokera langemise, kuid kuna see on ainult jälgija, pole taastumise järel mingeid tagajärgi.

Kuvatõmmis 26. Skenaario 3. Jälgija jätkab liidrile päringute saatmist

Skenaario 4. Liider näeb jälgijaid, aga ei näe Zookeeperi

Kuvatõmmis 27. Skenaario 4. Liider ja kaks jälgijat

Liider on eraldatud Zookeeperist, kuid mitte järgnevatest jälgijate brokeritest.

Kuvatõmmis 28. Skenaario 4. Liider on isoleeritud Zookeeperist

Mõne aja pärast registreerib Zookeeper brokera langemise ja teavitab sellest kontrollerit. See valib jälgijate seast uue liidri. Siiski jätkab algne liider arvamist, et ta on liider ja jätkab kirjade vastuvõtmist. acks=1. Jälgijad ei saada talle enam päringuid, seega peab ta neid surnud ja üritab ISR-i vähendada vaid enda peale. Kuid kuna tal pole Zookeeperiga ühendust, ei suuda ta seda teha ja loobub edaspidisest kirjade vastuvõtmisest.

Teated acks=all ei saa kinnitust, kuna esmalt ISR sisaldab kõiki koopiaid ja enne neid teated ei jõua. Kui algne juht proovib need ISR-ist eemaldada, ei saa ta seda teha ja lõpetab üldse teadete vastuvõtmise.

Klientidel on peagi märgata juhi vahetust ning nad hakkavad edastama kirjeid uuele serverile. Kui võrk taastub, näeb algne juht, et ta ei ole enam juht ja kärbib oma logi HW väärtuseni, mis oli uuel liidril katkestuse hetkel, et vältida logide lahknevust. Siis hakkab ta saatma päringuid uuele juhile. Kõik algse juhi kirjed, mida uuele juhile ei replikeeritud, on kadunud. See tähendab, et kaotatakse teated, mida algne juht ei kinnitanud nende paarikümne sekundi jooksul, mil kaks juhti töötasid.

Joonis 29. Stsenaarium 4. Juht brokeris 1 muutub järgijaks pärast võrgu taastumist

Stsenaarium 5. Järgija on täielikult eraldatud nii teistest Kafka sõlmedest kui ka Zookeeperist

Järgija on täielikult eraldatud nii teistest Kafka sõlmedest kui ka Zookeeperist. Ta eemaldatakse lihtsalt ISR-ist, kuni võrk taastub, ja siis püüab ta teisi järele.

Joon. 30. Stsenaarium 5. Isoleeritud järgija eemaldatakse ISR-ist

Stsenaarium 6. Juht on täielikult eraldatud nii teistest Kafka sõlmedest kui ka Zookeeperist

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

Juht on täielikult isoleeritud oma järgijatest, kontrollerist ja Zookeeperist. Lühikese ajaperioodi jooksul jätkab ta kirjade vastuvõtmist acks=1.

Joon. 32. Stsenaarium 6. Juhi isoleerimine teistest Kafka sõlmedest ja Zookeeperist

Pärast päringute mitte saamist replica.lag.time.max.ms, püüab ta ISR-i enda peale kokku suruda, kuid ei saa seda teha, kuna ühendust Zookeeperiga pole, siis lõpetab ta kirjade vastuvõtmise.

Samal ajal märgib Zookeeper isoleeritud maakleri kui surnud, ja kontroller valib uue juhi.

Joon. 33. Stsenaarium 6. Kaks juhti

Algne juht saab kirju vastu võtta mõne sekundi jooksul, kuid seejärel lõpetab ta igasuguste sõnumite vastuvõtmise. Klientide uuendused toimuvad iga 60 sekundi tagant viimaste metaandmete jaoks. Neid teavitatakse juhi vahetusest ja nad hakkavad kirju saatma uuele juhile.

Joon. 34. Stsenaarium 6. Tootjad lülituvad uuele juhile

Kuni kaovad kõik kinnitatud kirjed, mis tehti algse liidri poolt alates ühenduse kadumisest. Kui võrk taastatakse, tuvastab algne juht Zookeeperi kaudu, et ta ei ole enam juht. Seejärel kärbib ta oma logi uue juhi HW järgi valimise hetkel ja hakkab saadetama päringuid fännina.

Joon. 35. Stsenaarium 6. Algne juht muutub fänniks pärast võrgu ühenduse taastamist

Selles olukorras võib lühikese perioodi jooksul esineda loogiline jagunemine, kuid ainult kui acks=1 ja min.insync.replicas ka 1. Loogiline jagunemine lõpeb automaatselt kas pärast võrgu taastamist, kui algne juht mõistab, et ta ei ole enam juht, või kui kõik kliendid mõistavad, et juht on muutunud ja hakkavad kirjutama uuele juhile — olenevalt sellest, mis juhtub varem. Nii või teisiti toimub mõnede sõnumite kaotus, kuid ainult acks=1.

On olemas teine ​​selle stsenaariumi variant, kus kohe enne võrgu jagamist jäävad jälgijad maha ja juht tihendab ISR kuni enda isikuni. Siis isoleeritakse ta ühenduse kadumise tõttu. Valitakse uus juht, kuid algne juht jätkab kirjade vastuvõtmist, isegi acks=all, kuna ISR-is pole kedagi peale tema. Need kirjad kaovad võrgu taastumise järel. Ainus viis sellise stsenaariumi vältimiseks on min.insync.replicas = 2.

Stsenaarium 7. Kafka juhtrõngas ei näe teist Kafka sõlme

Üldiselt, pärast ühenduse kaotamist Kafka sõlmega ei suuda juht edastada sellele mingeid teavet juhi muutmise kohta. Halvimal juhul toob see kaasa lühiajalise loogilise eraldumise, nagu stsenaariumis 6. Tõenäolisemalt ei saa maakler lihtsalt juhtkandidaadiks, kui viimane ebaõnnestub.

Stsenaarium 8. Kafka juht ei näe Zookeeperit

Kui Zookeeperi kontrollija on kadunud, ei saa see pinget ja valib uut Kafka sõlme kontrollijana. Algne kontrollija võib endiselt esindada ennast kui kontrollijat, kuid ta ei saa Zookeeperilt teateid, seega ei ole tal ühtegi ülesannet täitmiseks. Kui võrk taastub, mõistab ta, et ei ole enam kontrollija, vaid on muutunud tavaliseks Kafka sõlmeks.

Järeldused stsenaariumeist

Nähtav on, et jälgijate ühenduse kaotus ei too kaasa sõnumite kaotust, vaid lihtsalt ajutiselt vähendab üleliigsust, kuni võrk taastub. See võib loomulikult viia andmete kadumiseni, kui üks või mitu sõlme on kaotsis.

Kui juht kaotab ühenduse Zookeeperiga, võib see viia sõnumite kadumiseni acks=1. Ühenduse puudumine Zookeeperiga põhjustab lühiajalise loogilise jagunemise kahe juhi vahel. Selle probleemi lahendab parameeter acks=all.

Parameeter min.insync.replicas kahes või enamas koopias, mis annab täiendavaid garantiisid, et sellised lühiajalised stsenaariumid ei too kaasa sõnumite kaotust, nagu stsenaariumis 6.

Kokkuvõte sõnumite kaotusest

Loetleme kõik viisid, kuidas andmeid Kafka's kaotada võib:

• Iga juhi tõrge, kui sõnumid kinnitati kasutades acks=1
• Iga ebatäpne (unclean) juhtimise üleminek, st järgija piiridest väljapoole ISR, isegi acks=all
• Juhi isoleerimine Zookeeperist, kui sõnumid kinnitati kasutades acks=1
• Täielik juhi isoleerimine, kes on juba vähendanud ISR grupi iseendaks. Kõik sõnumid kaovad, isegi acks=all. See kehtib ainult juhul, kui min.insync.replicas=1.
• Kõikide jaotuse sõlmede samaaegne tõrge. Kuna sõnumid kinnitatakse mälust, võivad mõned veel mitte kettale salvestuda. Pärast serverite taaskäivitamist võib puududa mõni sõnum.

Ebatäpsete juhtimisüleminekute vältimiseks saab kas neid keelata või tagada vähemalt kahe peale. Kõige usaldusväärsem konfiguratsioon on kombinatsioon acks=all ja min.insync.replicas rohkem kui 1.

RabbitMQ ja Kafka usaldusväärsuse otsene võrdlemine

Kuna usaldusväärsuse ja kõrge kättesaadavuse tagamiseks rakendavad mõlemad platvormid primaarse ja sekundaarse replikatsiooni süsteemi. Kuid RabbitMQ-l on oma nõrk koht. Ühenduse taastamisel pärast riket viskavad sõlmed oma andmed ära ja sünkroniseerimine peatub. See kahekordne löök seab kahtluse alla suurte järjekordade kestvuse RabbitMQ-s. Peate leppima kas vähendatud üleliigsusega või pikaajaliste lukustustega. Üksnes üleliigsuse vähendamine suurendab massilise andmekao riski. Kuid kui järjekorrad on väikesed, on üleliigsuse kindlustamiseks lühikeste toodete katkemistega (mõned sekundid) võimalik toime tulla uuesti ühenduse loomise katsete abil.

Kafkas ei ole sellist probleemi. See loob andmeid tagasi ainult siis, kui liidri ja järgija vahel on erinevus. Kõik ühised andmed säilitatakse. Lisaks ei blokeeri replikatsioon süsteemi. Liider jätkab kirjade vastuvõtmist, kuni uus järgija tema järele jõuab, nii et DevOps'i jaoks on klastrisse liitmine või uuesti liitmine triviaalne ülesanne. Muidugi jäävad endiselt probleemid, nagu võrgu läbilaskevõime replikatsiooni ajal. Kui mitu järgijat lisatakse samal ajal, võib esineda läbilaskevõime piirangut.

RabbitMQ ületab Kafkat usaldusväärsuses, kui mitu serverit klastris kokku kuivavad. Nagu me juba mainisime, saadab RabbitMQ avaldaja kinnituse alles pärast sõnumi kirjutamist meistrisse ja kõikidesse peegeldustesse. Kuid see toob kaasa täiendava viivituse kahes osas:

• fsync iga paari sadade millisekundi tagant
• Peegli rike võib olla märgatav alles siis, kui pakettide eluea ajal, mis kontrollib iga sõlme kättesaadavust (net tick), on möödunud. Kui peegel reageerib aeglaselt või on kokku kukkunud, lisab see viivituse.

Kafka usubub, et kui sõnum on talletatud mitmel sõlmel, saab sõnumeid kinnitada kohe, kui need mällu jõuavad. Selle tõttu tekib riski igasuguste sõnumite (isegi acks=all, min.insync.replikad=2) kaotamise korral samaaegse tõrke korral.

Üldiselt näitab Kafka kõrgemat jõudlust ja on algselt loodud klastrite jaoks. Jälgijate arvu saab suurendada kuni 11-ni, kui see on vajalik usaldusväärsuse tagamiseks. Replikatsioonikoefitsient 5 ja minimaalne sünkroonsete replikate arv min.insync.replicas=3 teevad sõnumite kaotuse väga harvaks juhuseks. Kui teie infrastruktuur suudab tagada sellise replikatsioonikoefitsiendi ja üleliigsuse taseme, siis võite valida selle variandi.

RabbitMQ klasterdamine sobib hästi väikestele järjekordadele. Kuid isegi väikesed järjekorrad võivad suure liikluse korral kiiresti kasvama hakata. Kui järjekorrad muutuvad suurteks, tuleb teha karm valik saadaolevuse ja usaldusväärsuse vahel. RabbitMQ klasterdamine sobib kõige paremini ebatavaliste olukordade jaoks, kus RabbitMQ paindlikkuse eelised kaaluvad üles kõik klasterdamise puudused.

Üks ravimeetod suurte RabbitMQ järjekordade haavatavuse vastu on jagada need väiksemateks. Kui ei nõuta kogu järjekorra täielikku järjestust, vaid ainult teatud sõnumite (näiteks konkreetse kliendi sõnumite) või mitte midagi järjestada, on see variant vastuvõetav: vaadake minu projekti. Rebalanser järjekorra jagamiseks (projekt on hetkel varajases staadiumis).

Lõpuks, ärge unustage mitmeid vigu nii RabbitMQ kui ka Kafka klasterdamise ja replikatsiooni mehhanismides. Aja jooksul on süsteemid muutunud kypsamaks ja stabiilsemaks, kuid ükski sõnum ei ole kunagi 100% kaitstud kadumise eest! Lisaks võivad andmekeskustes juhtuda ulatuslikud õnnetused!

Kui ma midagi jätsin vahele, tegin vea või te ei nõustu mõne väitega, uurige julgelt kommenteerida või minuga ühendust võtta.

Mind küsitakse sageli: „Mida valida, Kafka või RabbitMQ?“, „Milline platvorm on parem?“. Tõde on see, et see sõltub tõeliselt teie olukorrast, hetke kogemusest jne. Ma ei julge oma arvamust avaldada, sest oleks liiga suur üldistus soovitada ühte platvormi kõikide kasutusjuhtumite ja võimalike piirangute jaoks. Kirjutasin selle artiklite tsükli, et saaksite oma arvamuse kujundada.

Tahaksin öelda, et mõlemad süsteemid on selles valdkonnas liidrid. Võib-olla olen ma pisut kallutatud, kuna oma projektide kogemuste põhjal hindan rohkem selliseid aspekte nagu sõnumite garanteeritud järjestus ja usaldusväärsus.

Näen teisi tehnoloogiaid, millel puudub see usaldusväärsus ja garanteeritud järjestus, vaatan seejärel RabbitMQ ja Kafka poole — ja mõistan nende kahe süsteemi tohutut väärtust.

Allikas: habr.com