В artikulli i fundit ne shikuam grupimin e RabbitMQ për tolerancën e gabimeve dhe disponueshmërinë e lartë. Tani le të gërmojmë thellë në Apache Kafka.

Këtu njësia e replikimit është ndarja. Çdo temë ka një ose më shumë seksione. Çdo seksion ka një drejtues me ose pa ndjekës. Kur krijoni një temë, ju specifikoni numrin e ndarjeve dhe koeficientin e përsëritjes. Vlera e zakonshme është 3, që do të thotë tre kopje: një udhëheqës dhe dy ndjekës.

Oriz. 1. Katër seksione shpërndahen ndërmjet tre ndërmjetësve

Të gjitha kërkesat për lexim dhe shkrim shkojnë te drejtuesi. Ndjekësit i dërgojnë periodikisht kërkesa udhëheqësit për të marrë mesazhet më të fundit. Konsumatorët nuk u drejtohen kurrë ndjekësve; këta të fundit ekzistojnë vetëm për tepricë dhe tolerancë ndaj gabimeve.

Dështimi i ndarjes

Kur një ndërmjetës dështon, drejtuesit e disa seksioneve shpesh dështojnë. Në secilën prej tyre, një ndjekës nga një nyje tjetër bëhet udhëheqës. Në fakt, nuk është gjithmonë kështu, pasi faktori i sinkronizimit gjithashtu ndikon: nëse ka ndjekës të sinkronizuar, dhe nëse jo, atëherë nëse lejohet kalimi në një kopje të pasinkronizuar. Por le të mos i komplikojmë gjërat tani për tani.

Broker 3 largohet nga rrjeti dhe një drejtues i ri zgjidhet për seksionin 2 në ndërmjetësi 2.

Oriz. 2. Ndërmjetësi 3 vdes dhe ndjekësi i tij në ndërmjetësi 2 zgjidhet si drejtuesi i ri i ndarjes 2

Pastaj ndërmjetësi 1 largohet dhe seksioni 1 humbet gjithashtu udhëheqësin e tij, roli i të cilit kalon te ndërmjetësi 2.

Oriz. 3. Ka mbetur edhe një ndërmjetës. Të gjithë drejtuesit janë në një ndërmjetës me zero tepricë

Kur ndërmjetësi 1 kthehet në internet, ai shton katër ndjekës, duke siguruar një tepricë për secilën ndarje. Por të gjithë drejtuesit mbetën ende në ndërmjetësin 2.

Oriz. 4. Udhëheqësit mbeten në ndërmjetësin 2

Kur shfaqet ndërmjetësi 3, ne jemi përsëri në tre kopje për ndarje. Por të gjithë drejtuesit janë ende në ndërmjetësin 2.

Oriz. 5. Vendosja e pabalancuar e drejtuesve pas restaurimit të ndërmjetësve 1 dhe 3

Kafka ka një mjet për ribalancim më të mirë të liderit sesa RabbitMQ. Atje, duhej të përdorje një shtojcë ose skript të palës së tretë që ndryshoi politikat për migrimin e nyjes kryesore duke reduktuar tepricën gjatë migrimit. Përveç kësaj, për radhët e mëdha duhej të pranonim mosdisponueshmërinë gjatë sinkronizimit.

Kafka ka konceptin e "kopjeve të preferuara" për rolin e udhëheqësit. Kur krijohen ndarje temash, Kafka përpiqet të shpërndajë liderët në mënyrë të barabartë nëpër nyje dhe i shënon ata udhëheqës të parë si të preferuar. Me kalimin e kohës, për shkak të rindezjeve të serverit, dështimeve dhe prishjeve të lidhjes, drejtuesit mund të përfundojnë në nyje të tjera, si në rastin ekstrem të përshkruar më sipër.

Për ta rregulluar këtë, Kafka ofron dy opsione:

Opsioni auto.leader.rebalance.enable=true lejon nyjen e kontrolluesit të ricaktojë automatikisht liderët në kopjet e preferuara dhe në këtë mënyrë të rivendosë shpërndarjen uniforme.
Administratori mund të ekzekutojë skriptin kafka-preferuar-replika-zgjedhje.sh për ricaktimin manual.

Oriz. 6. Replikat pas ribalancimit

Ky ishte një version i thjeshtuar i dështimit, por realiteti është më kompleks, megjithëse nuk ka asgjë shumë të komplikuar këtu. Gjithçka ka të bëjë me kopjet e sinkronizuara (In-Sync Replicas, ISR).

Kopjet e sinkronizuara (ISR)

Një ISR është një grup kopjesh të një ndarjeje që konsiderohet "e sinkronizuar" (in-sinkronizuar). Ka një udhëheqës, por mund të mos ketë ndjekës. Një ndjekës konsiderohet i sinkronizuar nëse ka bërë kopje të sakta të të gjitha mesazheve të liderit përpara se të skadojë intervali kopje.lag.koha.max.ms.

Një ndjekës hiqet nga grupi ISR nëse:

nuk bëri një kërkesë për të zgjedhur për intervalin kopje.lag.koha.max.ms (supozohet i vdekur)
nuk ka arritur të përditësohet gjatë intervalit kopje.lag.koha.max.ms (konsiderohet i ngadaltë)

Ndjekësit bëjnë kërkesa për kampionim në interval replica.fetch.wait.max.ms, e cila është e paracaktuar në 500ms.

Për të shpjeguar qartë qëllimin e ISR, duhet të shohim konfirmimet nga prodhuesi dhe disa skenarë dështimi. Prodhuesit mund të zgjedhin kur ndërmjetësi të dërgojë konfirmimin:

acks=0, konfirmimi nuk është dërguar
acks=1, konfirmimi dërgohet pasi udhëheqësi të ketë shkruar një mesazh në regjistrin e tij lokal
acks=all, konfirmimi dërgohet pasi të gjitha kopjet në ISR të kenë shkruar mesazhin në regjistrat lokalë

Në terminologjinë e Kafkës, nëse ISR-ja ka ruajtur një mesazh, ai është "përkushtuar". Acks=all është opsioni më i sigurt, por gjithashtu shton vonesë shtesë. Le të shohim dy shembuj të dështimit dhe mënyrën se si opsionet e ndryshme të 'acks' ndërveprojnë me konceptin ISR.

Acks=1 dhe ISR

Në këtë shembull, do të shohim se nëse lideri nuk pret që çdo mesazh nga të gjithë ndjekësit të ruhet, atëherë humbja e të dhënave është e mundur nëse lideri dështon. Navigimi te një ndjekës i pasinkronizuar mund të aktivizohet ose çaktivizohet duke vendosur i papastër.udhëheqës.zgjedhje.mundësoj.

Në këtë shembull, prodhuesi ka vlerën acks=1. Seksioni shpërndahet në të tre ndërmjetësit. Broker 3 është prapa, është sinkronizuar me liderin tetë sekonda më parë dhe tani është 7456 mesazhe prapa. Broker 1 ishte vetëm një sekondë prapa. Prodhuesi ynë dërgon një mesazh dhe shpejt merr një përgjigje, pa shpenzimet e përgjithshme të ndjekësve të ngadaltë ose të vdekur që udhëheqësi nuk pret.

Oriz. 7. ISR me tre kopje

Broker 2 dështon dhe prodhuesi merr një gabim lidhjeje. Pasi udhëheqja kalon te ndërmjetësi 1, ne humbasim 123 mesazhe. Ndjekësi në ndërmjetësin 1 ishte pjesë e ISR, por nuk ishte plotësisht i sinkronizuar me liderin kur ai ra.

Oriz. 8. Mesazhet humbasin kur rrëzohet

Në konfigurim bootstrap.serverët Prodhuesi ka disa ndërmjetës të listuar dhe mund të pyesë një ndërmjetës tjetër se cili është drejtuesi i ri i seksionit. Më pas krijon një lidhje me ndërmjetësin 1 dhe vazhdon të dërgojë mesazhe.

Oriz. 9. Dërgimi i mesazheve rifillon pas një pushimi të shkurtër

Broker 3 është edhe më mbrapa. Bën kërkesa për marrjen, por nuk mund të sinkronizohet. Kjo mund të jetë për shkak të lidhjes së ngadaltë të rrjetit ndërmjet ndërmjetësve, problemit të ruajtjes, etj. Është hequr nga ISR. Tani ISR përbëhet nga një kopje - udhëheqësi! Prodhuesi vazhdon të dërgojë mesazhe dhe të marrë konfirmime.

Oriz. 10. Ndjekësi në ndërmjetësin 3 hiqet nga ISR

Broker 1 zbret dhe roli drejtues shkon tek ndërmjetësi 3 me humbjen e 15286 mesazheve! Prodhuesi merr një mesazh gabimi të lidhjes. Kalimi në një udhëheqës jashtë ISR ishte i mundur vetëm për shkak të vendosjes i papastër.lider.zgjedhje.aktivizoj=vërtetë. Nëse është i instaluar në i rremë, atëherë kalimi nuk do të ndodhte dhe të gjitha kërkesat për lexim dhe shkrim do të refuzoheshin. Në këtë rast, ne presim që ndërmjetësi 1 të kthehet me të dhënat e tij të paprekura në kopje, i cili do të marrë përsëri drejtimin.

Oriz. 11. Ndërmjetësi 1 bie. Kur ndodh një dështim, një numër i madh mesazhesh humbasin

Producenti krijon një lidhje me ndërmjetësin e fundit dhe sheh që ai tani është drejtuesi i seksionit. Ai fillon t'i dërgojë mesazhe ndërmjetësit 3.

Oriz. 12. Pas një pushimi të shkurtër, mesazhet dërgohen përsëri në seksionin 0

Ne pamë që, përveç ndërprerjeve të shkurtra për të krijuar lidhje të reja dhe për të kërkuar një udhëheqës të ri, prodhuesi dërgonte vazhdimisht mesazhe. Ky konfigurim siguron disponueshmërinë në kurriz të konsistencës (sigurisë së të dhënave). Kafka humbi mijëra mesazhe, por vazhdoi të pranonte shkrime të reja.

Acks=të gjitha dhe ISR

Le ta përsërisim përsëri këtë skenar, por me acks=të gjitha. Broker 3 ka një vonesë mesatare prej katër sekondash. Prodhuesi dërgon një mesazh me acks=të gjitha, dhe tani nuk merr një përgjigje të shpejtë. Udhëheqësi pret që mesazhi të ruhet nga të gjitha kopjet në ISR.

Oriz. 13. ISR me tre kopje. Njëra është e ngadaltë, duke rezultuar në vonesa në regjistrim

Pas katër sekondash vonese shtesë, ndërmjetësi 2 dërgon një pranim. Të gjitha kopjet tani janë përditësuar plotësisht.

Oriz. 14. Të gjitha kopjet ruajnë mesazhe dhe dërgojnë ack

Broker 3 tani është më mbrapa dhe është hequr nga ISR. Vonesa është reduktuar ndjeshëm sepse nuk ka mbetur kopje të ngadalta në ISR. Broker 2 tani pret vetëm për ndërmjetësin 1, dhe ai ka një vonesë mesatare prej 500 ms.

Oriz. 15. Replika në ndërmjetësin 3 hiqet nga ISR

Pastaj ndërmjetësi 2 bie dhe udhëheqja kalon te ndërmjetësi 1 pa humbur mesazhe.

Oriz. 16. Ndërmjetësi 2 bie

Prodhuesi gjen një udhëheqës të ri dhe fillon t'i dërgojë mesazhe atij. Vonesa zvogëlohet më tej sepse ISR tani përbëhet nga një kopje! Prandaj opsioni acks=të gjitha nuk shton tepricë.

Oriz. 17. Replica në ndërmjetësin 1 merr drejtimin pa humbur mesazhe

Pastaj ndërmjetësi 1 rrëzohet dhe kryesimi shkon te ndërmjetësi 3 me një humbje prej 14238 mesazhesh!

Oriz. 18. Ndërmjetësi 1 vdes dhe tranzicioni i lidershipit me mjedis të papastër rezulton në humbje të madhe të të dhënave

Nuk mund ta instalonim opsionin i papastër.udhëheqës.zgjedhje.mundësoj në kuptim i vërtetë. Si parazgjedhje është e barabartë me i rremë. Cilësimet acks=të gjitha с i papastër.lider.zgjedhje.aktivizoj=vërtetë ofron akses me disa siguri të shtuara të të dhënave. Por siç mund ta shihni, ne ende mund të humbasim mesazhe.

Por çka nëse duam të rrisim sigurinë e të dhënave? Mund të vendosni i papastër.udhëheqës.zgjedhje.aftësoj = i rremë, por kjo nuk do të na mbrojë domosdoshmërisht nga humbja e të dhënave. Nëse drejtuesi ra fort dhe i mori të dhënat me vete, atëherë mesazhet janë ende të humbura, plus disponueshmëria humbet derisa administratori të rivendosë situatën.

Është më mirë të siguroheni që të gjitha mesazhet të jenë të tepërta dhe përndryshe hidhni regjistrimin. Atëherë, të paktën nga këndvështrimi i ndërmjetësit, humbja e të dhënave është e mundur vetëm në rast të dy ose më shumë dështimeve të njëkohshme.

Acks=të gjitha, min.insync.replicas dhe ISR

Me konfigurim teme min.insync.kopje Ne po rrisim nivelin e sigurisë së të dhënave. Le të kalojmë përsëri pjesën e fundit të skenarit të mëparshëm, por këtë herë me min.insync.replicas=2.

Pra, ndërmjetësi 2 ka një drejtues kopje dhe ndjekësi në ndërmjetësin 3 hiqet nga ISR.

Oriz. 19. ISR nga dy kopje

Ndërmjetësi 2 bie dhe lidershipi i kalon ndërmjetësit 1 pa humbur mesazhe. Por tani ISR përbëhet nga vetëm një kopje. Kjo nuk plotëson numrin minimal për të marrë regjistrime, dhe për këtë arsye ndërmjetësi i përgjigjet përpjekjes për të shkruar me një gabim NotEnoughReplicas.

Oriz. 20. Numri i ISR-ve është një më i ulët se sa është specifikuar në min.insync.replicas

Ky konfigurim sakrifikon disponueshmërinë për qëndrueshmëri. Përpara se të pranojmë një mesazh, ne sigurohemi që ai të jetë shkruar në të paktën dy kopje. Kjo i jep prodhuesit shumë më tepër besim. Këtu, humbja e mesazhit është e mundur vetëm nëse dy kopje dështojnë njëkohësisht në një interval të shkurtër derisa mesazhi të përsëritet tek një ndjekës shtesë, gjë që nuk ka gjasa. Por nëse jeni super paranojak, mund ta vendosni faktorin e përsëritjes në 5, dhe min.insync.kopje nga 3. Këtu tre ndërmjetës duhet të bien në të njëjtën kohë për të humbur rekordin! Sigurisht, ju paguani për këtë besueshmëri në një vonesë shtesë.

Kur aksesueshmëria është e nevojshme për sigurinë e të dhënave

Si në rasti me RabbitMQ, ndonjëherë aksesueshmëria është e nevojshme për sigurinë e të dhënave. Ja çfarë duhet të mendoni:

A mundet botuesi thjesht të kthejë një gabim dhe të bëjë që shërbimi ose përdoruesi të provojë sërish më vonë?
A mundet botuesi ta ruajë mesazhin në nivel lokal ose në një bazë të dhënash për ta provuar përsëri më vonë?

Nëse përgjigja është jo, atëherë optimizimi i disponueshmërisë përmirëson sigurinë e të dhënave. Do të humbisni më pak të dhëna nëse zgjidhni disponueshmërinë në vend që të mos regjistroni. Kështu, gjithçka varet nga gjetja e një ekuilibri, dhe vendimi varet nga situata specifike.

Kuptimi i ISR

Kompleti ISR ju lejon të zgjidhni ekuilibrin optimal midis sigurisë së të dhënave dhe vonesës. Për shembull, siguroni disponueshmërinë në rast të dështimit të shumicës së kopjeve, duke minimizuar ndikimin e kopjeve të vdekura ose të ngadalta për sa i përket vonesës.

Ne e zgjedhim vetë kuptimin kopje.lag.koha.max.ms sipas nevojave tuaja. Në thelb, ky parametër nënkupton se sa vonesë jemi të gatshëm të pranojmë kur acks=të gjitha. Vlera e paracaktuar është dhjetë sekonda. Nëse kjo është shumë e gjatë për ju, mund ta zvogëloni atë. Atëherë frekuenca e ndryshimeve në ISR do të rritet, pasi ndjekësit do të hiqen dhe shtohen më shpesh.

RabbitMQ është thjesht një grup pasqyrash që duhet të përsëriten. Pasqyrat e ngadalta sjellin vonesë shtesë, dhe pasqyrat e vdekura mund të presin derisa paketat që kontrollojnë disponueshmërinë e secilës nyje (shënoni neto) të përgjigjen. ISR është një mënyrë interesante për të shmangur këto çështje latente. Por ne rrezikojmë të humbasim tepricën pasi ISR mund të tkurret vetëm tek lideri. Për të shmangur këtë rrezik, përdorni cilësimin min.insync.kopje.

Garancia e lidhjes me klientin

Në cilësimet bootstrap.serverët prodhuesi dhe konsumatori mund të specifikojnë ndërmjetësues të shumtë për lidhjen e klientëve. Ideja është që kur një nyje zbret, mbeten disa nyje rezervë me të cilat klienti mund të hapë një lidhje. Këta nuk janë domosdoshmërisht drejtues seksionesh, por thjesht një trampolinë për ngarkimin fillestar. Klienti mund t'i pyesë se cila nyje pret liderin e ndarjes për lexim/shkrim.

Në RabbitMQ, klientët mund të lidhen me çdo nyje, dhe rutimi i brendshëm dërgon kërkesën atje ku duhet të shkojë. Kjo do të thotë që mund të instaloni një balancues ngarkese përpara RabbitMQ. Kafka kërkon që klientët të lidhen me nyjen që pret liderin përkatës të ndarjes. Në një situatë të tillë, nuk mund të instaloni një balancues të ngarkesës. Listë bootstrap.serverët Është e rëndësishme që klientët të kenë akses dhe të gjejnë nyjet e sakta pas një dështimi.

Arkitektura e Konsensusit Kafka

Deri më tani, ne nuk kemi marrë parasysh se si grupi mëson për rënien e ndërmjetësit dhe se si zgjidhet një drejtues i ri. Për të kuptuar se si funksionon Kafka me ndarjet e rrjetit, së pari duhet të kuptoni arkitekturën e konsensusit.

Çdo grup Kafka vendoset së bashku me një grup Zookeeper, i cili është një shërbim konsensusi i shpërndarë që lejon sistemin të arrijë konsensus për një gjendje të caktuar, duke i dhënë përparësi konsistencës mbi disponueshmërinë. Për të miratuar operacionet e leximit dhe shkrimit kërkohet pëlqimi i shumicës së nyjeve të Zookeeper.

Zookeeper ruan gjendjen e grupit:

Lista e temave, seksioneve, konfigurimi, kopjet aktuale të liderit, kopjet e preferuara.
Anëtarët e grupit. Çdo ndërmjetës pingzon grupin Zookeeper. Nëse nuk merr një ping brenda një periudhe të caktuar kohore, atëherë Zookeeper e regjistron ndërmjetësin si të padisponueshëm.
Zgjedhja e nyjeve kryesore dhe rezervë për kontrolluesin.

Nyja e kontrolluesit është një nga ndërmjetësit e Kafkës që është përgjegjës për zgjedhjen e drejtuesve të kopjeve. Zookeeper i dërgon njoftime kontrolluesit në lidhje me anëtarësimin në grup dhe ndryshimet e temave, dhe kontrolluesi duhet të veprojë sipas këtyre ndryshimeve.

Për shembull, le të marrim një temë të re me dhjetë ndarje dhe një faktor replikimi prej 3. Kontrolluesi duhet të zgjedhë një udhëheqës për secilën ndarje, duke u përpjekur të shpërndajë në mënyrë optimale liderët midis ndërmjetësve.

Për çdo kontrollues seksioni:

përditëson informacionin në Zookeeper rreth ISR dhe udhëheqësit;
Dërgon një Komandë LeaderAndISR për çdo ndërmjetës që pret një kopje të kësaj ndarjeje, duke informuar ndërmjetësit për ISR-në dhe udhëheqësin.

Kur një ndërmjetës me një drejtues bie, Zookeeper i dërgon një njoftim kontrolluesit dhe ai zgjedh një drejtues të ri. Përsëri, kontrolluesi së pari përditëson Zookeeper dhe më pas i dërgon një komandë secilit ndërmjetës duke i njoftuar ata për ndryshimin e lidershipit.

Çdo udhëheqës është përgjegjës për rekrutimin e ISR-ve. Cilësimet kopje.lag.koha.max.ms përcakton se kush do të hyjë atje. Kur ndryshon ISR, drejtuesi transmeton informacion të ri te Zookeeper.

Zookeeper është gjithmonë i informuar për çdo ndryshim, në mënyrë që në rast të një dështimi, menaxhmenti të kalojë pa probleme në një drejtues të ri.

Oriz. 21. Konsensusi i Kafkës

Protokolli i replikimit

Kuptimi i detajeve të përsëritjes ju ndihmon të kuptoni më mirë skenarët e mundshëm të humbjes së të dhënave.

Pyetjet e kampionimit, Log End Offset (LEO) dhe Highwater Mark (HW)

Ne konsideruam se ndjekësit i dërgojnë periodikisht kërkesa për të marrë liderit. Intervali i paracaktuar është 500ms. Kjo ndryshon nga RabbitMQ në atë që në RabbitMQ replikimi nuk inicohet nga pasqyra e radhës por nga masteri. Mjeshtri shtyn ndryshimet në pasqyra.

Lideri dhe të gjithë ndjekësit ruajnë etiketën Log End Offset (LEO) dhe Highwater (HW). Shenja LEO ruan kompensimin e mesazhit të fundit në kopjen lokale, dhe HW mban kompensimin e kryerjes së fundit. Mos harroni se për statusin e kryerjes, mesazhi duhet të vazhdojë në të gjitha kopjet ISR. Kjo do të thotë që LEO zakonisht është pak përpara HW.

Kur udhëheqësi merr një mesazh, ai e ruan atë në vend. Ndjekësi bën një kërkesë për të marrë duke transmetuar LEO-n e tij. Lideri më pas dërgon një grup mesazhesh duke filluar nga ky LEO dhe gjithashtu transmeton HW aktuale. Kur drejtuesi merr informacion se të gjitha kopjet e kanë ruajtur mesazhin në zhvendosjen e dhënë, ai lëviz shenjën HW. Vetëm udhëheqësi mund të lëvizë HW, dhe kështu të gjithë ndjekësit do të dinë vlerën aktuale në përgjigjet ndaj kërkesës së tyre. Kjo do të thotë se ndjekësit mund të mbeten prapa liderit si në njohuritë e mesazheve ashtu edhe në HW. Konsumatorët marrin mesazhe vetëm deri në HW aktuale.

Vini re se "persisted" do të thotë e shkruar në memorie, jo në disk. Për performancën, Kafka sinkronizohet në disk në një interval të caktuar. RabbitMQ gjithashtu ka një interval të tillë, por ai do t'i dërgojë një konfirmim botuesit vetëm pasi masteri dhe të gjitha pasqyrat të kenë shkruar mesazhin në disk. Zhvilluesit e Kafka, për arsye të performancës, vendosën të dërgojnë një pranim sapo mesazhi të shkruhet në kujtesë. Kafka vë bast se teprica kompenson rrezikun e ruajtjes së shkurtër të mesazheve të pranuara vetëm në kujtesë.

Dështimi i liderit

Kur një udhëheqës bie, Zookeeper njofton kontrolluesin dhe ai zgjedh një kopje të re të drejtuesit. Lideri i ri vendos një shenjë të re HW sipas LEO-t të tij. Pasuesit më pas marrin informacion për udhëheqësin e ri. Në varësi të versionit të Kafkës, ndjekësi do të zgjedhë një nga dy skenarët:

Ai do të shkurtojë regjistrin lokal në një HW të njohur dhe do t'i dërgojë një kërkesë udhëheqësit të ri për mesazhe pas kësaj shenje.
Do t'i dërgojë një kërkesë udhëheqësit për të zbuluar HW-në në kohën kur ai u zgjodh drejtues dhe më pas do të shkurtojë regjistrin në këtë kompensim. Më pas do të fillojë të bëjë kërkesa periodike për tërheqje duke filluar nga ky kompensim.

Një ndjekës mund të ketë nevojë të shkurtojë regjistrin për arsyet e mëposhtme:

Kur një udhëheqës dështon, ndjekësi i parë në grupin ISR i regjistruar në Zookeeper fiton zgjedhjet dhe bëhet lider. Të gjithë ndjekësit në ISR, megjithëse konsiderohen "në sinkron", mund të mos kenë marrë kopje të të gjitha mesazheve nga ish-udhëheqësi. Është plotësisht e mundur që ndjekësi i paraqitur të mos ketë kopjen më të përditësuar. Kafka siguron që nuk ka divergjencë midis kopjeve. Kështu, për të shmangur mospërputhjet, çdo ndjekës duhet të shkurtojë regjistrin e tij në vlerën HW të liderit të ri në kohën e zgjedhjes së tij. Kjo është një arsye tjetër pse vendosja acks=të gjitha kaq e rëndësishme për konsistencën.
Mesazhet shkruhen periodikisht në disk. Nëse të gjitha nyjet e grupimit dështojnë në të njëjtën kohë, atëherë kopjet me zhvendosje të ndryshme do të ruhen në disqe. Është e mundur që kur ndërmjetësit të kthehen në internet, lideri i ri që zgjidhet do të jetë pas ndjekësve të tij, sepse ai u ruajt në disk para të tjerëve.

Ribashkim me grupin

Kur ribashkohen me grupin, kopjet bëjnë të njëjtën gjë si kur një drejtues dështon: ata kontrollojnë kopjen e liderit dhe shkurtojnë regjistrin e tyre në HW të tij (në kohën e zgjedhjes). Në krahasim, RabbitMQ i trajton në mënyrë të barabartë nyjet e bashkuara si krejtësisht të reja. Në të dyja rastet, ndërmjetësi hedh poshtë çdo gjendje ekzistuese. Nëse përdoret sinkronizimi automatik, atëherë masteri duhet të kopjojë absolutisht të gjithë përmbajtjen aktuale në pasqyrën e re në metodën "le të presë e gjithë bota". Masteri nuk pranon asnjë operacion leximi ose shkrimi gjatë këtij operacioni. Kjo qasje krijon probleme në radhë të mëdha.

Kafka është një regjistër i shpërndarë dhe në përgjithësi ruan më shumë mesazhe sesa një radhë RabbitMQ, ku të dhënat hiqen nga radha pasi lexohen. Radhët aktive duhet të mbeten relativisht të vogla. Por Kafka është një regjistër me politikën e vet të ruajtjes, i cili mund të caktojë një periudhë prej ditësh ose javësh. Qasja e bllokimit të radhës dhe sinkronizimit të plotë është absolutisht e papranueshme për një regjistër të shpërndarë. Në vend të kësaj, ndjekësit e Kafkës thjesht e shkurtojnë regjistrin e tyre në HW të liderit (në kohën e zgjedhjes së tij) nëse kopja e tyre është përpara liderit. Në rastin më të mundshëm, kur ndjekësi është prapa, ai thjesht fillon të bëjë kërkesa për tërheqje duke filluar me LEO-n e tij aktual.

Ndjekësit e rinj ose të ribashkuar fillojnë jashtë ISR dhe nuk marrin pjesë në angazhime. Ata thjesht punojnë së bashku me grupin, duke marrë mesazhe sa më shpejt që të munden derisa të arrijnë me liderin dhe të hyjnë në ISR. Nuk ka asnjë bllokim dhe nuk ka nevojë të hidhni tutje të gjitha të dhënat tuaja.

Humbja e lidhjes

Kafka ka më shumë komponentë se RabbitMQ, kështu që ka një grup sjelljesh më komplekse kur grupi shkëputet. Por Kafka fillimisht ishte projektuar për grupime, kështu që zgjidhjet janë menduar shumë mirë.

Më poshtë janë disa skenarë të dështimit të lidhjes:

Skenari 1: Ndjekësi nuk e sheh udhëheqësin, por ende sheh Kujdestarin e Zookit.
Skenari 2: Drejtuesi nuk sheh asnjë ndjekës, por ende sheh Zookeeper.
Skenari 3: Ndjekësi sheh udhëheqësin, por nuk e sheh Zookeeper.
Skenari 4: Udhëheqësi i sheh ndjekësit, por nuk e sheh Kujdestarin e Zookit.
Skenari 5: Ndjekësi është plotësisht i ndarë nga nyjet e tjera Kafka dhe Zookeeper.
Skenari 6: Udhëheqësi është plotësisht i ndarë nga të dy nyjet e tjera Kafka dhe Zookeeper.
Skenari 7: Nyja e kontrolluesit Kafka nuk mund të shohë një nyje tjetër Kafka.
Skenari 8: Kontrolluesi i Kafkës nuk e sheh Zookeeper.

Çdo skenar ka sjelljen e vet.

Skenari 1: Ndjekësi nuk e sheh udhëheqësin, por ende sheh Zookeeper

Oriz. 22. Skenari 1: ISR e tre kopjeve

Dështimi i lidhjes ndan ndërmjetësin 3 nga ndërmjetësit 1 dhe 2, por jo nga Zookeeper. Broker 3 nuk mund të dërgojë më kërkesa për tërheqje. Pasi ka kaluar koha kopje.lag.koha.max.ms ai hiqet nga ISR dhe nuk merr pjesë në kryerjen e mesazheve. Pasi të rikthehet lidhja, ajo do të rifillojë marrjen e kërkesave dhe do të bashkohet me ISR-në kur të arrijë me drejtuesin. Zookeeper do të vazhdojë të marrë ping dhe do të supozojë se ndërmjetësi është gjallë dhe mirë.

Oriz. 23. Skenari 1: Ndërmjetësi hiqet nga ISR nëse nuk merret asnjë kërkesë për tërheqje prej tij brenda intervalit replica.lag.time.max.ms

Nuk ka asnjë pezullim të trurit ose nyjeve si në RabbitMQ. Në vend të kësaj, teprica zvogëlohet.

Skenari 2: Udhëheqësi nuk sheh asnjë ndjekës, por ende sheh Zookeeper

Oriz. 24. Skenari 2. Udhëheqësi dhe dy ndjekës

Një ndarje në lidhjen e rrjetit ndan liderin nga ndjekësit, por ndërmjetësi mund të shohë akoma Zookeeper. Ashtu si në skenarin e parë, ISR zvogëlohet, por këtë herë vetëm për liderin pasi të gjithë ndjekësit ndalojnë dërgimin e kërkesave për marrjen. Përsëri, nuk ka ndarje logjike. Në vend të kësaj, ka një humbje të tepricës për mesazhet e reja derisa lidhja të rikthehet. Zookeeper vazhdon të marrë ping dhe beson se ndërmjetësi është gjallë dhe mirë.

Oriz. 25. Skenari 2. ISR është tkurrur vetëm tek lideri

Skenari 3. Ndjekësi sheh udhëheqësin, por nuk e sheh Zookeeeper

Ndjekësi ndahet nga Zookeeper, por jo nga ndërmjetësi me drejtuesin. Si rezultat, ndjekësi vazhdon të bëjë kërkesa të marra dhe të jetë anëtar i ISR. Zookeeper nuk merr më ping dhe regjistron një përplasje ndërmjetësi, por duke qenë se është vetëm një ndjekës, nuk ka pasoja pas rikuperimit.

Oriz. 26. Skenari 3: Ndjekësi vazhdon t'i dërgojë liderit kërkesa për tërheqje

Skenari 4. Udhëheqësi sheh ndjekësit, por nuk sheh Zookeeper

Oriz. 27. Skenari 4. Udhëheqësi dhe dy ndjekës

Udhëheqësi ndahet nga Zookeeper, por jo nga brokerat me ndjekës.

Oriz. 28. Skenari 4: Udhëheqësi i izoluar nga Zookeeper

Pas ca kohësh, Zookeeper do të regjistrojë një dështim të ndërmjetësit dhe do të njoftojë kontrolluesin për këtë. Ai do të zgjedhë një udhëheqës të ri mes ndjekësve të tij. Megjithatë, udhëheqësi origjinal do të vazhdojë të mendojë se është lideri dhe do të vazhdojë të pranojë hyrje nga acks=1. Ndjekësit nuk po i dërgojnë më kërkesa për tërheqje, kështu që ai do t'i konsiderojë ato të vdekura dhe do të përpiqet të zvogëlojë ISR-në në vetvete. Por meqenëse nuk ka lidhje me Zookeeper, nuk do të jetë në gjendje ta bëjë këtë dhe në atë moment do të refuzojë të pranojë çdo hyrje të mëtejshme.

Сообщения acks=të gjitha nuk do të marrë një konfirmim sepse ISR fillimisht aktivizon të gjitha kopjet dhe mesazhet nuk arrijnë tek ata. Kur udhëheqësi fillestar përpiqet t'i heqë ato nga ISR, ai nuk do të jetë në gjendje ta bëjë këtë dhe nuk do të pranojë fare mesazhe.

Klientët së shpejti vërejnë ndryshimin në lider dhe fillojnë të dërgojnë regjistrime në serverin e ri. Pasi rrjeti të restaurohet, drejtuesi fillestar sheh se nuk është më një udhëheqës dhe e shkurton regjistrin e tij në vlerën HW që lideri i ri kishte në kohën e dështimit për të shmangur divergjencën e regjistrave. Më pas do të fillojë dërgimi i kërkesave për tërheqje tek lideri i ri. Të gjitha regjistrimet nga lideri origjinal që nuk janë përsëritur te lideri i ri humbasin. Do të thotë, mesazhet që nuk u pranuan nga drejtuesi fillestar në ato pak sekonda kur punonin dy liderë do të humbasin.

Oriz. 29. Skenari 4. Lideri në ndërmjetësin 1 bëhet ndjekës pasi rrjeti të rikthehet

Skenari 5: Ndjekësi është plotësisht i ndarë nga nyjet e tjera Kafka dhe Zookeeper

Ndjekësi është plotësisht i izoluar si nga nyjet e tjera Kafka ashtu edhe nga Zookeeper. Ai thjesht e largon veten nga ISR derisa rrjeti të restaurohet, dhe më pas kap hapin me të tjerët.

Oriz. 30. Skenari 5: Ndjekësi i izoluar hiqet nga ISR

Skenari 6: Udhëheqësi është plotësisht i ndarë nga të dy nyjet e tjera Kafka dhe Zookeeper

Oriz. 31. Skenari 6. Udhëheqësi dhe dy ndjekës

Udhëheqësi është plotësisht i izoluar nga ndjekësit e tij, kontrolluesi dhe kujdestari i kopshtit. Për një periudhë të shkurtër do të vazhdojë të pranojë hyrje nga acks=1.

Oriz. 32. Skenari 6: Izolimi i liderit nga nyjet e tjera Kafka dhe Zookeeper

Nuk ka marrë kërkesa pas skadimit kopje.lag.koha.max.ms, do të përpiqet të zvogëlojë ISR-në në vetvete, por nuk do të jetë në gjendje ta bëjë këtë sepse nuk ka komunikim me Zookeeper, atëherë do të ndalojë së pranuari shkrime.

Ndërkohë, Zookeeper do të shënojë ndërmjetësin e izoluar si të vdekur dhe kontrolluesi do të zgjedhë një drejtues të ri.

Oriz. 33. Skenari 6. Dy drejtues

Udhëheqësi origjinal mund të pranojë shënime për disa sekonda, por më pas nuk pranon asnjë mesazh. Klientët përditësohen çdo 60 sekonda me meta të dhënat më të fundit. Ata do të informohen për ndryshimin e liderit dhe do të fillojnë t'i dërgojnë shënime drejtuesit të ri.

Oriz. 34. Skenari 6: Prodhuesit kalojnë në një udhëheqës të ri

Të gjitha hyrjet e konfirmuara të bëra nga drejtuesi origjinal që nga humbja e lidhjes do të humbasin. Pasi rrjeti të restaurohet, drejtuesi origjinal do të zbulojë përmes Zookeeper se nuk është më udhëheqësi. Më pas do të shkurtojë regjistrin e tij në HW të liderit të ri në kohën e zgjedhjes dhe do të fillojë të dërgojë kërkesa si ndjekës.

Oriz. 35. Skenari 6: Udhëheqësi origjinal bëhet ndjekës pas rivendosjes së lidhjes së rrjetit

Në këtë situatë, ndarja logjike mund të ndodhë për një periudhë të shkurtër, por vetëm nëse acks=1 и min.insync.kopje gjithashtu 1. Ndarja logjike përfundon automatikisht ose pasi të rikthehet rrjeti, kur udhëheqësi origjinal kupton se ai nuk është më udhëheqësi, ose kur të gjithë klientët kuptojnë se lideri ka ndryshuar dhe fillojnë t'i shkruajnë liderit të ri - cilado që të ndodhë e para. Në çdo rast, disa mesazhe do të humbasin, por vetëm me acks=1.

Ekziston një variant tjetër i këtij skenari ku, pak para ndarjes së rrjetit, ndjekësit mbetën prapa dhe lideri e kompresoi ISR-në vetëm në vetvete. Më pas bëhet i izoluar për shkak të humbjes së lidhjes. Një drejtues i ri zgjidhet, por drejtuesi origjinal vazhdon të pranojë, madje, hyrje acks=të gjitha, sepse nuk ka askush tjetër në ISR përveç tij. Këto të dhëna do të humbasin pasi rrjeti të rikthehet. Mënyra e vetme për të shmangur këtë opsion është min.insync.kopje = 2.

Skenari 7: Nyja e kontrolluesit të Kafkës nuk mund të shohë një nyje tjetër të Kafkës

Në përgjithësi, pasi lidhja me një nyje Kafka humbet, kontrolluesi nuk do të jetë në gjendje t'i transmetojë asaj asnjë informacion për ndryshimin e udhëheqësit. Në rastin më të keq, kjo do të çojë në një ndarje logjike afatshkurtër, si në skenarin 6. Më shpesh sesa jo, ndërmjetësi thjesht nuk do të bëhet kandidat për udhëheqje nëse ky i fundit dështon.

Skenari 8: Kontrolluesi Kafka nuk e sheh Zookeeper

Zookeeper nuk do të marrë një ping nga kontrolluesi i rënë dhe do të zgjedhë një nyje të re Kafka si kontrollues. Kontrolluesi origjinal mund të vazhdojë të prezantohet si i tillë, por nuk merr njoftime nga Zookeeper, kështu që nuk do të ketë asnjë detyrë për të kryer. Pasi rrjeti të restaurohet, ai do të kuptojë se nuk është më një kontrollues, por është bërë një nyje e rregullt e Kafkës.

Konkluzione nga skenarët

Ne shohim që humbja e lidhjes së ndjekësve nuk rezulton në humbje të mesazhit, por thjesht redukton përkohësisht tepricën derisa rrjeti të rikthehet. Kjo, natyrisht, mund të çojë në humbje të të dhënave nëse humbasin një ose më shumë nyje.

Nëse drejtuesi ndahet nga Zookeeper për shkak të humbjes së lidhjes, kjo mund të rezultojë në humbjen e mesazheve nga acks=1. Mungesa e komunikimit me Zookeeper shkakton një ndarje të shkurtër logjike me dy drejtuesit. Ky problem zgjidhet nga parametri acks=të gjitha.

Parametër min.insync.kopje në dy ose më shumë kopje ofron siguri shtesë se skenarë të tillë afatshkurtër nuk do të rezultojnë në mesazhe të humbura si në skenarin 6.

Përmbledhje e Mesazheve të Humbura

Le të rendisim të gjitha mënyrat se si mund të humbni të dhënat në Kafka:

Çdo dështim i liderit nëse mesazhet konfirmoheshin duke përdorur acks=1
Çdo tranzicion i papastër i udhëheqjes, domethënë tek një ndjekës jashtë ISR, madje edhe me acks=të gjitha
Izolimi i udhëheqësit nga Zookeeper nëse mesazhet konfirmohen duke përdorur acks=1
Izolimi i plotë i liderit i cili tashmë e ka tkurrur grupin ISR në vetvete. Të gjitha mesazhet do të humbasin, madje acks=të gjitha. Kjo është e vërtetë vetëm nëse min.insync.replicas=1.
Dështime të njëkohshme të të gjitha nyjeve të ndarjes. Për shkak se mesazhet pranohen nga memoria, disa mund të mos jenë shkruar ende në disk. Pas rinisjes së serverëve, disa mesazhe mund të mungojnë.

Tranzicionet e papastërta të lidershipit mund të shmangen ose duke i ndaluar ato ose duke siguruar të paktën dy teprica. Konfigurimi më i qëndrueshëm është një kombinim acks=të gjitha и min.insync.kopje më shumë se 1.

Krahasimi i drejtpërdrejtë i besueshmërisë së RabbitMQ dhe Kafka

Për të siguruar besueshmëri dhe disponueshmëri të lartë, të dyja platformat zbatojnë një sistem replikimi primar dhe dytësor. Megjithatë, RabbitMQ ka një thembër të Akilit. Kur rilidhen pas një dështimi, nyjet hedhin poshtë të dhënat e tyre dhe sinkronizimi bllokohet. Kjo goditje e dyfishtë vë në pikëpyetje jetëgjatësinë e radhëve të mëdha në RabbitMQ. Ju do të duhet të pranoni ose ulje të tepricës ose kohë të gjata bllokimi. Reduktimi i tepricës rrit rrezikun e humbjes masive të të dhënave. Por nëse radhët janë të vogla, atëherë për hir të tepricës, periudhat e shkurtra të padisponueshmërisë (disa sekonda) mund të trajtohen duke përdorur përpjekje të përsëritura për lidhje.

Kafka nuk e ka këtë problem. Ai hedh poshtë të dhënat vetëm nga pika e divergjencës midis liderit dhe ndjekësit. Të gjitha të dhënat e përbashkëta ruhen. Për më tepër, përsëritja nuk e bllokon sistemin. Lideri vazhdon të pranojë postime ndërsa ndjekësi i ri arrin, kështu që për devops, bashkimi ose ribashkimi në grup bëhet një detyrë e parëndësishme. Sigurisht, ka ende çështje të tilla si gjerësia e brezit të rrjetit gjatë riprodhimit. Nëse shtoni shumë ndjekës në të njëjtën kohë, mund të hasni një kufi të gjerësisë së brezit.

RabbitMQ është superior ndaj Kafkës në besueshmëri kur shumë serverë në një grup dështojnë në të njëjtën kohë. Siç kemi thënë tashmë, RabbitMQ i dërgon një konfirmim botuesit vetëm pasi mesazhi të shkruhet në disk nga masteri dhe të gjitha pasqyrat. Por kjo shton vonesë shtesë për dy arsye:

fsync çdo disa qindra milisekonda
Dështimi i pasqyrës mund të vërehet vetëm pasi të ketë skaduar jetëgjatësia e paketave që kontrollojnë disponueshmërinë e secilës nyje (neto tick). Nëse pasqyra ngadalësohet ose bie, kjo shton një vonesë.

Basti i Kafkës është që nëse një mesazh ruhet nëpër nyje të shumta, ai mund të pranojë mesazhet sapo të godasin memorien. Për shkak të kësaj, ekziston rreziku i humbjes së mesazheve të çdo lloji (madje acks=të gjitha, min.insync.replicas=2) në rast të dështimit të njëkohshëm.

Në përgjithësi, Kafka shfaq performancë më të mirë të softuerit dhe është projektuar nga themeli për grupe. Numri i ndjekësve mund të rritet në 11 nëse është e nevojshme për besueshmëri. Faktori i replikimit 5 dhe numri minimal i kopjeve në sinkronizim min.insync.replicas=3 do ta bëjë humbjen e mesazhit një ngjarje shumë të rrallë. Nëse infrastruktura juaj mund të mbështesë këtë raport të përsëritjes dhe nivelin e tepricës, atëherë mund të zgjidhni këtë opsion.

Grumbullimi i RabbitMQ është i mirë për radhë të vogla. Por edhe radhët e vogla mund të rriten shpejt kur ka trafik të rënduar. Sapo radhët të bëhen të mëdha, do t'ju duhet të bëni zgjedhje të vështira midis disponueshmërisë dhe besueshmërisë. Grumbullimi i RabbitMQ është më i përshtatshmi për situata jo tipike ku përfitimet e fleksibilitetit të RabbitMQ tejkalojnë çdo disavantazh të grupimit të tij.

Një kundërhelm ndaj cenueshmërisë së RabbitMQ ndaj radhëve të mëdha është ndarja e tyre në shumë radhë më të vogla. Nëse nuk keni nevojë për porosi të plotë të të gjithë radhës, por vetëm mesazhet përkatëse (për shembull, mesazhe nga një klient specifik), ose nuk porosisni asgjë, atëherë ky opsion është i pranueshëm: shikoni projektin tim Ribalancues për të ndarë radhën (projekti është ende në një fazë të hershme).

Së fundi, mos harroni për një numër gabimesh në mekanizmat e grumbullimit dhe riprodhimit të RabbitMQ dhe Kafka. Me kalimin e kohës, sistemet janë bërë më të pjekur dhe më të qëndrueshëm, por asnjë mesazh nuk do të jetë kurrë 100% i sigurt nga humbja! Përveç kësaj, aksidente në shkallë të gjerë ndodhin në qendrat e të dhënave!

Nëse kam humbur diçka, kam bërë një gabim ose nuk jeni dakord me ndonjë nga pikat, mos ngurroni të shkruani një koment ose të më kontaktoni.

Më pyesin shpesh: “Çfarë të zgjedh, Kafka apo RabbitMQ?”, “Cila platformë është më e mirë?”. E vërteta është se varet vërtet nga situata juaj, përvoja aktuale, etj. Unë hezitoj të jap mendimin tim, sepse do të ishte shumë thjeshtim i tepërt të rekomandoja një platformë për të gjitha rastet e përdorimit dhe kufizimet e mundshme. E shkrova këtë seri artikujsh në mënyrë që ju të krijoni mendimin tuaj.

Dua të them se të dy sistemet janë lider në këtë fushë. Mund të jem pak i njëanshëm, sepse nga përvoja ime me projekte prirem të vlerësoj gjëra të tilla si porositja e garantuar e mesazheve dhe besueshmëria.

Unë shoh teknologji të tjera të cilave u mungon kjo besueshmëri dhe porositje e garantuar, më pas shikoj RabbitMQ dhe Kafka dhe kuptoj vlerën e jashtëzakonshme të të dy këtyre sistemeve.

Burimi: www.habr.com

RabbitMQ vs Kafka: Toleranca e gabimeve dhe disponueshmëria e lartë