В poslední článek podívali jsme se na klastrování RabbitMQ z hlediska odolnosti proti chybám a vysoké dostupnosti. Nyní se pojďme ponořit hluboko do Apache Kafka.

Zde je jednotkou replikace oddíl. Každé téma má jednu nebo více sekcí. Každá sekce má vůdce s nebo bez následovníků. Při vytváření tématu zadáváte počet oddílů a koeficient replikace. Obvyklá hodnota je 3, což znamená tři repliky: jeden vůdce a dva následovníci.

Rýže. 1. Čtyři sekce jsou rozděleny mezi tři makléře

Všechny požadavky na čtení a zápis jdou vedoucímu. Následovníci pravidelně posílají požadavky vedoucímu, aby obdržel nejnovější zprávy. Spotřebitelé se nikdy neobrátí na následovníky; tito existují pouze kvůli redundanci a odolnosti vůči chybám.

Selhání oddílu

Když broker selže, často selhávají vedoucí několika sekcí. V každém z nich se vedoucím stane následovník z jiného uzlu. Ve skutečnosti tomu tak není vždy, protože faktor synchronizace také ovlivňuje: zda existují synchronizovaní následovníci, a pokud ne, pak zda je povolen přechod na nesynchronizovanou repliku. Ale abychom to zatím nekomplikovali.

Broker 3 opustí síť a pro sekci 2 je u brokera 2 zvolen nový vůdce.

Rýže. 2. Broker 3 zemře a jeho následovník na brokerovi 2 je zvolen novým vůdcem oddílu 2

Poté broker 1 odejde a sekce 1 také ztratí svého vůdce, jehož role přechází na brokera 2.

Rýže. 3. Zbývá jeden makléř. Všichni lídři jsou u jednoho brokera s nulovou redundancí

Když se broker 1 vrátí do režimu online, přidá čtyři následovníky, což každému oddílu poskytne určitou redundanci. Ale všichni lídři stále zůstali na brokerovi 2.

Rýže. 4. Lídři zůstávají u brokera 2

Když se objeví broker 3, jsme zpět u tří replik na oddíl. Ale všichni lídři jsou stále u brokera 2.

Rýže. 5. Nevyvážené umístění lídrů po obnovení brokerů 1 a 3

Kafka má nástroj pro lepší vyvážení lídrů než RabbitMQ. Tam jste museli použít plugin nebo skript třetí strany, který změnil zásady pro migraci hlavního uzlu snížením redundance během migrace. U velkých front jsme se navíc museli smířit s nedostupností při synchronizaci.

Kafka má pro vedoucí roli koncept „preferovaných replik“. Když jsou vytvořeny tématické oddíly, Kafka se pokusí rozmístit vedoucí rovnoměrně mezi uzly a označí tyto první vedoucí jako preferované. V průběhu času mohou v důsledku restartování serveru, selhání a výpadků připojení vedoucí pracovníci skončit na jiných uzlech, jako v extrémním případě popsaném výše.

K nápravě nabízí Kafka dvě možnosti:

Možnost auto.leader.rebalance.enable=true umožňuje řídicímu uzlu automaticky znovu přiřadit odkazy zpět k preferovaným replikám a tím obnovit rovnoměrnou distribuci.
Správce může skript spustit kafka-preferred-replica-election.sh pro ruční přeřazení.

Rýže. 6. Repliky po opětovném vyvážení

Toto byla zjednodušená verze selhání, ale realita je složitější, i když zde není nic příliš složitého. Vše se týká synchronizovaných replik (In-Sync Replicas, ISR).

Synchronizované repliky (ISR)

ISR je sada replik oddílu, který je považován za „synchronizovaný“ (in-sync). Existuje vůdce, ale nemusí existovat následovníci. Následovník je považován za synchronizovaného, pokud před vypršením intervalu vytvořil přesné kopie všech zpráv vedoucího replika.doba.prodlevy.max.ms.

Následovník je odstraněn ze sady ISR, pokud:

nezadal požadavek na výběr pro interval replika.doba.prodlevy.max.ms (předpokládaný mrtvý)
se nepodařilo během intervalu aktualizovat replika.doba.prodlevy.max.ms (považováno za pomalé)

Následovníci podávají požadavky na vzorkování v intervalu replica.fetch.wait.max.ms, což je výchozí hodnota 500 ms.

Abychom jasně vysvětlili účel ISR, musíme se podívat na potvrzení od výrobce a některé scénáře selhání. Producenti si mohou vybrat, kdy makléř pošle potvrzení:

acks=0, potvrzení není odesláno
acks=1, potvrzení je odesláno poté, co vedoucí zapíše zprávu do svého místního deníku
acks=all, potvrzení je odesláno poté, co všechny repliky v ISR zapsaly zprávu do místních protokolů

V Kafkově terminologii platí, že pokud ISR uložil zprávu, je to „committed“. Acks=all je nejbezpečnější možnost, ale také přidává další zpoždění. Podívejme se na dva příklady selhání a na to, jak různé možnosti 'ack' interagují s konceptem ISR.

Acks=1 a ISR

V tomto příkladu uvidíme, že pokud vedoucí nečeká na uložení každé zprávy od všech sledujících, pak je možná ztráta dat, pokud vedoucí selže. Navigaci k nesynchronizovanému sledujícímu lze povolit nebo zakázat nastavením nečistý.vůdce.volby.umožnit.

V tomto příkladu má výrobce hodnotu acks=1. Sekce je distribuována mezi všechny tři brokery. Broker 3 je pozadu, před osmi sekundami se synchronizoval s lídrem a nyní zaostává o 7456 zpráv. Broker 1 zaostal pouze o jednu sekundu. Náš producent pošle zprávu a rychle obdrží zpět potvrzení, bez režie pomalých nebo mrtvých následovníků, na které vůdce nečeká.

Rýže. 7. ISR se třemi replikami

Broker 2 selže a producent obdrží chybu připojení. Poté, co vedení přejde na brokera 1, ztratíme 123 zpráv. Následovník na brokerovi 1 byl součástí ISR, ale nebyl plně synchronizován s vůdcem, když padl.

Rýže. 8. Zprávy se při zhroucení ztratí

V konfiguraci bootstrap.servery Výrobce má uvedených několik brokerů a může se zeptat jiného brokera, kdo je novým vedoucím sekce. Poté naváže spojení s brokerem 1 a pokračuje v odesílání zpráv.

Rýže. 9. Odesílání zpráv se obnoví po krátké přestávce

Broker 3 je ještě dále. Vytváří požadavky na načtení, ale nemůže se synchronizovat. Může to být způsobeno pomalým síťovým připojením mezi makléři, problémem s úložištěm atd. Je odstraněno z ISR. Nyní se ISR skládá z jedné repliky - vůdce! Výrobce pokračuje v odesílání zpráv a přijímání potvrzení.

Rýže. 10. Následovník na brokerovi 3 je odstraněn z ISR

Broker 1 klesá a vedoucí role přechází na makléře 3 se ztrátou 15286 zpráv! Výrobce obdrží chybovou zprávu o připojení. Přechod na lídra mimo ISR byl možný jen díky nastavení unclean.leader.election.enable=true. Pokud je nainstalován v nepravdivý, pak by k přechodu nedošlo a všechny požadavky na čtení a zápis by byly odmítnuty. V tomto případě čekáme, až se broker 1 vrátí se svými neporušenými daty v replice, která opět převezme vedení.

Rýže. 11. Broker 1 padá. Při selhání dojde ke ztrátě velkého počtu zpráv

Producent naváže spojení s posledním makléřem a vidí, že je nyní vedoucím sekce. Začne posílat zprávy brokerovi 3.

Rýže. 12. Po krátké přestávce jsou zprávy znovu odeslány do sekce 0

Viděli jsme, že kromě krátkých přerušení kvůli navazování nových spojení a hledání nového lídra, výrobce neustále posílal zprávy. Tato konfigurace zajišťuje dostupnost na úkor konzistence (zabezpečení dat). Kafka ztratil tisíce zpráv, ale nadále přijímal nové zprávy.

Acks=all a ISR

Zopakujme tento scénář znovu, ale s acks=vše. Broker 3 má průměrnou latenci čtyři sekundy. Výrobce posílá zprávu s acks=všea nyní nedostává rychlou odpověď. Vedoucí čeká na uložení zprávy všemi replikami v ISR.

Rýže. 13. ISR se třemi replikami. Jeden je pomalý, což má za následek zpoždění nahrávání

Po čtyřech sekundách dodatečného zpoždění zašle broker 2 potvrzení. Všechny repliky jsou nyní plně aktualizovány.

Rýže. 14. Všechny repliky ukládají zprávy a posílají potvrzení

Broker 3 nyní zaostává dále a je odstraněn z ISR. Latence je výrazně snížena, protože v ISR nezůstávají žádné pomalé repliky. Broker 2 nyní čeká pouze na brokera 1 a ten má průměrné zpoždění 500 ms.

Rýže. 15. Replika na brokera 3 je odstraněna z ISR

Poté broker 2 padá a vedení přechází na brokera 1 bez ztráty zpráv.

Rýže. 16. Broker 2 padá

Výrobce si najde nového vůdce a začne mu posílat zprávy. Latence je dále snížena, protože ISR se nyní skládá z jedné repliky! Proto možnost acks=vše nepřidává redundanci.

Rýže. 17. Replika na brokerovi 1 přebírá vedení bez ztráty zpráv

Poté dojde ke zhroucení brokera 1 a vedení jde na brokera 3 se ztrátou 14238 zpráv!

Rýže. 18. Broker 1 umírá a přechod vedení s nečistým nastavením vede k rozsáhlé ztrátě dat

Volbu se nepodařilo nainstalovat nečistý.vůdce.volby.umožnit do smyslu pravdivý. Ve výchozím nastavení se rovná nepravdivý. Nastavení acks=vše с unclean.leader.election.enable=true poskytuje přístupnost s určitým přidaným zabezpečením dat. Ale jak vidíte, stále můžeme ztratit zprávy.

Co když ale chceme zvýšit bezpečnost dat? Můžeš položit unclean.leader.election.enable = false, ale to nás nutně neochrání před ztrátou dat. Pokud vůdce tvrdě upadl a vzal s sebou data, zprávy jsou stále ztraceny a dostupnost je ztracena, dokud správce situaci neobnoví.

Je lepší zajistit, aby byly všechny zprávy nadbytečné, a jinak nahrávku zahodit. Pak je, alespoň z pohledu brokera, ztráta dat možná pouze v případě dvou a více současných poruch.

Acks=all, min.insync.replicas a ISR

S konfigurací tématu min.insync.repliky Zvyšujeme úroveň zabezpečení dat. Pojďme si znovu projít poslední část předchozího scénáře, ale tentokrát s min.insync.replicas=2.

Takže broker 2 má repliku vůdce a následovník na brokerovi 3 je odstraněn z ISR.

Rýže. 19. ISR ze dvou replik

Broker 2 padá a vedení přechází na brokera 1 bez ztráty zpráv. Nyní se ale ISR skládá pouze z jedné repliky. To nesplňuje minimální počet pro příjem záznamů, a proto broker odpoví na pokus o zápis chybou NotEnoughReplicas.

Rýže. 20. Počet ISR je o jeden nižší, než je uvedeno v min.insync.replicas

Tato konfigurace obětuje dostupnost kvůli konzistenci. Před potvrzením zprávy se ujistíme, že je zapsána alespoň do dvou replik. To dává výrobci mnohem větší jistotu. Zde je ztráta zprávy možná pouze v případě, že dvě repliky selžou současně v krátkém intervalu, dokud není zpráva replikována na dalšího následovníka, což je nepravděpodobné. Ale pokud jste super paranoidní, můžete nastavit replikační faktor na 5 a min.insync.repliky o 3. Zde musí padnout tři makléři současně, aby ztratili rekord! Za tuto spolehlivost samozřejmě platíte v dodatečné latenci.

Když je dostupnost nezbytná pro zabezpečení dat

Stejně jako v pouzdro s RabbitMQ, někdy je dostupnost nezbytná pro zabezpečení dat. Zde je to, na co je třeba myslet:

Může vydavatel jednoduše vrátit chybu a nechat službu nebo uživatele, aby to zkusili později?
Může vydavatel uložit zprávu místně nebo do databáze a zkusit to znovu později?

Pokud je odpověď ne, pak optimalizace dostupnosti zlepšuje zabezpečení dat. Pokud místo nenahrávání zvolíte dostupnost, ztratíte méně dat. Vše tedy spočívá v nalezení rovnováhy a rozhodnutí závisí na konkrétní situaci.

Význam ISR

Sada ISR vám umožňuje zvolit optimální rovnováhu mezi zabezpečením dat a latencí. Například zajistit dostupnost v případě selhání většiny replik a minimalizovat dopad mrtvých nebo pomalých replik z hlediska latence.

Význam si volíme sami replika.doba.prodlevy.max.ms podle vašich potřeb. Tento parametr v podstatě znamená, kolik zpoždění jsme ochotni přijmout, kdy acks=vše. Výchozí hodnota je deset sekund. Pokud je to pro vás příliš dlouhé, můžete to snížit. Pak se frekvence změn v ISR zvýší, protože následovníci budou odebíráni a přidáváni častěji.

RabbitMQ je jednoduše sada zrcadel, které je třeba replikovat. Pomalá zrcadla zavádějí další latenci a mrtvá zrcadla mohou čekat, než zareagují pakety, které kontrolují dostupnost každého uzlu (net tick). ISR je zajímavý způsob, jak se těmto problémům s latencí vyhnout. Ale riskujeme ztrátu redundance, protože ISR se může zmenšit pouze na vůdce. Chcete-li se tomuto riziku vyhnout, použijte nastavení min.insync.repliky.

Garance připojení klienta

V nastavení bootstrap.servery výrobce a spotřebitel mohou určit více brokerů pro připojení klientů. Myšlenka je taková, že když jeden uzel vypadne, zbude několik náhradních, se kterými může klient navázat spojení. Nejedná se nutně o vedoucí oddílů, ale pouze o odrazový můstek pro počáteční zatížení. Klient se jich může zeptat, který uzel je hostitelem vedoucího oddílu pro čtení/zápis.

V RabbitMQ se klienti mohou připojit k libovolnému uzlu a interní směrování pošle požadavek tam, kam potřebuje. To znamená, že můžete nainstalovat load balancer před RabbitMQ. Kafka vyžaduje, aby se klienti připojili k uzlu, který je hostitelem příslušného vedoucího oddílu. V takové situaci nemůžete nainstalovat nástroj pro vyrovnávání zatížení. Seznam bootstrap.servery Je důležité, aby klienti měli po selhání přístup a našli správné uzly.

Kafkova konsensuální architektura

Doposud jsme se nezabývali tím, jak se klastr dozví o pádu brokera a jak se volí nový lídr. Abyste pochopili, jak Kafka pracuje se síťovými oddíly, musíte nejprve porozumět architektuře konsensu.

Každý cluster Kafka je nasazen spolu s clusterem Zookeeper, což je distribuovaná služba konsenzu, která umožňuje systému dosáhnout konsensu v určitém daném stavu, přičemž upřednostňuje konzistenci před dostupností. Ke schválení operací čtení a zápisu je nutný souhlas většiny uzlů Zookeeper.

Zookeeper ukládá stav clusteru:

Seznam témat, sekcí, konfigurace, aktuální repliky vedoucích, preferované repliky.
Členové klastru. Každý broker pingne na cluster Zookeeper. Pokud neobdrží ping během stanovené doby, Zookeeper zaznamená zprostředkovatele jako nedostupného.
Výběr hlavního a náhradního uzlu pro ovladač.

Kontrolní uzel je jedním z Kafkových brokerů, který je zodpovědný za volbu lídrů replik. Zookeeper zasílá řadiči oznámení o členství v clusteru a změnách témat a řadič musí na tyto změny reagovat.

Vezměme si například nové téma s deseti oddíly a replikačním faktorem 3. Řadič musí zvolit vedoucího pro každý oddíl a snažit se optimálně rozdělit lídry mezi brokery.

Pro každý ovladač sekce:

aktualizuje informace v Zookeeper o ISR a vůdci;
Odešle LeaderAndISRCommand každému brokerovi, který je hostitelem repliky tohoto oddílu, informuje brokery o ISR a lídrovi.

Když padne broker s vůdcem, Zookeeper pošle oznámení správci a ten zvolí nového vůdce. Kontrolor opět nejprve aktualizuje Zookeeper a poté každému brokerovi pošle příkaz, který je upozorní na změnu vedení.

Každý vůdce je zodpovědný za nábor ISR. Nastavení replika.doba.prodlevy.max.ms určuje, kdo tam vstoupí. Když se ISR změní, vedoucí předá nové informace Zookeeper.

Zookeeper je vždy informován o všech změnách, aby v případě výpadku vedení plynule přešlo na nového vedoucího.

Rýže. 21. Kafkův konsensus

Replikační protokol

Pochopení podrobností o replikaci vám pomůže lépe porozumět potenciálním scénářům ztráty dat.

Vzorkování dotazů, Log End Offset (LEO) a Highwater Mark (HW)

Měli jsme za to, že sledující pravidelně posílají žádosti o načtení vedoucímu. Výchozí interval je 500 ms. To se liší od RabbitMQ v tom, že v RabbitMQ replikaci nespouští zrcadlo fronty, ale hlavní server. Master tlačí změny do zrcátek.

Vedoucí a všichni následovníci si uloží Log End Offset (LEO) a štítek Highwater (HW). Značka LEO ukládá offset poslední zprávy v lokální replice a HW drží offset posledního potvrzení. Pamatujte, že pro stav potvrzení musí být zpráva zachována ve všech replikách ISR. To znamená, že LEO je obvykle mírně napřed před HW.

Když vedoucí obdrží zprávu, uloží ji lokálně. Následovník zadá požadavek na vyzvednutí odesláním svého LEO. Vedoucí pak odešle dávku zpráv počínaje tímto LEO a také přenese aktuální HW. Když leader obdrží informaci, že všechny repliky uložily zprávu v daném offsetu, posune HW značku. Přesouvat HW může pouze vedoucí, a tak všichni následovníci budou znát aktuální hodnotu v odpovědích na svůj požadavek. To znamená, že následovníci mohou za lídrem zaostávat ve znalostech zpráv i HW. Spotřebitelé dostávají zprávy pouze do aktuálního HW.

Všimněte si, že "trvalo" znamená zapsáno do paměti, nikoli na disk. Kvůli výkonu se Kafka synchronizuje s diskem v určitém intervalu. RabbitMQ má také takový interval, ale potvrzení odešle vydavateli až poté, co master a všechna zrcadla zapíší zprávu na disk. Vývojáři Kafky se z výkonnostních důvodů rozhodli odeslat potvrzení, jakmile se zpráva zapíše do paměti. Kafka sází na to, že redundance kompenzuje riziko krátkého uložení potvrzených zpráv pouze do paměti.

Selhání vůdce

Když vůdce padne, Zookeeper upozorní správce a ten vybere novou repliku vůdce. Nový lídr nastavuje novou HW značku podle svého LEO. Následovníci pak obdrží informace o novém vůdci. V závislosti na verzi Kafky si následovník vybere jeden ze dvou scénářů:

Zkrátí místní protokol na známý HW a odešle požadavek novému vedoucímu na zprávy za touto značkou.
Odešle požadavek vedoucímu, aby zjistil HW v době, kdy byl zvolen vůdcem, a poté zkrátí protokol na tento offset. Poté začne provádět pravidelné požadavky na načítání počínaje tímto posunem.

Sledovatel může potřebovat zkrátit protokol z následujících důvodů:

Když vůdce selže, první následovník v sadě ISR registrovaný u Zookeeper vyhraje volby a stane se vůdcem. Všichni sledující na ISR, i když jsou považováni za „synchronizované“, možná neobdrželi kopie všech zpráv od bývalého vůdce. Je zcela možné, že doporučený následovník nemá nejaktuálnější kopii. Kafka zajišťuje, že mezi replikami nejsou žádné rozdíly. Aby se tedy předešlo nesrovnalostem, musí každý následovník zkrátit svůj log na HW hodnotu nového vůdce v době jeho zvolení. To je další důvod, proč nastavení acks=vše tak důležité pro konzistenci.
Zprávy jsou pravidelně zapisovány na disk. Pokud všechny uzly clusteru selžou současně, budou na disky uloženy repliky s různými offsety. Je možné, že když se makléři vrátí online, nový vůdce, který bude zvolen, bude za svými následovníky, protože byl uložen na disk dříve než ostatní.

Shledání s klastrem

Při opětovném připojení ke clusteru repliky dělají totéž, jako když vůdce selže: zkontrolují repliku vůdce a zkrátí svůj protokol na jeho HW (v době volby). Ve srovnání s tím RabbitMQ stejně zachází se sjednocenými uzly jako se zcela novými. V obou případech broker vyřadí jakýkoli existující stav. Pokud je použita automatická synchronizace, pak master musí replikovat absolutně veškerý aktuální obsah do nového zrcadla metodou „nechte celý svět čekat“. Master během této operace nepřijímá žádné operace čtení nebo zápisu. Tento přístup vytváří problémy ve velkých frontách.

Kafka je distribuovaný protokol a obecně ukládá více zpráv než fronta RabbitMQ, kde jsou data po přečtení z fronty odstraněna. Aktivní fronty by měly zůstat relativně malé. Kafka je ale protokol s vlastní politikou uchovávání, která může nastavit období dnů nebo týdnů. Přístup blokování fronty a plné synchronizace je pro distribuovaný protokol absolutně nepřijatelný. Místo toho následovníci Kafky jednoduše zkrátí svůj protokol na HW vůdce (v době jeho zvolení), pokud je jejich kopie před vůdcem. V pravděpodobnějším případě, když je následovník pozadu, jednoduše začne provádět požadavky na načtení počínaje jeho aktuálním objektem LEO.

Noví nebo znovu se připojili sledující začínají mimo ISR a neúčastní se odevzdání. Jednoduše pracují se skupinou a dostávají zprávy tak rychle, jak mohou, dokud nedohoní vůdce a nevstoupí do ISR. Neexistuje žádné uzamčení a není třeba vyhodit všechna vaše data.

Ztráta konektivity

Kafka má více komponent než RabbitMQ, takže má složitější sadu chování, když se cluster odpojí. Kafka byl ale původně navržen pro clustery, takže řešení jsou velmi dobře promyšlená.

Níže je uvedeno několik scénářů selhání připojení:

Scénář 1: Následovník nevidí vůdce, ale přesto vidí Zookeepera.
Scénář 2: Vedoucí nevidí žádné následovníky, ale stále vidí Zookeeper.
Scénář 3: Následovník vidí vůdce, ale nevidí Zookeepera.
Scénář 4: Vůdce vidí následovníky, ale nevidí Zookeepera.
Scénář 5: Následovník je zcela oddělen od ostatních Kafkových uzlů a Zookeeper.
Scénář 6: Vůdce je zcela oddělen od ostatních Kafkových uzlů a Zookeepera.
Scénář 7: Uzel řadiče Kafka nevidí jiný uzel Kafka.
Scénář 8: Kafka ovladač nevidí Zookeeper.

Každý scénář má své vlastní chování.

Scénář 1: Následovník nevidí vůdce, ale stále vidí Zookeeper

Rýže. 22. Scénář 1: ISR tří replik

Selhání připojení odděluje brokera 3 od brokerů 1 a 2, ale ne od Zookeeper. Broker 3 již nemůže odesílat požadavky na načtení. Po uplynutí času replika.doba.prodlevy.max.ms je odstraněn z ISR a neúčastní se potvrzování zpráv. Jakmile je připojení obnoveno, obnoví požadavky na načítání a připojí se k ISR, když dohoní vedoucího. Ošetřovatel zoo bude i nadále dostávat pingy a předpokládat, že broker je naživu a zdráv.

Rýže. 23. Scénář 1: Broker je odstraněn z ISR, pokud od něj není přijat žádný požadavek na načtení během intervalu replika.lag.time.max.ms

Neexistuje žádné zavěšení rozděleného mozku nebo uzlu jako v RabbitMQ. Místo toho je redundance snížena.

Scénář 2: Leader nevidí žádné následovníky, ale stále vidí Zookeeper

Rýže. 24. Scénář 2. Vůdce a dva následovníci

Porucha síťové konektivity odděluje vůdce od následovníků, ale broker stále vidí Zookeeper. Stejně jako v prvním scénáři se ISR zmenší, ale tentokrát pouze na vedoucí, protože všichni následovníci přestanou odesílat požadavky na načtení. Opět zde není žádné logické dělení. Místo toho dochází ke ztrátě redundance pro nové zprávy, dokud není připojení obnoveno. Ošetřovatel zoo nadále dostává pingy a věří, že makléř je naživu a zdráv.

Rýže. 25. Scénář 2. ISR se smrskl pouze na vůdce

Scénář 3. Následovník vidí vůdce, ale nevidí Zookeeper

Následovník je oddělen od Zookeepera, ale ne od brokera s vůdcem. Výsledkem je, že následovník nadále zadává požadavky na načtení a je členem ISR. Zookeeper již nepřijímá pingy a registruje pád brokera, ale jelikož se jedná pouze o followera, po zotavení nenesou žádné následky.

Rýže. 26. Scénář 3: Následovník pokračuje v odesílání požadavků na vyzvednutí vedoucímu

Scénář 4. Vedoucí vidí následovníky, ale nevidí Zookeeper

Rýže. 27. Scénář 4. Vůdce a dva následovníci

Vůdce je oddělen od Zookeeper, ale ne od makléřů s následovníky.

Rýže. 28. Scénář 4: Vůdce izolovaný od Zookeepera

Po nějaké době Zookeeper zaregistruje selhání brokera a upozorní na to správce. Mezi svými následovníky si vybere nového vůdce. Původní vedoucí si však bude i nadále myslet, že je vůdcem, a bude nadále přijímat příspěvky od acks=1. Následovníci mu již neposílají žádosti o přivedení, takže je bude považovat za mrtvé a pokusí se zmenšit ISR na sebe. Ale protože nemá spojení se Zookeeperem, nebude to moci udělat a v tu chvíli odmítne přijmout jakékoli další záznamy.

zprávy acks=vše neobdrží potvrzení, protože ISR nejprve zapne všechny repliky a zprávy se k nim nedostanou. Když se je původní vůdce pokusí odstranit z ISR, nebude to moci udělat a přestane přijímat jakékoli zprávy.

Klienti si brzy všimnou změny vedoucího a začnou odesílat záznamy na nový server. Jakmile je síť obnovena, původní vedoucí vidí, že již není vedoucím, a zkrátí svůj protokol na HW hodnotu, kterou měl nový vedoucí v době selhání, aby se zabránilo divergenci protokolu. Poté začne odesílat požadavky na načtení novému vedoucímu. Všechny záznamy z původního odkazu, které nejsou replikovány do nového odkazu, budou ztraceny. To znamená, že zprávy, které nebyly uznány původním vedoucím v těch několika sekundách, kdy dva vedoucí pracovali, budou ztraceny.

Rýže. 29. Scénář 4. Vedoucí na brokerovi 1 se po obnovení sítě stane následovníkem

Scénář 5: Následovník je zcela oddělen od ostatních Kafkových uzlů a Zookeeper

Následovník je zcela izolován jak od ostatních Kafkových uzlů, tak od Zookeepera. Jednoduše se odstraní z ISR, dokud nebude síť obnovena, a pak dohoní ostatní.

Rýže. 30. Scénář 5: Izolovaný sledovač je odstraněn z ISR

Scénář 6: Vůdce je zcela oddělen od ostatních Kafkových uzlů a Zookeepera

Rýže. 31. Scénář 6. Vůdce a dva následovníci

Vůdce je zcela izolován od svých následovníků, kontrolora a Zookeepera. Po krátkou dobu bude nadále přijímat příspěvky od acks=1.

Rýže. 32. Scénář 6: Izolace vůdce od ostatních uzlů Kafka a Zookeeper

Nepřijaté žádosti po vypršení platnosti replika.doba.prodlevy.max.ms, pokusí se zmenšit ISR na sebe, ale nebude to moci udělat, protože neexistuje žádná komunikace se Zookeeperem, pak přestane přijímat zápisy.

Mezitím Zookeeper označí izolovaného makléře za mrtvého a správce zvolí nového vůdce.

Rýže. 33. Scénář 6. Dva vůdci

Původní vedoucí může na několik sekund přijímat záznamy, ale poté přestane přijímat jakékoli zprávy. Klienti jsou aktualizováni každých 60 sekund nejnovějšími metadaty. Budou informováni o změně vedoucího a začnou odesílat záznamy novému vedoucímu.

Rýže. 34. Scénář 6: Výrobci přejdou na nového lídra

Všechny potvrzené záznamy provedené původním vedoucím od ztráty připojení budou ztraceny. Jakmile bude síť obnovena, původní vůdce prostřednictvím Zookeeper zjistí, že již není vůdcem. Poté zkrátí svůj protokol na HW nového vůdce v době voleb a začne odesílat požadavky jako následovník.

Rýže. 35. Scénář 6: Po obnovení síťového připojení se původní vedoucí stane následovníkem

V této situaci může dojít na krátkou dobu k logickému oddělení, ale pouze pokud acks=1 и min.insync.repliky také 1. Logické oddělení automaticky končí buď po obnovení sítě, když si původní vedoucí uvědomí, že už není vedoucí, nebo když si všichni klienti uvědomí, že se vedoucí změnil a začnou psát novému vedoucímu – podle toho, co nastane dříve. V každém případě se některé zprávy ztratí, ale pouze s acks=1.

Existuje další varianta tohoto scénáře, kdy těsně před rozdělením sítě následovníci zaostali a vůdce komprimoval ISR pouze na sebe. Poté se izoluje kvůli ztrátě připojení. Je zvolen nový vůdce, ale původní vůdce nadále přijímá příspěvky, dokonce acks=vše, protože v ISR kromě něj nikdo jiný není. Tyto záznamy budou po obnovení sítě ztraceny. Jediný způsob, jak se této možnosti vyhnout, je min.insync.replicas = 2.

Scénář 7: Kafka Controller Node nevidí jiný Kafka Node

Obecně platí, že jakmile dojde ke ztrátě spojení s uzlem Kafka, řadič do něj nebude schopen přenést žádné informace o změně vedoucího. V nejhorším případě to povede ke krátkodobému logickému oddělení, jako ve scénáři 6. Mnohem častěji se makléř jednoduše nestane kandidátem na vedení, pokud druhý selže.

Scénář 8: Kafka ovladač nevidí Zookeeper

Zookeeper nedostane ping od padlého ovladače a jako ovladač vybere nový Kafka uzel. Původní ovladač se může nadále prezentovat jako takový, ale nedostává upozornění od Zookeeper, takže nebude mít žádné úkoly, které by musel provádět. Jakmile bude síť obnovena, uvědomí si, že již není kontrolorem, ale stal se regulérním Kafkovým uzlem.

Závěry ze scénářů

Vidíme, že ztráta konektivity následovníků nevede ke ztrátě zpráv, ale pouze dočasně snižuje redundanci, dokud není síť obnovena. To samozřejmě může vést ke ztrátě dat, pokud dojde ke ztrátě jednoho nebo více uzlů.

Pokud se vůdce oddělí od Zookeepera kvůli ztrátě připojení, může to vést ke ztrátě zpráv acks=1. Nedostatek komunikace se Zookeeperem způsobí krátký logický rozkol s oběma vůdci. Tento problém řeší parametr acks=vše.

Parametr min.insync.repliky do dvou nebo více replik poskytuje další záruku, že takové krátkodobé scénáře nepovedou ke ztrátě zpráv jako ve scénáři 6.

Souhrn ztracených zpráv

Pojďme si vyjmenovat všechny způsoby, jak můžete v Kafce ztratit data:

Jakékoli selhání vůdce, pokud byly zprávy potvrzeny pomocí acks=1
Jakýkoli nečistý přechod vedení, tedy na následovníka mimo ISR, i s acks=vše
Izolace vůdce od Zookeeper, pokud byly zprávy potvrzeny pomocí acks=1
Úplná izolace vůdce, který již zmenšil skupinu ISR na sebe. Všechny zprávy budou ztraceny, dokonce i acks=vše. To platí pouze tehdy, pokud min.insync.replicas=1.
Simultánní selhání všech uzlů oddílu. Protože zprávy jsou potvrzovány z paměti, některé ještě nemusí být zapsány na disk. Po restartování serverů mohou některé zprávy chybět.

Nečistým přechodům vedení se lze vyhnout buď jejich zákazem, nebo zajištěním alespoň dvou propouštění. Nejodolnější konfigurace je kombinace acks=vše и min.insync.repliky více 1.

Přímé srovnání spolehlivosti RabbitMQ a Kafka

Pro zajištění spolehlivosti a vysoké dostupnosti implementují obě platformy primární a sekundární replikační systém. RabbitMQ má však Achillovu patu. Při opětovném připojení po selhání uzly zahodí svá data a synchronizace je zablokována. Tato dvojitá rána zpochybňuje životnost velkých front v RabbitMQ. Budete se muset smířit buď se sníženou redundancí, nebo s dlouhou dobou blokování. Snížení redundance zvyšuje riziko masivní ztráty dat. Pokud jsou však fronty malé, lze z důvodu redundance vyřešit krátké doby nedostupnosti (několik sekund) pomocí opakovaných pokusů o připojení.

Kafka tento problém nemá. Zahazuje data pouze z bodu divergence mezi vůdcem a následovníkem. Všechna sdílená data jsou uložena. Replikace navíc neblokuje systém. Vedoucí pokračuje v přijímání příspěvků, zatímco nový sledující je dohání, takže pro devopy se připojení nebo opětovné připojení ke clusteru stává triviálním úkolem. Samozřejmě stále existují problémy, jako je šířka pásma sítě během replikace. Pokud přidáte více sledujících současně, můžete narazit na omezení šířky pásma.

RabbitMQ je lepší než Kafka ve spolehlivosti, když selže více serverů v clusteru současně. Jak jsme si již řekli, RabbitMQ posílá vydavateli potvrzení až po zapsání zprávy na disk masterem a všemi zrcadly. To však přidává další latenci ze dvou důvodů:

fsync každých několik set milisekund
Selhání zrcadla lze zaznamenat až po vypršení životnosti paketů, které kontrolují dostupnost každého uzlu (net tick). Pokud se zrcadlo zpomalí nebo spadne, přidá se zpoždění.

Kafkova sázka spočívá v tom, že pokud je zpráva uložena na více uzlech, může zprávy potvrdit, jakmile se dostanou do paměti. Z tohoto důvodu existuje riziko ztráty zpráv jakéhokoli typu (dokonce i acks=vše, min.insync.replicas=2) v případě současné poruchy.

Celkově Kafka vykazuje lepší výkon softwaru a je od základu navržen pro clustery. Počet sledujících lze v případě potřeby zvýšit na 11 kvůli spolehlivosti. Replikační faktor 5 a minimální počet replik v synchronizaci min.insync.replicas=3 učiní ztrátu zprávy velmi vzácnou událostí. Pokud vaše infrastruktura podporuje tento poměr replikace a úroveň redundance, můžete zvolit tuto možnost.

Klastrování RabbitMQ je dobré pro malé fronty. Ale i malé fronty mohou rychle narůst, když je hustý provoz. Jakmile se fronty zvětší, budete muset tvrdě vybírat mezi dostupností a spolehlivostí. Clusterování RabbitMQ se nejlépe hodí pro netypické situace, kde výhody flexibility RabbitMQ převažují nad nevýhodami jeho shlukování.

Jedním z protijed na zranitelnost RabbitMQ vůči velkým frontám je rozdělit je do mnoha menších front. Pokud nepožadujete kompletní objednání celé fronty, ale pouze příslušné zprávy (například zprávy od konkrétního klienta), nebo neobjednáte vůbec nic, pak je tato možnost přijatelná: podívejte se na můj projekt Rebalancer k rozdělení fronty (projekt je stále v rané fázi).

Nakonec nezapomeňte na řadu chyb v mechanismech shlukování a replikace RabbitMQ i Kafka. Postupem času se systémy staly vyspělejšími a stabilnějšími, ale žádná zpráva nebude nikdy 100% bezpečná před ztrátou! V datových centrech navíc dochází k rozsáhlým nehodám!

Pokud jsem něco přehlédl, udělal chybu nebo nesouhlasíte s některým z bodů, neváhejte napsat komentář nebo mě kontaktujte.

Často dostávám otázku: „Co si vybrat, Kafka nebo RabbitMQ?“, „Která platforma je lepší?“. Pravdou je, že opravdu záleží na vaší situaci, aktuálních zkušenostech atd. Váhám s vyjádřením svého názoru, protože doporučovat jednu platformu pro všechny případy použití a možná omezení by bylo příliš zjednodušující. Tuto sérii článků jsem napsal proto, abyste si udělali vlastní názor.

Chci říci, že oba systémy jsou v této oblasti lídry. Možná jsem trochu zaujatý, protože ze svých zkušeností s projekty mám tendenci oceňovat věci, jako je zaručené uspořádání zpráv a spolehlivost.

Vidím další technologie, kterým tato spolehlivost a zaručené řazení chybí, pak se podívám na RabbitMQ a Kafka a uvědomím si neuvěřitelnou hodnotu obou těchto systémů.

Zdroj: www.habr.com

RabbitMQ vs Kafka: Odolnost vůči chybám a vysoká dostupnost