В posledný článok pozreli sme sa na klastrovanie RabbitMQ z hľadiska odolnosti voči chybám a vysokej dostupnosti. Teraz poďme hlbšie do Apache Kafka.

Jednotkou replikácie je tu oddiel. Každá téma má jednu alebo viac sekcií. Každá sekcia má lídra s nasledovníkmi alebo bez nich. Pri vytváraní témy zadávate počet oddielov a koeficient replikácie. Zvyčajná hodnota je 3, čo znamená tri repliky: jeden vodca a dvaja nasledovníci.

Ryža. 1. Štyri sekcie sú rozdelené medzi troch maklérov

Všetky požiadavky na čítanie a zápis idú vedúcemu. Nasledovníci pravidelne posielajú požiadavky vedúcemu, aby dostal najnovšie správy. Spotrebitelia sa nikdy neobracajú na nasledovníkov, tí druhí existujú len kvôli redundancii a odolnosti voči chybám.

Zlyhanie oddielu

Keď zlyhá maklér, často zlyhajú vedúci viacerých sekcií. V každom z nich sa vodcom stáva nasledovník z iného uzla. V skutočnosti to tak nie je vždy, pretože faktor synchronizácie tiež ovplyvňuje: či existujú synchronizovaní sledovatelia, a ak nie, či je povolený prechod na nesynchronizovanú repliku. Ale nekomplikujme to nateraz.

Maklér 3 opustí sieť a u makléra 2 sa zvolí nový vodca pre sekciu 2.

Ryža. 2. Maklér 3 zomrie a jeho nasledovník na brokerovi 2 je zvolený za nového vodcu oddielu 2

Potom maklér 1 odíde a aj sekcia 1 stratí svojho vodcu, ktorého úloha prechádza na makléra 2.

Ryža. 3. Zostáva jeden maklér. Všetci lídri sú pod jedným maklérom s nulovou redundanciou

Keď sa maklér 1 vráti do režimu online, pridá štyroch sledovateľov, čím každému oddielu poskytne určitú redundanciu. Všetci lídri však stále zostali na brokerovi 2.

Ryža. 4. Lídri zostávajú u makléra 2

Keď sa objaví broker 3, sme späť k trom replikám na oddiel. Ale všetci lídri sú stále u brokera 2.

Ryža. 5. Nevyvážené umiestnenie lídrov po obnovení brokerov 1 a 3

Kafka má nástroj na lepšie vyváženie lídrov ako RabbitMQ. Tam ste museli použiť doplnok alebo skript tretej strany, ktorý zmenil zásady migrácie hlavného uzla znížením redundancie počas migrácie. Pre veľké fronty sme navyše museli akceptovať nedostupnosť počas synchronizácie.

Kafka má koncepciu „preferovaných replík“ pre rolu vodcu. Keď sú vytvorené tematické oddiely, Kafka sa pokúša rozdeliť lídrov rovnomerne medzi uzly a označí týchto prvých lídrov ako preferovaných. Postupom času, kvôli reštartom servera, zlyhaniam a výpadkom pripojenia, môžu lídri skončiť na iných uzloch, ako je to v extrémnom prípade opísanom vyššie.

Na vyriešenie tohto problému ponúka Kafka dve možnosti:

• Možnosť auto.leader.rebalance.enable=true umožňuje riadiacemu uzlu automaticky priradiť lídrov späť k preferovaným replikám a tým obnoviť rovnomernú distribúciu.
• Administrátor môže skript spustiť kafka-preferovaná-replika-volby.sh na manuálne preradenie.

Ryža. 6. Repliky po opätovnom vyvážení

Toto bola zjednodušená verzia zlyhania, ale realita je zložitejšia, aj keď tu nie je nič komplikované. Všetko sa týka synchronizovaných replík (In-Sync Replicas, ISR).

Synchronizované repliky (ISR)

ISR je množina replík oddielu, ktorý sa považuje za „synchronizovaný“ (in-sync). Existuje vodca, ale nemusia existovať nasledovníci. Nasledovateľ sa považuje za synchronizovaného, ​​ak pred uplynutím intervalu vytvoril presné kópie všetkých správ vedúceho doba oneskorenia repliky max.ms.

Nasledovník je odstránený zo sady ISR, ak:

• nepožiadali o výber intervalu doba oneskorenia repliky max.ms (predpokladá sa mŕtvy)
• sa nepodarilo aktualizovať počas intervalu doba oneskorenia repliky max.ms (považuje sa za pomalé)

Nasledovníci robia požiadavky na vzorkovanie v intervale replica.fetch.wait.max.ms, ktorá je predvolená na 500 ms.

Aby sme jasne vysvetlili účel ISR, musíme sa pozrieť na potvrdenia od výrobcu a niektoré scenáre zlyhania. Výrobcovia si môžu vybrať, kedy maklér pošle potvrdenie:

• acks=0, potvrdenie sa neodošle
• acks=1, potvrdenie sa odošle potom, čo vedúci zapíše správu do svojho lokálneho denníka
• acks=all, potvrdenie sa odošle, keď všetky repliky v ISR zapíšu správu do lokálnych protokolov

V Kafkovej terminológii, ak ISR uložil správu, je „odovzdaná“. Acks=all je najbezpečnejšia možnosť, ale pridáva aj ďalšie oneskorenie. Pozrime sa na dva príklady zlyhania a na to, ako rôzne možnosti „potvrdenia“ interagujú s konceptom ISR.

Acks = 1 a ISR

V tomto príklade uvidíme, že ak vedúci nečaká na uloženie každej správy od všetkých sledovateľov, potom je možná strata údajov, ak vedúci zlyhá. Navigáciu k nesynchronizovanému sledovateľovi je možné povoliť alebo zakázať nastavením nečistý.vodca.voľby.umožniť.

V tomto príklade má výrobca hodnotu acks=1. Sekcia je distribuovaná medzi všetkých troch maklérov. Broker 3 je pozadu, pred ôsmimi sekundami sa synchronizoval s lídrom a teraz zaostáva o 7456 1 správ. Broker XNUMX zaostal len o jednu sekundu. Náš producent pošle správu a rýchlo dostane späť potvrdenie, bez réžie pomalých alebo mŕtvych nasledovníkov, na ktorých vodca nečaká.

Ryža. 7. ISR s tromi replikami

Broker 2 zlyhá a producent dostane chybu pripojenia. Po prechode vedenia na makléra 1 stratíme 123 správ. Nasledovník na brokerovi 1 bol súčasťou ISR, ale nebol plne synchronizovaný s lídrom, keď padol.

Ryža. 8. Správy sa stratia, keď sa zrúti

V konfigurácii bootstrap.servery Výrobca má uvedených niekoľko maklérov a môže sa opýtať iného makléra, kto je novým vedúcim sekcie. Potom nadviaže spojenie s maklérom 1 a pokračuje v odosielaní správ.

Ryža. 9. Odosielanie správ sa obnoví po krátkej prestávke

Broker 3 je ešte viac pozadu. Vytvára požiadavky na načítanie, ale nemôže sa synchronizovať. Môže to byť spôsobené pomalým sieťovým pripojením medzi maklérmi, problémom s úložiskom atď. Je odstránený z ISR. Teraz ISR pozostáva z jednej repliky - vodcu! Výrobca pokračuje v odosielaní správ a prijímaní potvrdení.

Ryža. 10. Nasledovník na brokerovi 3 je odstránený z ISR

Broker 1 klesá a vedúcu úlohu preberá maklér 3 so stratou 15286 správ! Výrobca dostane hlásenie o chybe pripojenia. Prechod na lídra mimo ISR bol možný len vďaka nastaveniu unclean.leader.election.enable=true. Ak je nainštalovaný v nepravdivý, potom by prechod nenastal a všetky požiadavky na čítanie a zápis by boli zamietnuté. V tomto prípade čakáme, kým sa maklér 1 vráti so svojimi neporušenými údajmi v replike, ktorý opäť prevezme vedenie.

Ryža. 11. Broker 1 padá. Keď dôjde k zlyhaniu, stratí sa veľké množstvo správ

Producent nadviaže spojenie s posledným maklérom a vidí, že teraz je vedúcim sekcie. Začne posielať správy maklérovi 3.

Ryža. 12. Po krátkej prestávke sa správy znova odošlú do sekcie 0

Videli sme, že okrem krátkych prestávok na nadväzovanie nových spojení a hľadanie nového lídra výrobca neustále posielal správy. Táto konfigurácia zabezpečuje dostupnosť na úkor konzistencie (bezpečnosť dát). Kafka stratil tisíce správ, no naďalej prijímal nové správy.

Acks=all a ISR

Zopakujme tento scenár ešte raz, ale s acks=všetko. Broker 3 má priemernú latenciu štyri sekundy. Výrobca pošle správu s acks=všetkoa teraz nedostáva rýchlu odpoveď. Vedúci čaká na uloženie správy všetkými replikami v ISR.

Ryža. 13. ISR s tromi replikami. Jeden je pomalý, čo má za následok oneskorenie nahrávania

Po štyroch sekundách dodatočného oneskorenia sprostredkovateľ 2 pošle potvrdenie. Všetky repliky sú teraz plne aktualizované.

Ryža. 14. Všetky repliky ukladajú správy a odosielajú potvrdenie

Broker 3 teraz zaostáva ďalej a je odstránený z ISR. Latencia je výrazne znížená, pretože v ISR nezostali žiadne pomalé repliky. Broker 2 teraz čaká len na makléra 1 a ten má priemerné oneskorenie 500 ms.

Ryža. 15. Replika na brokera 3 je odstránená z ISR

Potom maklér 2 padne a vedenie prechádza na makléra 1 bez straty správ.

Ryža. 16. Broker 2 padá

Výrobca si nájde nového lídra a začne mu posielať správy. Latencia je ďalej znížená, pretože ISR teraz pozostáva z jednej repliky! Preto možnosť acks=všetko nepridáva nadbytočnosť.

Ryža. 17. Replika na brokerovi 1 preberá vedenie bez straty správ

Potom maklér 1 havaruje a vedie maklér 3 so stratou 14238 správ!

Ryža. 18. Broker 1 zomrie a prechod vedenia s nečistým nastavením vedie k rozsiahlej strate údajov

Nepodarilo sa nám nainštalovať možnosť nečistý.vodca.voľby.umožniť do významu pravdivý. V predvolenom nastavení je rovnaký nepravdivý. nastavenie acks=všetko с unclean.leader.election.enable=true poskytuje dostupnosť s určitým pridaným zabezpečením údajov. Ale ako vidíte, stále môžeme stratiť správy.

Čo ak však chceme zvýšiť bezpečnosť dát? Môžete dať unclean.leader.election.enable = false, ale to nás nevyhnutne neochráni pred stratou údajov. Ak vodca tvrdo spadol a vzal so sebou údaje, správy sa stále stratia a dostupnosť sa stratí, kým správca neobnoví situáciu.

Je lepšie zabezpečiť, aby boli všetky správy nadbytočné, a inak nahrávku zahodiť. Vtedy je, aspoň z pohľadu brokera, strata dát možná len v prípade dvoch a viacerých súčasných porúch.

Acks=all, min.insync.replicas a ISR

S konfiguráciou témy min.insync.repliky Zvyšujeme úroveň bezpečnosti údajov. Poďme si ešte raz prejsť poslednú časť predchádzajúceho scenára, ale tentoraz s min.insync.replicas=2.

Takže maklér 2 má repliku vodcu a nasledovník makléra 3 je odstránený z ISR.

Ryža. 19. ISR z dvoch replík

Broker 2 padá a vedenie prechádza na makléra 1 bez straty správ. Teraz však ISR pozostáva len z jednej repliky. To nespĺňa minimálny počet na príjem záznamov, a preto maklér odpovedá na pokus o zápis chybou NotEnoughReplicas.

Ryža. 20. Počet ISR je o jeden nižší, ako je uvedené v min.insync.replicas

Táto konfigurácia obetuje dostupnosť kvôli konzistencii. Pred potvrdením správy sa ubezpečíme, že je zapísaná aspoň do dvoch kópií. To dáva výrobcovi oveľa väčšiu dôveru. Strata správy je tu možná len vtedy, ak dve repliky zlyhajú súčasne v krátkom intervale, kým sa správa nereplikuje ďalšiemu nasledovníkovi, čo je nepravdepodobné. Ale ak ste super paranoidní, môžete nastaviť replikačný faktor na 5 a min.insync.repliky o 3. Tu musia padnúť traja makléri súčasne, aby stratili rekord! Za túto spoľahlivosť samozrejme platíte dodatočnou latenciou.

Keď je dostupnosť potrebná pre bezpečnosť údajov

Rovnako ako v prípad s RabbitMQ, niekedy je dostupnosť potrebná pre bezpečnosť údajov. Tu je to, na čo musíte myslieť:

• Môže vydavateľ jednoducho vrátiť chybu a požiadať službu alebo používateľa, aby to skúsili znova neskôr?
• Môže vydavateľ uložiť správu lokálne alebo do databázy a skúsiť to znova neskôr?

Ak je odpoveď nie, potom optimalizácia dostupnosti zlepšuje bezpečnosť údajov. Ak namiesto nenahrávania zvolíte dostupnosť, stratíte menej dát. Všetko teda spočíva v nájdení rovnováhy a rozhodnutie závisí od konkrétnej situácie.

Význam ISR

Sada ISR vám umožňuje zvoliť optimálnu rovnováhu medzi bezpečnosťou údajov a latenciou. Zabezpečte napríklad dostupnosť v prípade zlyhania väčšiny replík, čím sa minimalizuje vplyv mŕtvych alebo pomalých replík z hľadiska latencie.

Význam si volíme sami doba oneskorenia repliky max.ms podľa vašich potrieb. Tento parameter v podstate znamená, koľko oneskorenia sme ochotní akceptovať acks=všetko. Predvolená hodnota je desať sekúnd. Ak je to pre vás príliš dlhé, môžete to znížiť. Potom sa frekvencia zmien v ISR zvýši, pretože sledovatelia sa budú odstraňovať a pridávať častejšie.

RabbitMQ je jednoducho súbor zrkadiel, ktoré je potrebné replikovať. Pomalé zrkadlá zavádzajú dodatočnú latenciu a mŕtve zrkadlá môžu čakať, kým pakety, ktoré kontrolujú dostupnosť každého uzla (net tick), zareagujú. ISR je zaujímavý spôsob, ako sa vyhnúť týmto problémom s latenciou. Ale riskujeme stratu nadbytočnosti, pretože ISR sa môže zmenšiť len na lídra. Aby ste predišli tomuto riziku, použite nastavenie min.insync.repliky.

Garancia pripojenia klienta

V nastaveniach bootstrap.servery výrobca a spotrebiteľ môžu určiť viacerých maklérov na pripojenie klientov. Myšlienka je taká, že keď jeden uzol vypadne, zostane niekoľko náhradných, s ktorými môže klient nadviazať spojenie. Nie sú to nevyhnutne vodcovia sekcií, ale jednoducho odrazový mostík pre počiatočné zaťaženie. Klient sa ich môže opýtať, ktorý uzol je hostiteľom vedúceho oddielu na čítanie/zápis.

V RabbitMQ sa klienti môžu pripojiť k akémukoľvek uzlu a interné smerovanie pošle požiadavku tam, kam potrebuje. To znamená, že pred RabbitMQ môžete nainštalovať vyvažovač záťaže. Kafka vyžaduje, aby sa klienti pripojili k uzlu, ktorý je hostiteľom príslušného vedúceho oddielu. V takejto situácii nemôžete nainštalovať vyrovnávač zaťaženia. Zoznam bootstrap.servery Je dôležité, aby klienti mohli pristupovať a nájsť správne uzly po zlyhaní.

Konsenzuálna architektúra Kafku

Doteraz sme sa nezaoberali tým, ako sa klaster dozvie o páde brokera a ako sa volí nový líder. Aby ste pochopili, ako Kafka pracuje so sieťovými oddielmi, musíte najprv porozumieť konsenzuálnej architektúre.

Každý klaster Kafka je nasadený spolu s klastrom Zookeeper, čo je distribuovaná služba konsenzu, ktorá umožňuje systému dosiahnuť konsenzus v určitom danom stave, pričom uprednostňuje konzistenciu pred dostupnosťou. Na schválenie operácií čítania a zápisu je potrebný súhlas väčšiny uzlov Zookeeper.

Zookeeper ukladá stav klastra:

• Zoznam tém, sekcií, konfigurácia, aktuálne repliky lídrov, preferované repliky.
• Členovia klastra. Každý maklér pingne klaster Zookeeper. Ak nedostane ping v stanovenom čase, Zookeeper zaznamená sprostredkovateľa ako nedostupného.
• Výber hlavného a náhradného uzla pre ovládač.

Riadiaci uzol je jedným z Kafkových maklérov, ktorý je zodpovedný za voľbu lídrov replík. Zookeeper posiela kontrolórovi upozornenia o členstve v klastri a zmenách tém a kontrolór musí podľa týchto zmien konať.

Vezmime si napríklad novú tému s desiatimi partíciami a replikačným faktorom 3. Radič musí zvoliť lídra pre každú partíciu, pričom sa snaží optimálne rozdeliť lídrov medzi maklérov.

Pre každý ovládač sekcie:

• aktualizuje informácie v Zookeeper o ISR a vodcovi;
• Odošle LeaderAndISRCommand každému maklérovi, ktorý je hostiteľom repliky tohto oddielu, informuje maklérov o ISR a vodcovi.

Keď maklér s vodcom padne, Zookeeper pošle správu kontrolórovi a ten zvolí nového vodcu. Kontrolór opäť najskôr aktualizuje Zookeepera a potom každému maklérovi pošle príkaz, ktorý ich upozorní na zmenu vedenia.

Každý vodca je zodpovedný za nábor ISR. nastavenie doba oneskorenia repliky max.ms určuje, kto tam vstúpi. Keď sa ISR zmení, vedúci odošle nové informácie Zookeeperovi.

Zookeeper je vždy informovaný o akýchkoľvek zmenách, aby v prípade poruchy vedenie plynulo prešlo na nového vedúceho.

Ryža. 21. Kafkov konsenzus

Replikačný protokol

Pochopenie podrobností o replikácii vám pomôže lepšie pochopiť potenciálne scenáre straty údajov.

Vzorkovanie dopytov, Log End Offset (LEO) a Highwater Mark (HW)

Usúdili sme, že sledovatelia pravidelne posielajú vedúcemu žiadosti o načítanie. Predvolený interval je 500 ms. Toto sa líši od RabbitMQ v tom, že v RabbitMQ replikáciu nespúšťa zrkadlo frontu, ale hlavný server. Majster tlačí zmeny na zrkadlá.

Vedúci a všetci nasledovníci si uložia log End Offset (LEO) a štítok Highwater (HW). Značka LEO ukladá offset poslednej správy v lokálnej replike a HW drží offset posledného odovzdania. Pamätajte, že pre stav potvrdenia musí byť správa zachovaná vo všetkých replikách ISR. To znamená, že LEO je zvyčajne mierne pred HW.

Keď vedúci dostane správu, uloží ju lokálne. Nasledovník odošle svoj LEO žiadosť o vyzdvihnutie. Vedúci potom odošle dávku správ od tohto LEO a tiež odošle aktuálny HW. Keď vedúci dostane informáciu, že všetky repliky uložili správu v danom posune, posunie HW značku. Posúvať HW môže iba vedúci, a tak budú všetci sledovatelia poznať aktuálnu hodnotu v odpovediach na ich požiadavku. To znamená, že nasledovníci môžu za lídrom zaostávať v správe aj v znalostiach HW. Spotrebitelia dostávajú správy len do aktuálneho HW.

Všimnite si, že „pretrvávalo“ znamená zapisovať do pamäte, nie na disk. Kvôli výkonu sa Kafka synchronizuje s diskom v určitom intervale. RabbitMQ má tiež takýto interval, ale potvrdenie pošle vydavateľovi až potom, čo master a všetky zrkadlá zapíšu správu na disk. Vývojári Kafka sa z výkonnostných dôvodov rozhodli poslať potvrdenie hneď, ako sa správa zapíše do pamäte. Kafka vsádza, že redundancia kompenzuje riziko krátkeho uloženia potvrdených správ iba do pamäte.

Zlyhanie vodcu

Keď vodca padne, Zookeeper upozorní kontrolóra a ten vyberie novú repliku vodcu. Nový líder nastavuje novú HW značku podľa svojho LEO. Nasledovníci potom dostanú informácie o novom vodcovi. V závislosti od verzie Kafka si nasledovník vyberie jeden z dvoch scenárov:

1. Skráti lokálny protokol na známy HW a pošle požiadavku novému vedúcemu na správy po tejto značke.
2. Pošle požiadavku vedúcemu, aby zistil HW v čase, keď bol zvolený za vedúceho, a potom skráti protokol na tento offset. Potom začne vykonávať pravidelné požiadavky na načítanie počnúc týmto posunom.

Nasledovateľ môže potrebovať skrátiť denník z nasledujúcich dôvodov:

• Keď vodca zlyhá, prvý nasledovník v súprave ISR registrovanej u Zookeepera vyhrá voľby a stane sa vodcom. Všetci sledovatelia na ISR, hoci sa považujú za „synchronizované“, nemusia dostať kópie všetkých správ od bývalého vodcu. Je celkom možné, že odporúčaný sledovateľ nemá najaktuálnejšiu kópiu. Kafka zabezpečuje, že medzi replikami nie sú žiadne rozdiely. Aby sa predišlo nezrovnalostiam, každý nasledovník musí skrátiť svoj log na HW hodnotu nového lídra v čase jeho zvolenia. To je ďalší dôvod, prečo nastavenie acks=všetko tak dôležité pre konzistenciu.
• Správy sa pravidelne zapisujú na disk. Ak všetky uzly klastra zlyhajú súčasne, potom sa na disky uložia repliky s rôznymi posunmi. Je možné, že keď sa makléri vrátia online, nový líder, ktorý je zvolený, bude za svojimi nasledovníkmi, pretože bol uložený na disku pred ostatnými.

Opätovné stretnutie s klastrom

Pri opätovnom pripájaní sa do klastra repliky robia to isté, ako keď vodca zlyhá: skontrolujú repliku lídra a skrátia svoj protokol na jeho HW (v čase volieb). V porovnaní s tým RabbitMQ rovnako zaobchádza so zjednotenými uzlami ako s úplne novými. V oboch prípadoch maklér zahodí akýkoľvek existujúci stav. Ak sa použije automatická synchronizácia, potom musí master replikovať absolútne všetok aktuálny obsah do nového zrkadla metódou „nech celý svet čaká“. Master počas tejto operácie neakceptuje žiadne operácie čítania ani zápisu. Tento prístup spôsobuje problémy vo veľkých radoch.

Kafka je distribuovaný protokol a vo všeobecnosti ukladá viac správ ako front RabbitMQ, kde sa údaje po prečítaní odstránia z frontu. Aktívne fronty by mali zostať relatívne malé. Kafka je však denník s vlastnou politikou uchovávania, ktorá môže nastaviť obdobie dní alebo týždňov. Prístup blokovania frontu a úplnej synchronizácie je pre distribuovaný protokol absolútne neprijateľný. Namiesto toho Kafkovi nasledovníci jednoducho skrátia svoj denník na HW lídra (v čase jeho zvolenia), ak je ich kópia pred lídrom. V pravdepodobnejšom prípade, keď je nasledovník pozadu, jednoducho začne odosielať požiadavky na načítanie počnúc jeho aktuálnym objektom LEO.

Noví alebo pripojení nasledovníci začínajú mimo ISR a nezúčastňujú sa záväzkov. Jednoducho pracujú vedľa skupiny a prijímajú správy tak rýchlo, ako môžu, kým nedobehnú vodcu a nevstúpia do ISR. Neexistuje žiadne uzamknutie a nie je potrebné vyhodiť všetky svoje údaje.

Strata konektivity

Kafka má viac komponentov ako RabbitMQ, takže má zložitejší súbor správania, keď sa klaster odpojí. Kafka bol ale pôvodne navrhnutý pre klastre, takže riešenia sú veľmi dobre premyslené.

Nižšie je uvedených niekoľko scenárov zlyhania pripojenia:

• Scenár 1: Nasledovateľ nevidí vodcu, ale stále vidí správcu zoo.
• Scenár 2: Vodca nevidí žiadnych nasledovníkov, ale stále vidí Zookeepera.
• Scenár 3: Nasledovateľ vidí vodcu, ale nevidí Zookeepera.
• Scenár 4: Vodca vidí nasledovníkov, ale nevidí Zookeepera.
• Scenár 5: Nasledovník je úplne oddelený od ostatných Kafkových uzlov a Zookeepera.
• Scenár 6: Vodca je úplne oddelený od ostatných Kafkových uzlov a Zookeepera.
• Scenár 7: Uzol ovládača Kafka nevidí iný uzol Kafka.
• Scenár 8: Kafka ovládač nevidí Zookeeper.

Každý scenár má svoje vlastné správanie.

Scenár 1: Nasledovateľ nevidí vodcu, ale stále vidí Zookeepera

Ryža. 22. Scenár 1: ISR troch replík

Zlyhanie pripojenia oddeľuje makléra 3 od maklérov 1 a 2, ale nie od Zookeepera. Broker 3 už nemôže odosielať požiadavky na načítanie. Po uplynutí času doba oneskorenia repliky max.ms je odstránený z ISR a nezúčastňuje sa potvrdenia správ. Po obnovení pripojenia obnoví požiadavky na vyzdvihnutie a pripojí sa k ISR, keď dobehne lídra. Ošetrovateľ bude naďalej dostávať pingy a bude predpokladať, že sprostredkovateľ je živý a zdravý.

Ryža. 23. Scenár 1: Sprostredkovateľ je odstránený z ISR, ak od neho nie je prijatá žiadna požiadavka na vyzdvihnutie v rámci intervalu replika.lag.time.max.ms

Neexistuje žiadne zavesenie rozdeleného mozgu alebo uzla ako v RabbitMQ. Namiesto toho sa znižuje nadbytočnosť.

Scenár 2: Vodca nevidí žiadnych nasledovníkov, ale stále vidí Zookeepera

Ryža. 24. Scenár 2. Vodca a dvaja nasledovníci

Porucha sieťového pripojenia oddeľuje vodcu od sledovateľov, ale sprostredkovateľ stále vidí Zookeeper. Rovnako ako v prvom scenári sa ISR zmenšuje, ale tentoraz iba na vedúceho, pretože všetci nasledovníci prestanú posielať žiadosti o načítanie. Opäť tu nie je žiadne logické delenie. Namiesto toho dochádza k strate redundancie pre nové správy, kým sa pripojenie neobnoví. Ošetrovateľ zoo naďalej dostáva pingy a verí, že maklér je živý a zdravý.

Ryža. 25. Scenár 2. ISR sa scvrkol len na lídra

Scenár 3. Nasledovateľ vidí vodcu, ale nevidí Zookeepera

Nasledovateľ je oddelený od Zookeepera, ale nie od makléra s vodcom. Výsledkom je, že nasledovník naďalej podáva žiadosti o vyzdvihnutie a je členom ISR. Zookeeper už nedostáva pingy a registruje pád brokera, no keďže ide len o followera, po zotavení nenesú žiadne následky.

Ryža. 26. Scenár 3: Nasledovateľ pokračuje v odosielaní žiadostí o vyzdvihnutie vedúcemu

Scenár 4. Vodca vidí nasledovníkov, ale nevidí Zookeepera

Ryža. 27. Scenár 4. Vodca a dvaja nasledovníci

Vodca je oddelený od Zookeepera, ale nie od maklérov s nasledovníkmi.

Ryža. 28. Scenár 4: Vodca izolovaný od Zookeepera

Po určitom čase Zookeeper zaregistruje zlyhanie brokera a upozorní na to správcu. Vyberie si nového vodcu spomedzi svojich nasledovníkov. Pôvodný vedúci si však bude naďalej myslieť, že je to vedúci a bude naďalej prijímať príspevky od acks=1. Nasledovníci mu už neposielajú žiadosti o prinesenie, takže ich bude považovať za mŕtvych a pokúsi sa zmenšiť ISR na seba. Ale keďže nemá spojenie so Zookeeperom, nebude to môcť urobiť a v tom momente odmietne prijať akékoľvek ďalšie záznamy.

správy acks=všetko nedostane potvrdenie, pretože ISR najskôr zapne všetky repliky a správy sa k nim nedostanú. Keď sa ich pôvodný vodca pokúsi odstrániť z ISR, nebude to môcť urobiť a prestane prijímať akékoľvek správy.

Klienti si čoskoro všimnú zmenu lídra a začnú odosielať záznamy na nový server. Akonáhle je sieť obnovená, pôvodný líder vidí, že už nie je lídrom a skráti svoj protokol na HW hodnotu, ktorú mal nový líder v čase zlyhania, aby sa predišlo divergencii protokolu. Potom začne odosielať požiadavky na vyzdvihnutie novému vedúcemu. Všetky záznamy od pôvodného vedúceho, ktoré nie sú replikované do nového vedúceho, sa stratia. To znamená, že správy, ktoré pôvodný vodca nepotvrdil v tých pár sekundách, keď pracovali dvaja vodcovia, sa stratia.

Ryža. 29. Scenár 4. Líder na brokerovi 1 sa po obnovení siete stáva nasledovníkom

Scenár 5: Nasledovník je úplne oddelený od ostatných Kafkových uzlov a Zookeepera

Nasledovník je úplne izolovaný od ostatných Kafkových uzlov a Zookeepera. Jednoducho sa odstráni z ISR, kým sa sieť neobnoví, a potom dobehne ostatných.

Ryža. 30. Scenár 5: Izolovaný nasledovník je odstránený z ISR

Scenár 6: Vodca je úplne oddelený od ostatných Kafkových uzlov a Zookeepera

Ryža. 31. Scenár 6. Vodca a dvaja nasledovníci

Vodca je úplne izolovaný od svojich nasledovníkov, kontrolóra a Zookeepera. Na krátke obdobie bude naďalej prijímať príspevky od acks=1.

Ryža. 32. Scenár 6: Izolácia vodcu od ostatných uzlov Kafka a Zookeeper

Neprijaté žiadosti po uplynutí platnosti doba oneskorenia repliky max.ms, pokúsi sa zmenšiť ISR na seba, ale nebude to môcť urobiť, pretože neexistuje žiadna komunikácia so Zookeeperom, potom prestane prijímať zápisy.

Medzitým Zookeeper označí izolovaného makléra za mŕtveho a kontrolór si zvolí nového vodcu.

Ryža. 33. Scenár 6. Dvaja lídri

Pôvodný vedúci môže na niekoľko sekúnd prijať záznamy, ale potom prestane prijímať akékoľvek správy. Klienti sú aktualizovaní každých 60 sekúnd o najnovšie metadáta. Budú informovaní o zmene vedúceho a začnú posielať záznamy novému vedúcemu.

Ryža. 34. Scenár 6: Výrobcovia prechádzajú na nového lídra

Všetky potvrdené záznamy vykonané pôvodným vedúcim od straty pripojenia sa stratia. Po obnovení siete pôvodný vodca prostredníctvom Zookeepera zistí, že už nie je vodcom. Potom skráti svoj denník na HW nového lídra v čase volieb a začne odosielať požiadavky ako nasledovník.

Ryža. 35. Scenár 6: Pôvodný líder sa po obnovení sieťového pripojenia stane nasledovníkom

V tejto situácii môže dôjsť na krátku dobu k logickému oddeleniu, ale iba ak acks=1 и min.insync.repliky aj 1. Logické oddelenie sa automaticky skončí buď po obnovení siete, keď si pôvodný líder uvedomí, že už nie je lídrom, alebo keď si všetci klienti uvedomia, že sa líder zmenil a začnú si písať s novým lídrom – podľa toho, čo nastane skôr. V každom prípade sa niektoré správy stratia, ale iba s acks=1.

Existuje ďalší variant tohto scenára, kde tesne pred rozdelením siete nasledovníci zaostali a vodca stlačil ISR len na seba. Potom sa izoluje kvôli strate pripojenia. Je zvolený nový vodca, ale pôvodný vodca naďalej prijíma príspevky, dokonca acks=všetko, lebo v ISR okrem neho nikto iný nie je. Tieto záznamy sa po obnovení siete stratia. Jediný spôsob, ako sa vyhnúť tejto možnosti, je min.insync.replicas = 2.

Scenár 7: Kafka Controller Node nevidí iný Kafka Node

Vo všeobecnosti platí, že akonáhle dôjde k strate spojenia s uzlom Kafka, kontrolér do neho nebude môcť preniesť žiadne informácie o zmene vedúceho. V najhoršom prípade to povedie ku krátkodobému logickému oddeleniu, ako je to v scenári 6. Často sa stáva, že maklér sa jednoducho nestane kandidátom na vedenie, ak tento zlyhá.

Scenár 8: Kafka ovládač nevidí Zookeeper

Zookeeper nedostane ping od spadnutého ovládača a ako ovládač vyberie nový uzol Kafka. Pôvodný ovládač sa môže takto prezentovať aj naďalej, no nedostáva upozornenia od Zookeepera, takže nebude mať žiadne úlohy, ktoré by mal vykonávať. Po obnovení siete si uvedomí, že už nie je kontrolórom, ale stal sa bežným Kafkovým uzlom.

Závery zo scenárov

Vidíme, že strata konektivity nasledovníkov nemá za následok stratu správ, ale jednoducho dočasne znižuje redundanciu, kým sa sieť neobnoví. To, samozrejme, môže viesť k strate údajov, ak dôjde k strate jedného alebo viacerých uzlov.

Ak sa vedúci oddelí od Zookeepera kvôli strate pripojenia, môže to viesť k strate správ acks=1. Nedostatok komunikácie so Zookeeperom spôsobí krátky logický rozchod s dvoma vodcami. Tento problém je vyriešený parametrom acks=všetko.

Parameter min.insync.repliky do dvoch alebo viacerých replík poskytuje dodatočnú záruku, že takéto krátkodobé scenáre nepovedú k strate správ ako v scenári 6.

Súhrn stratených správ

Uveďme si zoznam všetkých spôsobov, ako môžete v Kafke stratiť dáta:

• Akékoľvek zlyhanie lídra, ak boli správy potvrdené pomocou acks=1
• Akýkoľvek nečistý prechod vedenia, teda na nasledovníka mimo ISR, aj s acks=všetko
• Izolácia vodcu od Zookeepera, ak boli správy potvrdené použitím acks=1
• Úplná izolácia vodcu, ktorý už zmenšil skupinu ISR na seba. Všetky správy sa stratia, dokonca aj acks=všetko. To platí len vtedy, ak min.insync.replicas=1.
• Simultánne zlyhania všetkých uzlov oddielu. Keďže správy sú potvrdzované z pamäte, niektoré ešte nemusia byť zapísané na disk. Po reštarte serverov môžu niektoré správy chýbať.

Nečistým prechodom vedenia sa možno vyhnúť ich zákazom alebo zabezpečením aspoň dvoch prepúšťaní. Najodolnejšia konfigurácia je kombinácia acks=všetko и min.insync.repliky viac ako 1.

Priame porovnanie spoľahlivosti RabbitMQ a Kafka

Na zabezpečenie spoľahlivosti a vysokej dostupnosti implementujú obe platformy primárny a sekundárny replikačný systém. RabbitMQ má však Achillovu pätu. Pri opätovnom pripojení po zlyhaní uzly zahodia svoje údaje a synchronizácia sa zablokuje. Táto dvojitá rana spochybňuje životnosť veľkých radov v RabbitMQ. Budete musieť akceptovať buď zníženú redundanciu alebo dlhé blokovacie časy. Zníženie redundancie zvyšuje riziko masívnej straty údajov. Ak sú však fronty malé, z dôvodu redundancie je možné krátke obdobia nedostupnosti (niekoľko sekúnd) riešiť opakovanými pokusmi o pripojenie.

Kafka tento problém nemá. Údaje zahodí len z bodu divergencie medzi vodcom a nasledovníkom. Všetky zdieľané údaje sa uložia. Replikácia navyše neblokuje systém. Líder naďalej prijíma príspevky, zatiaľ čo nový sledovateľ dobieha, takže pre devops sa pripojenie alebo opätovné pripojenie do klastra stáva triviálnou úlohou. Samozrejme, stále existujú problémy, ako je šírka pásma siete počas replikácie. Ak pridáte viacero sledovateľov súčasne, môžete naraziť na obmedzenie šírky pásma.

RabbitMQ je lepší ako Kafka v spoľahlivosti, keď zlyhá viacero serverov v klastri súčasne. Ako sme už povedali, RabbitMQ pošle vydavateľovi potvrdenie až po zapísaní správy na disk masterom a všetkými zrkadlami. To však pridáva ďalšiu latenciu z dvoch dôvodov:

• fsync každých niekoľko stoviek milisekúnd
• Zlyhanie zrkadla je možné zaznamenať až po uplynutí životnosti paketov, ktoré kontrolujú dostupnosť každého uzla (net tick). Ak sa zrkadlo spomalí alebo spadne, pridá sa oneskorenie.

Kafkova stávka spočíva v tom, že ak je správa uložená vo viacerých uzloch, môže správy potvrdiť hneď, ako sa dostanú do pamäte. Z tohto dôvodu existuje riziko straty správ akéhokoľvek typu (dokonca acks=všetko, min.insync.replicas=2) v prípade súčasného zlyhania.

Celkovo Kafka vykazuje lepší softvérový výkon a je od základov navrhnutý pre klastre. Počet sledovateľov sa môže zvýšiť na 11, ak je to potrebné pre spoľahlivosť. Replikačný faktor 5 a minimálny počet replík v synchronizácii min.insync.replicas=3 spôsobí, že strata správy bude veľmi zriedkavá udalosť. Ak vaša infraštruktúra podporuje tento pomer replikácie a úroveň redundancie, môžete si vybrať túto možnosť.

Klastrovanie RabbitMQ je dobré pre malé fronty. Ale aj malé rady môžu rýchlo narásť, keď je hustá premávka. Keď sa fronty zväčšia, budete musieť urobiť ťažké rozhodnutia medzi dostupnosťou a spoľahlivosťou. Klastrovanie RabbitMQ je najvhodnejšie pre netypické situácie, kde výhody flexibility RabbitMQ prevažujú nad akýmikoľvek nevýhodami jeho klastrovania.

Jedna protilátka na zraniteľnosť RabbitMQ voči veľkým radom je rozdeliť ich do mnohých menších radov. Ak nepožadujete kompletné objednanie celej fronty, ale iba príslušných správ (napríklad správy od konkrétneho klienta), alebo si neobjednávate vôbec nič, potom je táto možnosť prijateľná: pozrite sa na môj projekt Rebalancer rozdeliť front (projekt je stále v počiatočnom štádiu).

Nakoniec nezabudnite na množstvo chýb v mechanizmoch klastrovania a replikácie RabbitMQ aj Kafka. Postupom času sa systémy stali vyspelejšími a stabilnejšími, ale žiadna správa nebude nikdy 100% bezpečná pred stratou! Navyše v dátových centrách dochádza k rozsiahlym nehodám!

Ak som niečo vynechal, urobil som chybu alebo nesúhlasíte s niektorým bodom, pokojne napíšte komentár alebo ma kontaktujte.

Často sa ma pýtajú: „Čo si vybrať, Kafka alebo RabbitMQ?“, „Ktorá platforma je lepšia?“. Pravdou je, že to skutočne závisí od vašej situácie, aktuálnych skúseností atď. Váham s vyjadrením svojho názoru, pretože odporučiť jednu platformu pre všetky prípady použitia a možné obmedzenia by bolo príliš zjednodušené. Túto sériu článkov som napísal preto, aby ste si urobili vlastný názor.

Chcem povedať, že oba systémy sú lídrami v tejto oblasti. Môžem byť trochu zaujatý, pretože z mojich skúseností s projektmi mám tendenciu oceňovať veci, ako je zaručené usporiadanie správ a spoľahlivosť.

Vidím ďalšie technológie, ktorým chýba táto spoľahlivosť a zaručené objednávanie, potom sa pozriem na RabbitMQ a Kafka a uvedomím si neuveriteľnú hodnotu oboch týchto systémov.

Zdroj: hab.com