В poslednji članak pogledali smo RabbitMQ klasterizaciju radi tolerancije grešaka i visoke dostupnosti. Hajde sada da kopamo duboko u Apache Kafku.

Ovdje je jedinica replikacije particija. Svaka tema ima jedan ili više odjeljaka. Svaka sekcija ima vođu sa ili bez sljedbenika. Kada kreirate temu, specificirate broj particija i koeficijent replikacije. Uobičajena vrijednost je 3, što znači tri replike: jedan vođa i dva sljedbenika.

Rice. 1. Četiri sekcije su raspoređene između tri brokera

Svi zahtjevi za čitanje i pisanje idu vođi. Sljedbenici povremeno šalju zahtjeve vođi da primaju najnovije poruke. Potrošači se nikada ne okreću sljedbenicima; ovi drugi postoje samo zbog redundancije i tolerancije grešaka.

Greška particije

Kada broker propadne, lideri nekoliko sekcija često propadnu. U svakom od njih, sljedbenik iz drugog čvora postaje vođa. Zapravo, to nije uvijek slučaj, jer faktor sinhronizacije također utiče na: da li postoje sinhronizirani sljedbenici, a ako ne, onda da li je prelazak na nesinhroniziranu repliku dozvoljen. Ali nemojmo za sada komplikovati.

Broker 3 napušta mrežu, a novi lider se bira za sekciju 2 kod brokera 2.

Rice. 2. Broker 3 umire i njegov pratilac na brokeru 2 je izabran za novog vođu particije 2

Tada broker 1 napušta i dio 1 također gubi svog lidera, čija uloga prelazi na brokera 2.

Rice. 3. Ostao je jedan broker. Svi lideri su na jednom brokeru sa nultom zališkom

Kada se broker 1 vrati na mrežu, dodaje četiri sljedbenika, pružajući određenu redundantnost svakoj particiji. Ali svi lideri su i dalje ostali na brokeru 2.

Rice. 4. Lideri ostaju na brokeru 2

Kada se pojavi broker 3, vraćamo se na tri replike po particiji. Ali svi lideri su i dalje na brokeru 2.

Rice. 5. Neuravnotežen plasman lidera nakon restauracije brokera 1 i 3

Kafka ima alat za bolji balans lidera od RabbitMQ-a. Tamo ste morali da koristite dodatak ili skriptu treće strane koja je promenila smernice za migraciju glavnog čvora smanjujući redundantnost tokom migracije. Osim toga, za velike redove morali smo prihvatiti nedostupnost tokom sinhronizacije.

Kafka ima koncept „poželjnih replika“ za vodeću ulogu. Kada se kreiraju particije tema, Kafka pokušava ravnomjerno rasporediti lidere po čvorovima i označava te prve vođe kao preferirane. Tokom vremena, zbog ponovnog pokretanja servera, kvarova i prekida veze, lideri mogu završiti na drugim čvorovima, kao u ekstremnom slučaju opisanom gore.

Da to popravi, Kafka nudi dvije opcije:

• Opcija auto.leader.rebalance.enable=true omogućava čvoru kontrolera da automatski preraspodijeli vođe natrag na željene replike i na taj način obnovi uniformnu distribuciju.
• Administrator može pokrenuti skriptu kafka-preferred-replica-election.sh za ručni preraspoređivanje.

Rice. 6. Replike nakon rebalansa

Ovo je bila pojednostavljena verzija neuspjeha, ali stvarnost je složenija, iako ovdje nema ništa previše komplikovano. Sve se svodi na sinhronizovane replike (In-Sync Replicas, ISR).

Sinkronizirane replike (ISR)

ISR je skup replika particije koja se smatra "sinhroniziranom" (in-sinhroniziranom). Vođa postoji, ali sljedbenika možda nema. Sljedbenik se smatra sinhroniziranim ako je napravio tačne kopije svih poruka vođe prije isteka intervala replica.lag.time.max.ms.

Pratilac se uklanja iz ISR skupa ako:

• nije napravio zahtjev za odabir intervala replica.lag.time.max.ms (pretpostavlja se da je mrtav)
• nije uspio ažurirati tokom intervala replica.lag.time.max.ms (smatra se sporim)

Sljedbenici postavljaju zahtjeve za uzorkovanje u intervalu replica.fetch.wait.max.ms, što je zadano na 500 ms.

Da bismo jasno objasnili svrhu ISR-a, moramo pogledati potvrde proizvođača i neke scenarije neuspjeha. Proizvođači mogu odabrati kada broker pošalje potvrdu:

• acks=0, potvrda nije poslana
• acks=1, potvrda se šalje nakon što je vođa napisao poruku u svoj lokalni dnevnik
• acks=all, potvrda se šalje nakon što sve replike u ISR-u napišu poruku u lokalne dnevnike

U Kafkinoj terminologiji, ako je ISR sačuvao poruku, ona je “posvećena”. Acks=all je najsigurnija opcija, ali također dodaje dodatno kašnjenje. Pogledajmo dva primjera neuspjeha i kako različite 'acks' opcije djeluju u interakciji s ISR konceptom.

Acks=1 i ISR

U ovom primjeru ćemo vidjeti da ako vođa ne čeka da se svaka poruka od svih sljedbenika sačuva, gubitak podataka je moguć ako voditelj ne uspije. Navigacija do nesinhroniziranog pratioca može se omogućiti ili onemogućiti postavkama unclean.leader.election.enable.

U ovom primjeru, proizvođač ima vrijednost acks=1. Odjeljak je raspoređen na sva tri brokera. Broker 3 je iza, sinhronizovao se sa liderom prije osam sekundi i sada zaostaje 7456 poruka. Broker 1 zaostajao je samo jednu sekundu. Naš producent šalje poruku i brzo dobija potvrdu, bez dodatnih troškova sporih ili mrtvih pratilaca koje lider ne čeka.

Rice. 7. ISR sa tri replike

Broker 2 ne uspijeva i proizvođač prima grešku u vezi. Nakon što vodstvo pređe na brokera 1, gubimo 123 poruke. Pratilac na brokeru 1 bio je dio ISR-a, ali nije bio u potpunosti sinhronizovan sa liderom kada je pao.

Rice. 8. Poruke se gube kada se sruši

U konfiguraciji bootstrap.servers Proizvođač ima na listi nekoliko brokera i može pitati drugog brokera ko je novi vođa sekcije. Zatim uspostavlja vezu sa brokerom 1 i nastavlja sa slanjem poruka.

Rice. 9. Slanje poruka se nastavlja nakon kratke pauze

Broker 3 još više zaostaje. Izrađuje zahtjeve za preuzimanje, ali se ne može sinhronizirati. Ovo može biti zbog spore mrežne veze između brokera, problema sa pohranom itd. Uklonjen je iz ISR-a. Sada se ISR sastoji od jedne replike - lidera! Proizvođač nastavlja slati poruke i primati potvrde.

Rice. 10. Pratilac na brokeru 3 se uklanja iz ISR-a

Broker 1 pada, a vodeća uloga ide na brokera 3 sa gubitkom 15286 poruka! Proizvođač prima poruku o grešci pri povezivanju. Prelazak na lidera izvan ISR-a bio je moguć samo zbog postavke unclean.leader.election.enable=true. Ako je instaliran u lažan, tada se prijelaz ne bi dogodio i svi zahtjevi za čitanje i pisanje bi bili odbijeni. U ovom slučaju čekamo da se broker 1 vrati sa svojim netaknutim podacima u replici, koja će ponovo preuzeti vodstvo.

Rice. 11. Broker 1 pada. Kada dođe do kvara, veliki broj poruka se gubi

Producent uspostavlja vezu sa zadnjim brokerom i vidi da je on sada vođa sekcije. Počinje da šalje poruke brokeru 3.

Rice. 12. Nakon kratke pauze, poruke se ponovo šalju u sekciju 0

Vidjeli smo da, osim kratkih prekida radi uspostavljanja novih veza i traženja novog lidera, proizvođač neprestano šalje poruke. Ova konfiguracija osigurava dostupnost na račun konzistentnosti (sigurnost podataka). Kafka je izgubio hiljade poruka, ali je nastavio da prihvata nove tekstove.

Acks=sve i ISR

Ponovimo ovaj scenario ponovo, ali sa acks=sve. Broker 3 ima prosječno kašnjenje od četiri sekunde. Proizvođač šalje poruku sa acks=sve, i sada ne dobija brz odgovor. Vođa čeka da poruku sačuvaju sve replike u ISR-u.

Rice. 13. ISR sa tri replike. Jedan je spor, što dovodi do kašnjenja snimanja

Nakon četiri sekunde dodatnog kašnjenja, broker 2 šalje potvrdu. Sve replike su sada potpuno ažurirane.

Rice. 14. Sve replike čuvaju poruke i šalju potvrdu

Broker 3 sada zaostaje dalje i uklonjen je iz ISR-a. Latencija je značajno smanjena jer u ISR-u nema sporih replika. Broker 2 sada čeka samo brokera 1, a on ima prosječno kašnjenje od 500 ms.

Rice. 15. Replika na brokeru 3 se uklanja iz ISR-a

Tada broker 2 pada i vodstvo prelazi na brokera 1 bez gubitka poruka.

Rice. 16. Broker 2 pada

Proizvođač pronalazi novog vođu i počinje mu slati poruke. Latencija je dodatno smanjena jer se ISR sada sastoji od jedne replike! Stoga opcija acks=sve ne dodaje redundantnost.

Rice. 17. Replika na brokeru 1 preuzima vodstvo bez gubljenja poruka

Tada se broker 1 sruši i prednost ide na brokera 3 sa gubitkom od 14238 poruka!

Rice. 18. Broker 1 umire i tranzicija rukovodstva s nečistom postavkom rezultira velikim gubitkom podataka

Nismo mogli instalirati opciju unclean.leader.election.enable u značenje istinski. Podrazumevano je jednako lažan. Postavke acks=sve с unclean.leader.election.enable=true pruža pristupačnost uz dodatnu sigurnost podataka. Ali kao što vidite, još uvijek možemo izgubiti poruke.

Ali šta ako želimo povećati sigurnost podataka? Možete staviti unclean.leader.election.enable = netačno, ali to nas neće nužno zaštititi od gubitka podataka. Ako je vođa teško pao i odnio podatke sa sobom, poruke su i dalje izgubljene, plus dostupnost je izgubljena dok administrator ne vrati situaciju.

Bolje je osigurati da su sve poruke suvišne, a u suprotnom odbacite snimak. Tada je, barem sa stanovišta brokera, gubitak podataka moguć samo u slučaju dva ili više istovremenih kvarova.

Acks=sve, min.insync.replike i ISR

Sa konfiguracijom teme min.insync.replicas Povećavamo nivo sigurnosti podataka. Idemo ponovo kroz zadnji dio prethodnog scenarija, ali ovaj put sa min.insync.replicas=2.

Dakle, broker 2 ima repliku lidera, a pratilac na brokeru 3 je uklonjen iz ISR-a.

Rice. 19. ISR iz dvije replike

Broker 2 pada i vodstvo prelazi na brokera 1 bez gubitka poruka. Ali sada se ISR sastoji od samo jedne replike. Ovo ne zadovoljava minimalni broj za primanje zapisa i stoga broker na pokušaj pisanja odgovara greškom NotEnoughReplicas.

Rice. 20. Broj ISR-ova je za jedan manji od navedenog u min.insync.replicas

Ova konfiguracija žrtvuje dostupnost radi konzistentnosti. Prije nego što potvrdimo poruku, osiguravamo da je napisana u najmanje dvije replike. Ovo proizvođaču daje mnogo više samopouzdanja. Ovdje je gubitak poruke moguć samo ako dvije replike ne uspiju istovremeno u kratkom intervalu dok se poruka ne replicira na dodatnog pratioca, što je malo vjerovatno. Ali ako ste super paranoični, možete postaviti faktor replikacije na 5 i min.insync.replicas za 3. Ovdje tri brokera moraju pasti u isto vrijeme da bi izgubili rekord! Naravno, ovu pouzdanost plaćate u dodatnom kašnjenju.

Kada je pristupačnost neophodna za sigurnost podataka

Kao u slučaj sa RabbitMQ, ponekad je pristupačnost neophodna za sigurnost podataka. Evo o čemu trebate razmisliti:

• Može li izdavač jednostavno vratiti grešku i naložiti uzvodnoj usluzi ili korisniku da pokuša ponovo kasnije?
• Može li izdavač sačuvati poruku lokalno ili u bazi podataka da pokuša ponovo kasnije?

Ako je odgovor ne, onda optimizacija dostupnosti poboljšava sigurnost podataka. Izgubit ćete manje podataka ako odaberete dostupnost umjesto da ne snimate. Dakle, sve se svodi na pronalaženje balansa, a odluka zavisi od konkretne situacije.

Značenje ISR

ISR paket vam omogućava da odaberete optimalnu ravnotežu između sigurnosti podataka i kašnjenja. Na primjer, osigurajte dostupnost u slučaju kvara većine replika, minimizirajući utjecaj mrtvih ili sporih replika u smislu kašnjenja.

Sami biramo značenje replica.lag.time.max.ms prema vašim potrebama. U suštini, ovaj parametar znači koliko kašnjenja smo spremni prihvatiti kada acks=sve. Zadana vrijednost je deset sekundi. Ako vam je ovo predugo, možete ga smanjiti. Tada će se učestalost promjena u ISR-u povećati, jer će se pratioci češće uklanjati i dodavati.

RabbitMQ je jednostavno skup ogledala koje treba replicirati. Spora ogledala unose dodatno kašnjenje, a mrtva ogledala mogu čekati dok paketi koji provjeravaju dostupnost svakog čvora (mrežni tik) odgovore. ISR je zanimljiv način za izbjegavanje ovih problema sa kašnjenjem. Ali rizikujemo da izgubimo višak jer se ISR može smanjiti samo do lidera. Da biste izbjegli ovaj rizik, koristite postavku min.insync.replicas.

Garancija na vezu sa klijentom

In settings bootstrap.servers proizvođač i potrošač mogu odrediti više brokera za povezivanje klijenata. Ideja je da kada se jedan čvor sruši, ostane nekoliko rezervnih sa kojima klijent može otvoriti vezu. Ovo nisu nužno vođe sekcija, već jednostavno odskočna daska za početno opterećenje. Klijent ih može pitati koji čvor hostuje vođu particije za čitanje/pisanje.

U RabbitMQ-u, klijenti se mogu povezati na bilo koji čvor, a interno rutiranje šalje zahtjev tamo gdje treba ići. To znači da možete instalirati balansator opterećenja ispred RabbitMQ-a. Kafka zahtijeva od klijenata da se povežu na čvor koji hostuje odgovarajući vođu particije. U takvoj situaciji ne možete instalirati balansator opterećenja. Lista bootstrap.servers Ključno je da klijenti mogu pristupiti i pronaći ispravne čvorove nakon kvara.

Kafkina konsenzus arhitektura

Do sada nismo razmatrali kako klaster saznaje za pad brokera i kako se bira novi lider. Da biste razumjeli kako Kafka radi sa mrežnim particijama, prvo morate razumjeti arhitekturu konsenzusa.

Svaki Kafka klaster je raspoređen zajedno sa Zookeeper klasterom, koji je distribuirani konsenzus servis koji omogućava sistemu da postigne konsenzus o nekom datom stanju, dajući prioritet konzistentnosti nad dostupnošću. Za odobravanje operacija čitanja i pisanja potrebna je saglasnost većine Zookeeper čvorova.

Zookeeper pohranjuje stanje klastera:

• Lista tema, sekcija, konfiguracija, trenutne replike lidera, preferirane replike.
• Članovi klastera. Svaki broker pinguje klaster Zookeeper. Ako ne primi ping u određenom vremenskom periodu, Zookeeper bilježi brokera kao nedostupnog.
• Odabir glavnog i rezervnog čvora za kontroler.

Kontrolni čvor je jedan od Kafka brokera koji je odgovoran za izbor vođa replika. Zookeeper šalje obavještenja kontroloru o članstvu u klasteru i promjenama teme, a kontrolor mora djelovati na te promjene.

Na primjer, uzmimo novu temu sa deset particija i faktorom replikacije 3. Kontrolor mora izabrati lidera za svaku particiju, pokušavajući optimalno rasporediti lidere među brokerima.

Za svaki kontroler sekcije:

• ažurira informacije u Zookeeper-u o ISR i vođi;
• Šalje LeaderAndISRCCommand svakom brokeru koji hostuje repliku ove particije, obavještavajući brokere o ISR-u i lideru.

Kada broker s liderom padne, Zookeeper šalje obavijest kontroloru i on bira novog vođu. Opet, kontrolor prvo ažurira Zookeeper, a zatim šalje naredbu svakom brokeru obavještavajući ga o promjeni vodstva.

Svaki lider je odgovoran za zapošljavanje ISR-a. Postavke replica.lag.time.max.ms određuje ko će tamo ući. Kada se ISR promijeni, vođa prenosi nove informacije Zookeeperu.

Zookeeper je uvijek obaviješten o svim promjenama, tako da u slučaju kvara menadžment nesmetano prelazi na novog vođu.

Rice. 21. Kafkin konsenzus

Protokol replikacije

Razumijevanje detalja replikacije pomaže vam bolje razumjeti potencijalne scenarije gubitka podataka.

Upiti za uzorkovanje, pomak na kraju dnevnika (LEO) i oznaka visoke vode (HW)

Smatrali smo da sljedbenici povremeno šalju zahtjeve za preuzimanje vođi. Podrazumevani interval je 500ms. Ovo se razlikuje od RabbitMQ-a po tome što u RabbitMQ replikaciju ne inicira zrcalo reda, već master. Majstor gura promjene na retrovizorima.

Vođa i svi sljedbenici čuvaju pomak kraja dnevnika (LEO) i oznaku Highwater (HW). LEO oznaka pohranjuje pomak posljednje poruke u lokalnoj replici, a HW drži pomak posljednjeg urezivanja. Zapamtite da za status urezivanja, poruka mora biti prisutna u svim ISR replikama. To znači da je LEO obično malo ispred HW.

Kada vođa primi poruku, pohranjuje je lokalno. Sljedbenik postavlja zahtjev za preuzimanje prenoseći svoj LEO. Vođa zatim šalje seriju poruka počevši od ovog LEO-a i također prenosi trenutni HW. Kada vođa primi informaciju da su sve replike pohranile poruku na datom pomaku, pomiče HW oznaku. Samo vođa može pomjeriti HW, pa će svi pratioci znati trenutnu vrijednost u odgovorima na njihov zahtjev. To znači da sljedbenici mogu zaostajati za liderom i u poruci i u znanju HW-a. Potrošači primaju poruke samo do trenutnog HW-a.

Imajte na umu da "postojano" znači zapisano u memoriju, a ne na disk. Za performanse, Kafka se sinhronizuje na disk u određenom intervalu. RabbitMQ također ima takav interval, ali će poslati potvrdu izdavaču tek nakon što master i svi ogledala zapišu poruku na disk. Programeri Kafke, iz razloga performansi, odlučili su da pošalju potvrdu čim se poruka upiše u memoriju. Kafka se kladi da redundantnost nadoknađuje rizik od kratkog pohranjivanja potvrđenih poruka samo u memoriju.

Neuspjeh lidera

Kada vođa padne, Zookeeper obavještava kontrolora i on bira novu repliku vođe. Novi vođa postavlja novu HW oznaku prema svom LEO-u. Sljedbenici tada dobijaju informacije o novom vođi. U zavisnosti od verzije Kafke, pratilac će izabrati jedan od dva scenarija:

1. Skratit će lokalni dnevnik na poznati HW i poslati zahtjev novom vođi za poruke nakon ove oznake.
2. Poslat će zahtjev lideru da sazna HW u vrijeme kada je izabran za vođu, a zatim skratiti dnevnik na ovaj pomak. Tada će početi sa periodičnim zahtjevima za dohvaćanje počevši od ovog pomaka.

Pratilac će možda morati da skrati dnevnik iz sledećih razloga:

• Kada vođa ne uspije, prvi pratilac u ISR setu registriran kod Zookeeper-a pobjeđuje na izborima i postaje vođa. Svi sljedbenici na ISR-u, iako se smatraju "sinhroniziranim", možda nisu primili kopije svih poruka od bivšeg vođe. Sasvim je moguće da istaknuti pratilac nema najnoviju kopiju. Kafka osigurava da nema odstupanja između replika. Stoga, da bi se izbjegla neslaganja, svaki sljedbenik mora skratiti svoj dnevnik na HW vrijednost novog lidera u vrijeme njegovog izbora. Ovo je još jedan razlog za postavljanje acks=sve toliko važno za konzistentnost.
• Poruke se periodično zapisuju na disk. Ako svi čvorovi klastera pokvare u isto vrijeme, tada će replike s različitim pomacima biti pohranjene na diskovima. Moguće je da će, kada se brokeri vrate na mrežu, novi lider koji bude izabran biti iza svojih sljedbenika jer je spremljen na disk prije ostalih.

Ponovno okupljanje sa klasterom

Prilikom ponovnog pridruživanja klasteru, replike rade isto kao i kada lider ne uspije: provjeravaju repliku vođe i skraćuju svoj dnevnik na njegov HW (u vrijeme izbora). Za usporedbu, RabbitMQ jednako tretira ponovno ujedinjene čvorove kao potpuno nove. U oba slučaja, broker odbacuje svako postojeće stanje. Ako se koristi automatska sinhronizacija, tada master mora replicirati apsolutno sav trenutni sadržaj na novo ogledalo u metodi „neka cijeli svijet čeka“. Master ne prihvata nikakve operacije čitanja ili pisanja tokom ove operacije. Ovaj pristup stvara probleme u velikim redovima.

Kafka je distribuirani dnevnik i općenito pohranjuje više poruka nego RabbitMQ red, gdje se podaci uklanjaju iz reda nakon što se pročitaju. Aktivni redovi bi trebali ostati relativno mali. Ali Kafka je dnevnik sa svojom politikom zadržavanja, koja može postaviti period od dana ili sedmica. Pristup blokiranja reda i pune sinhronizacije je apsolutno neprihvatljiv za distribuirani dnevnik. Umjesto toga, Kafkini sljedbenici jednostavno skraćuju svoj dnevnik na HW vođe (u vrijeme njegovog izbora) ako je njihova kopija ispred vođe. U vjerovatnijem slučaju, kada pratilac zaostaje, on jednostavno počinje da postavlja zahtjeve za preuzimanje počevši od svog trenutnog LEO-a.

Novi ili ponovo pridruženi pratioci počinju izvan ISR-a i ne učestvuju u urezivanju. Oni jednostavno rade zajedno sa grupom, primajući poruke što je brže moguće dok ne sustignu vođu i uđu u ISR. Nema zaključavanja i nema potrebe da odbacujete sve svoje podatke.

Poremećaj povezivanja

Kafka ima više komponenti od RabbitMQ-a, tako da ima složeniji skup ponašanja kada se klaster isključi. Ali Kafka je prvobitno dizajniran za klastere, tako da su rješenja vrlo dobro osmišljena.

Ispod je nekoliko scenarija neuspjeha povezivanja:

• Scenario 1: Pratilac ne vidi vođu, ali ipak vidi čuvara Zoološkog vrta.
• Scenario 2: Vođa ne vidi nijednog sljedbenika, ali i dalje vidi Zookeeper-a.
• Scenario 3: Pratilac vidi vođu, ali ne vidi čuvara zoološkog vrta.
• Scenario 4: Vođa vidi sljedbenike, ali ne vidi čuvara zoološkog vrta.
• Scenario 5: Pratilac je potpuno odvojen i od ostalih Kafka čvorova i od Zookeepera.
• Scenario 6: Vođa je potpuno odvojen i od ostalih Kafka čvorova i od Zookeepera.
• Scenario 7: Čvor Kafka kontrolera ne može vidjeti drugi Kafka čvor.
• Scenario 8: Kafka kontroler ne vidi Zookeeper.

Svaki scenario ima svoje ponašanje.

Scenario 1: Pratilac ne vidi vođu, ali i dalje vidi Zookeeper-a

Rice. 22. Scenario 1: ISR od tri replike

Greška povezivanja odvaja brokera 3 od brokera 1 i 2, ali ne i od Zookeeper-a. Broker 3 više ne može slati zahtjeve za preuzimanje. Nakon što je vrijeme prošlo replica.lag.time.max.ms uklonjen je iz ISR-a i ne učestvuje u urezivanju poruka. Jednom kada se konekcija uspostavi, nastavit će zahtjeve za preuzimanje i pridružiti se ISR-u kada sustigne lidera. Zookeeper će nastaviti primati pingove i pretpostavljati da je broker živ i zdrav.

Rice. 23. Scenario 1: Broker se uklanja iz ISR-a ako se od njega ne primi zahtjev za preuzimanje unutar replica.lag.time.max.ms intervala

Ne postoji split-brain ili node suspenzija kao u RabbitMQ. Umjesto toga, redundantnost je smanjena.

Scenario 2: Vođa ne vidi nijednog sljedbenika, ali i dalje vidi Zookeeper-a

Rice. 24. Scenario 2. Vođa i dva sljedbenika

Prekid mrežne povezanosti odvaja lidera od pratilaca, ali broker i dalje može vidjeti Zookeeper. Kao iu prvom scenariju, ISR se smanjuje, ali ovaj put samo na lidera jer svi sljedbenici prestaju slati zahtjeve za preuzimanje. Opet, nema logične podjele. Umjesto toga, dolazi do gubitka redundantnosti za nove poruke dok se ne uspostavi veza. Zookeeper nastavlja primati pingove i vjeruje da je broker živ i zdrav.

Rice. 25. Scenario 2. ISR se smanjio samo na lidera

Scenario 3. Pratilac vidi vođu, ali ne vidi čuvara zoološkog vrta

Pratilac je odvojen od Zookeeper-a, ali ne i od brokera sa vođom. Kao rezultat toga, sljedbenik nastavlja sa zahtjevima za preuzimanje i biti član ISR-a. Zookeeper više ne prima pingove i registruje pad brokera, ali pošto je samo pratilac, nema posledica nakon oporavka.

Rice. 26. Scenario 3: Pratilac nastavlja slati zahtjeve za preuzimanje vođi

Scenario 4. Vođa vidi sljedbenike, ali ne vidi čuvara Zoološkog vrta

Rice. 27. Scenario 4. Vođa i dva sljedbenika

Vođa je odvojen od Zookeeper-a, ali ne i od brokera sa sljedbenicima.

Rice. 28. Scenario 4: Vođa izolovan od Zookeeper-a

Nakon nekog vremena, Zookeeper će registrirati grešku brokera i obavijestiti kontrolora o tome. On će izabrati novog vođu među svojim sljedbenicima. Međutim, prvobitni vođa će i dalje misliti da je to vođa i nastavit će primati unose od acks=1. Sljedbenici mu više ne šalju zahtjeve za preuzimanje, pa će ih smatrati mrtvima i pokušati smanjiti ISR ​​na sebe. Ali pošto nema vezu sa Zookeeper-om, neće moći to da uradi i u tom trenutku će odbiti da prihvati bilo kakve dalje unose.

Poruke acks=sve neće primiti potvrdu jer ISR prvo uključuje sve replike, a poruke ne stižu do njih. Kada ih originalni vođa pokuša ukloniti iz ISR-a, neće to moći učiniti i uopće će prestati prihvaćati bilo kakve poruke.

Klijenti ubrzo primjećuju promjenu lidera i počinju slati zapise na novi server. Jednom kada se mreža vrati, originalni vođa vidi da više nije lider i skraćuje svoj dnevnik na HW vrijednost koju je novi lider imao u trenutku neuspjeha kako bi izbjegao divergenciju dnevnika. Zatim će početi slati zahtjeve za preuzimanje novom vođi. Svi zapisi originalnog vođe koji nisu replicirani na novog vođu su izgubljeni. Odnosno, poruke koje prvobitni vođa nije priznao u tih nekoliko sekundi dok su radila dva lidera biće izgubljene.

Rice. 29. Scenario 4. Lider na brokeru 1 postaje sljedbenik nakon što se mreža vrati

Scenario 5: Pratilac je potpuno odvojen i od ostalih Kafka čvorova i od Zookeepera

Pratilac je potpuno izolovan i od ostalih Kafka čvorova i od Zookeeper-a. On se jednostavno uklanja iz ISR-a dok se mreža ne obnovi, a zatim sustiže ostale.

Rice. 30. Scenario 5: Izolovani pratilac je uklonjen iz ISR-a

Scenario 6: Vođa je potpuno odvojen i od ostalih Kafka čvorova i od Zookeepera

Rice. 31. Scenario 6. Vođa i dva sljedbenika

Vođa je potpuno izolovan od svojih sljedbenika, kontrolora i čuvara zoološkog vrta. Za kratko vreme će nastaviti da prihvata unose od acks=1.

Rice. 32. Scenario 6: Izolacija vođe od drugih Kafka i Zookeeper čvorova

Nije primio zahtjeve nakon isteka replica.lag.time.max.ms, pokušat će smanjiti ISR ​​na sebe, ali to neće moći učiniti jer nema komunikacije sa Zookeeper-om, tada će prestati primati zapise.

U međuvremenu, Zookeeper će označiti izolovanog brokera kao mrtvog, a kontrolor će izabrati novog vođu.

Rice. 33. Scenario 6. Dva lidera

Originalni vođa može prihvatiti unose na nekoliko sekundi, ali onda prestaje prihvaćati poruke. Klijenti se ažuriraju svakih 60 sekundi s najnovijim metapodacima. Oni će biti obaviješteni o promjeni vođe i počet će slati unose novom vođi.

Rice. 34. Scenario 6: Proizvođači prelaze na novog lidera

Svi potvrđeni unosi koje je napravio originalni vođa nakon gubitka veze bit će izgubljeni. Kada se mreža obnovi, originalni vođa će otkriti preko Zookeeper-a da više nije vođa. Zatim će skratiti svoj dnevnik na HW novog lidera u vrijeme izbora i početi slati zahtjeve kao sljedbenik.

Rice. 35. Scenario 6: Originalni vođa postaje sljedbenik nakon što se mrežna konekcija ponovo uspostavi

U ovoj situaciji može doći do logičnog razdvajanja na kratak period, ali samo ako acks=1 и min.insync.replicas takođe 1. Logičko razdvajanje se automatski završava ili nakon što se mreža obnovi, kada prvobitni vođa shvati da više nije vođa, ili kada svi klijenti shvate da se vođa promenio i počnu pisati novom vođi - šta god da se prvo dogodi. U svakom slučaju, neke poruke će biti izgubljene, ali samo sa acks=1.

Postoji još jedna varijanta ovog scenarija gdje su, neposredno prije razdvajanja mreže, sljedbenici zaostajali, a lider je kompresovao ISR samo na sebe. Tada postaje izoliran zbog gubitka veze. Novi vođa je izabran, ali prvobitni vođa nastavlja da prihvata prijave, čak acks=sve, jer u ISR nema nikog osim njega. Ovi zapisi će biti izgubljeni kada se mreža vrati. Jedini način da izbjegnete ovu opciju je min.insync.replicas = 2.

Scenario 7: Čvor Kafka kontrolera ne može vidjeti drugi Kafka čvor

Uopšteno govoreći, kada se veza sa Kafka čvorom izgubi, kontroler mu neće moći prenijeti nikakvu informaciju o promjeni lidera. U najgorem slučaju, ovo će dovesti do kratkoročnog logičnog razdvajanja, kao u scenariju 6. Češće nego ne, broker jednostavno neće postati kandidat za vodstvo ako potonji ne uspije.

Scenario 8: Kafka kontroler ne vidi Zookeeper

Zookeeper neće primiti ping od palog kontrolera i izabrat će novi Kafka čvor kao kontroler. Originalni kontroler se može i dalje predstavljati kao takav, ali ne prima obavijesti od Zookeeper-a, tako da neće imati nikakve zadatke za obavljanje. Kada se mreža obnovi, shvatit će da više nije kontrolor, već da je postao običan Kafka čvor.

Zaključci iz scenarija

Vidimo da gubitak povezivanja pratioca ne dovodi do gubitka poruke, već jednostavno privremeno smanjuje redundantnost dok se mreža ne obnovi. To, naravno, može dovesti do gubitka podataka ako se izgubi jedan ili više čvorova.

Ako se vođa odvoji od Zookeeper-a zbog gubitka veze, to može rezultirati gubitkom poruka od acks=1. Nedostatak komunikacije sa Zookeeperom uzrokuje kratak logičan razlaz sa dvojicom vođa. Ovaj problem je riješen parametrom acks=sve.

Parametar min.insync.replicas u dvije ili više replika pruža dodatnu sigurnost da takvi kratkoročni scenariji neće rezultirati izgubljenim porukama kao u scenariju 6.

Sažetak izgubljenih poruka

Hajde da navedemo sve načine na koje možete izgubiti podatke u Kafki:

• Bilo kakav neuspjeh vođe ako su poruke potvrđene korištenjem acks=1
• Svaka nečista tranzicija vodstva, odnosno na sljedbenika izvan ISR-a, čak i sa acks=sve
• Izolacija vođe od Zookeepera ako su poruke potvrđene korištenjem acks=1
• Potpuna izolacija vođe koji je već smanjio ISR grupu na sebe. Sve poruke će biti izgubljene, čak acks=sve. Ovo je tačno samo ako min.insync.replicas=1.
• Istovremeni kvarovi svih particijskih čvorova. Budući da se poruke priznaju iz memorije, neke možda još nisu zapisane na disk. Nakon ponovnog pokretanja servera, neke poruke možda nedostaju.

Nečista tranzicija rukovođenja može se izbjeći ili zabranom ili osiguravanjem najmanje dva viška radnika. Najtrajnija konfiguracija je kombinacija acks=sve и min.insync.replicas više od 1.

Direktno poređenje pouzdanosti RabbitMQ-a i Kafke

Da bi se osigurala pouzdanost i visoka dostupnost, obje platforme implementiraju primarni i sekundarni sistem replikacije. Međutim, RabbitMQ ima Ahilovu petu. Prilikom ponovnog povezivanja nakon kvara, čvorovi odbacuju svoje podatke i sinhronizacija je blokirana. Ovaj dvostruki udarac dovodi u pitanje dugovječnost velikih redova u RabbitMQ-u. Morat ćete prihvatiti ili smanjenu redundanciju ili dugo vrijeme blokiranja. Smanjenje redundantnosti povećava rizik od velikog gubitka podataka. Ali ako su redovi mali, onda se radi redundantnosti, kratki periodi nedostupnosti (nekoliko sekundi) mogu riješiti korištenjem ponovljenih pokušaja povezivanja.

Kafka nema ovaj problem. Odbacuje podatke samo sa tačke razilaženja između vođe i sledbenika. Svi dijeljeni podaci su sačuvani. Osim toga, replikacija ne blokira sistem. Vođa nastavlja da prihvata objave dok novi pratilac sustiže, tako da za devops pridruživanje ili ponovno pridruživanje klasteru postaje trivijalan zadatak. Naravno, i dalje postoje problemi kao što je propusnost mreže tokom replikacije. Ako dodate više pratilaca u isto vrijeme, možete naići na ograničenje propusnosti.

RabbitMQ je superiorniji od Kafke u pouzdanosti kada više servera u klasteru otkaže u isto vrijeme. Kao što smo već rekli, RabbitMQ šalje potvrdu izdavaču tek nakon što je poruka zapisana na disk od strane mastera i svih ogledala. Ali ovo dodaje dodatno kašnjenje iz dva razloga:

• fsync svakih nekoliko stotina milisekundi
• Kvar ogledala može se primijetiti tek nakon što istekne vijek trajanja paketa koji provjeravaju dostupnost svakog čvora (net tick). Ako ogledalo uspori ili padne, to dodaje kašnjenje.

Kafkina opklada je da ako je poruka pohranjena na više čvorova, ona može potvrditi poruke čim stignu u memoriju. Zbog toga postoji rizik od gubitka poruka bilo koje vrste (čak acks=sve, min.insync.replicas=2) u slučaju istovremenog kvara.

Sve u svemu, Kafka pokazuje bolje performanse softvera i dizajniran je od temelja za klastere. Broj pratilaca se može povećati na 11 ako je potrebno radi pouzdanosti. Faktor replikacije 5 i minimalni broj replika u sinhronizaciji min.insync.replicas=3 će gubitak poruke učiniti vrlo rijetkim događajem. Ako vaša infrastruktura može podržati ovaj omjer replikacije i nivo redundancije, onda možete odabrati ovu opciju.

RabbitMQ klasterisanje je dobro za male redove. Ali čak i mali redovi mogu brzo rasti kada je promet gust. Kada se redovi postanu veliki, morat ćete napraviti teške izbore između dostupnosti i pouzdanosti. RabbitMQ klasterisanje je najprikladnije za netipične situacije u kojima su prednosti RabbitMQ-ove fleksibilnosti veće od svih nedostataka njegovog grupisanja.

Jedan protivotrov za ranjivost RabbitMQ-a na velike redove je da ih razbijete na mnogo manjih redova. Ako ne zahtijevate kompletno naručivanje cijelog reda, već samo relevantne poruke (na primjer, poruke od određenog klijenta), ili ne naručite ništa, onda je ova opcija prihvatljiva: pogledajte moj projekt Rebalanser da podijelite red (projekat je još u ranoj fazi).

Konačno, ne zaboravite na brojne greške u mehanizmima grupiranja i replikacije i RabbitMQ-a i Kafke. Vremenom su sistemi postali zreliji i stabilniji, ali nijedna poruka nikada neće biti 100% sigurna od gubitka! Osim toga, u data centrima se dešavaju nesreće velikih razmjera!

Ako sam nešto propustio, pogriješio ili se ne slažete sa bilo kojom tačkom, slobodno napišite komentar ili me kontaktirajte.

Često me pitaju: “Šta odabrati, Kafku ili RabbitMQ?”, “Koja je platforma bolja?”. Istina je da to stvarno ovisi o vašoj situaciji, trenutnom iskustvu itd. Oklevam da dam svoje mišljenje jer bi bilo previše pojednostavljivati ​​preporučiti jednu platformu za sve slučajeve upotrebe i moguća ograničenja. Napisao sam ovu seriju članaka kako biste mogli stvoriti svoje mišljenje.

Želim da kažem da su oba sistema lideri u ovoj oblasti. Možda sam malo pristrasan jer iz svog iskustva s projektima cijenim stvari poput zagarantovanog reda poruka i pouzdanosti.

Vidim druge tehnologije kojima nedostaje ova pouzdanost i zagarantovano naručivanje, zatim pogledam RabbitMQ i Kafku i shvatim nevjerovatnu vrijednost oba ova sistema.

izvor: www.habr.com