В leschten Artikel mir gekuckt RabbitMQ Clustering fir Feeler Toleranz an héich Disponibilitéit. Loosst eis elo déif an den Apache Kafka gräifen.

Hei ass d'Eenheet vun der Replikatioun d'Partition. All Thema huet een oder méi Rubriken. All Sektioun huet e Leader mat oder ouni Follower. Wann Dir en Thema erstellt, spezifizéiert Dir d'Zuel vun de Partitionen an de Replikatiounskoeffizient. Den übleche Wäert ass 3, dat heescht dräi Repliken: ee Leader an zwee Follower.

Reis. 1. Véier Rubriken sinn ënnert dräi Courtiere verdeelt

All Lies- a Schreiffuerderunge ginn un de Leader. Follower schécken periodesch Ufroe un de Leader fir déi lescht Messagen ze kréien. Konsumenten wenden sech ni un Unhänger; Déi lescht existéieren nëmme fir Redundanz a Feelertoleranz.

Partition Echec

Wann e Broker feelt, falen d'Leader vu verschiddene Sektiounen dacks. A jidderee vun hinnen gëtt e Follower vun engem aneren Node de Leader. Tatsächlech ass dat net ëmmer de Fall, well de Synchroniséierungsfaktor och beaflosst: ob et synchroniséiert Follower gëtt, a wann net, ob et erlaabt ass op eng onsynchroniséiert Replik ze wiesselen. Awer loosst eis d'Saache fir de Moment net komplizéieren.

Broker 3 verléisst d'Netz, an en neie Leader gëtt fir Sektioun 2 beim Broker 2 gewielt.

Reis. 2. Broker 3 stierft a säi Follower um Broker 2 gëtt als neie Leader vun der Partition 2 gewielt

Da verléisst de Broker 1 an d'Sektioun 1 verléiert och säi Leader, deem seng Roll un de Broker 2 geet.

Reis. 3. Et gëtt nach ee Broker. All Leader sinn op engem Broker mat Null Redundanz

Wann de Broker 1 zréck online kënnt, füügt et véier Unhänger, déi e puer Redundanz fir all Partition ubidden. Awer all Leader sinn nach ëmmer um Broker 2 bliwwen.

Reis. 4. Leader bleiwen um Broker 2

Wann de Broker 3 kënnt, si mir zréck op dräi Repliken pro Partition. Awer all Leader sinn nach ëmmer um Broker 2.

Reis. 5. Onbalancéiert Placement vun Cheffen no der Restauratioun vun Courtiere 1 an 3

Kafka huet en Tool fir bessere Leader Rebalancing wéi RabbitMQ. Do musst Dir en Drëtt Partei Plugin oder Skript benotzen, deen d'Politik fir d'Migratioun vum Master Node geännert huet andeems d'Redundanz während der Migratioun reduzéiert gëtt. Zousätzlech, fir grouss Schlaangen hu mir d'Onverfügbarkeet während der Synchroniséierung misse akzeptéieren.

Kafka huet d'Konzept vun "preferred replicas" fir d'Leader Roll. Wann d'Thema Partitionen erstallt ginn, probéiert de Kafka d'Leader gläichméisseg iwwer d'Noden ze verdeelen a markéiert déi éischt Leader als bevorzugt. Mat der Zäit, wéinst Server Neistart, Feeler a Konnektivitéitsdebroch, kënnen d'Leader op aner Wirbelen ophalen, wéi am extreme Fall hei uewen beschriwwen.

Fir dëst ze fixéieren, bitt de Kafka zwou Méiglechkeeten:

Optioun auto.leader.rebalance.enable=true erlaabt de Controller Node automatesch d'Cheffen zréck op déi gewënschte Repliken z'änneren an doduerch eenheetlech Verdeelung ze restauréieren.
Den Administrateur kann de Skript lafen kafka-preferred-replica-election.sh fir manuell Ëmsetzung.

Reis. 6. Repliken no rebalancing

Dëst war eng vereinfacht Versioun vum Echec, awer d'Realitéit ass méi komplex, obwuel et hei näischt ze komplizéiert ass. Et geet alles erof op synchroniséiert Repliken (In-Sync Replicas, ISR).

Synchroniséierter Replicas (ISR)

En ISR ass e Set vu Repliken vun enger Partition déi als "synchroniséiert" (synchroniséiert) ugesi gëtt. Et gëtt e Leader, awer et kann net Unhänger sinn. E Follower gëtt als synchroniséiert ugesinn wann en exakt Kopien vun all de Leader seng Messagen gemaach huet ier den Intervall ofleeft replica.lag.time.max.ms.

E Follower gëtt aus dem ISR Set geläscht wann et:

huet keng Ufro gemaach fir den Intervall ze wielen replica.lag.time.max.ms (vermutlech dout)
konnt net während dem Intervall aktualiséieren replica.lag.time.max.ms (gëtt als lues ugesinn)

Follower maachen Probe Ufroen am Intervall replica.fetch.wait.max.ms, déi als Standard op 500ms.

Fir den Zweck vum ISR kloer z'erklären, musse mir d'Bestätegunge vum Produzent an e puer Ausfallszenarie kucken. D'Produzente kënnen wielen wann de Broker d'Bestätegung schéckt:

acks = 0, Bestätegung gëtt net geschéckt
acks=1, d'Bestätegung gëtt geschéckt nodeems de Leader e Message op säi lokale Logbuch geschriwwen huet
acks = all, d'Bestätegung gëtt geschéckt nodeems all Repliken am ISR de Message un d'lokal Logbicher geschriwwen hunn

An der Kafka Terminologie, wann den ISR e Message gespäichert huet, ass et "engagéiert". Acks=all ass déi sécherst Optioun, awer füügt och zousätzlech Verspéidung. Loosst eis zwee Beispiller vu Feeler kucken a wéi déi verschidde 'acks' Optiounen mam ISR Konzept interagéieren.

Acks=1 an ISR

An dësem Beispill wäerte mir gesinn datt wann de Leader net op all Message vun all Unhänger waart fir gespäichert ze ginn, ass Datenverloscht méiglech wann de Leader feelt. Navigéieren op en net synchroniséierte Follower kann duerch Astellung aktivéiert oder deaktivéiert ginn onrein.leader.wahlen.aktivéieren.

An dësem Beispill huet den Hiersteller de Wäert acks = 1. D'Sektioun ass iwwer all dräi Broker verdeelt. Broker 3 ass hannendrun, et synchroniséiert mam Leader virun aacht Sekonnen an ass elo 7456 Messagen hannendrun. De Broker 1 war nëmmen eng Sekonn hannert. Eise Produzent schéckt e Message a kritt séier en Ack zréck, ouni den Overhead vu luesen oder doudege Follower, op déi de Leader net waart.

Reis. 7. ISR mat dräi replicas

Broker 2 feelt an de Produzent kritt e Verbindungsfehler. Nodeems d'Leedung op de Broker 1 passéiert, verléieren mir 123 Messagen. De Follower um Broker 1 war Deel vum ISR, awer war net voll mat dem Leader synchroniséiert wann et gefall ass.

Reis. 8. Messagen sinn verluer wann et Crash

An der Konfiguratioun bootstrap.servers Den Hiersteller huet e puer Broker opgelëscht a kann en anere Broker froen deen den neie Sektiounsleader ass. Et stellt dann eng Verbindung mam Broker 1 a schéckt weider Messagen.

Reis. 9. D'Schécke vu Messagen geet no enger kuerzer Paus weider

Broker 3 ass nach méi hannendrun. Et mécht Ufroe fir ze sichen, awer kann net synchroniséieren. Dëst kann wéinst luesen Reseau Verbindung tëscht Courtiere ginn, Stockage Problem, etc.. Et gëtt aus der ISR geläscht. Elo besteet den ISR aus enger Replica - de Leader! Den Hiersteller schéckt weider Messagen a kritt Bestätegungen.

Reis. 10. Follower op Broker 3 gëtt aus dem ISR geläscht

Broker 1 geet erof an d'Leedungsroll geet un de Broker 3 mam Verloscht vun 15286 Messagen! Den Hiersteller kritt eng Verbindungsfehlermeldung. Den Iwwergank zu engem Leader ausserhalb vum ISR war nëmme méiglech wéinst dem Kader unclean.leader.election.enable=true. Wann et installéiert ass an falsch, da géif den Iwwergank net geschéien an all Lies- a Schreiffuerderunge géife refuséiert ginn. An dësem Fall waarden mir op de Broker 1 fir mat sengen intakten Donnéeën an der Replika zréckzekommen, déi erëm d'Leedung iwwerhuelen.

Reis. 11. Broker 1 Falen. Wann e Feeler geschitt, ginn eng grouss Zuel vu Messagen verluer

De Produzent stellt eng Verbindung mam leschte Broker a gesäit datt hien elo de Leader vun der Sektioun ass. Hie fänkt un Messagen un de Broker 3 ze schécken.

Reis. 12. No enger kuerzer Paus ginn d'Messagen nees an d'Sektioun 0 geschéckt

Mir hunn gesinn datt, ausser kuerzen Ënnerbriechungen fir nei Verbindungen opzebauen an no engem neie Leader ze sichen, den Hiersteller stänneg Messagen schéckt. Dës Konfiguratioun garantéiert Disponibilitéit op Käschte vun der Konsistenz (Datesécherheet). De Kafka huet Dausende vu Messagen verluer, awer huet weider nei Schreiwe akzeptéiert.

Acks=all an ISR

Loosst eis dëst Szenario nach eng Kéier widderhuelen, awer mat acks = all. Broker 3 huet eng Moyenne latency vu véier Sekonnen. Den Hiersteller schéckt e Message mat acks = all, a kritt elo keng séier Äntwert. De Leader waart op de Message fir vun all Repliken am ISR gerett ze ginn.

Reis. 13. ISR mat dräi replicas. Eent ass lues, wat zu Verspéidungen op der Opnam resultéiert

No véier Sekonnen zousätzlech Verspéidung schéckt de Broker 2 en Ack. All Repliken sinn elo komplett aktualiséiert.

Reis. 14. All replicas späicheren Messagen a schécken ack

Broker 3 fällt elo méi hannendrun a gëtt aus der ISR geläscht. D'Latency gëtt wesentlech reduzéiert well et keng lues Repliken am ISR sinn. Broker 2 waart elo nëmmen op Broker 1, an hien huet eng Moyenne Lag vun 500 ms.

Reis. 15. D'Replique op Broker 3 gëtt aus dem ISR geläscht

Da fällt de Broker 2 an d'Leedung geet un de Broker 1 ouni Verloscht vu Messagen.

Reis. 16. Broker 2 Falen

Den Hiersteller fënnt en neie Leader a fänkt un him Messagen ze schécken. D'Latenz gëtt weider reduzéiert well den ISR elo aus enger Replik besteet! Dofir d'Optioun acks = all bäidréit keng Redundanz.

Reis. 17. Replica op broker 1 hëlt d'Féierung ouni Messagen ze verléieren

Da klappt de Broker 1 an de Lead geet un de Broker 3 mat engem Verloscht vun 14238 Messagen!

Reis. 18. Broker 1 stierft a Leadership Transitioun mat onreine Kader Resultater an extensiv Daten Verloscht

Mir konnten d'Optioun net installéieren onrein.leader.wahlen.aktivéieren an Bedeitung richteg. Par défaut ass et gläich falsch. Astellungen acks = all с unclean.leader.election.enable=true bitt Accessibilitéit mat e puer zousätzlech Datesécherheet. Awer wéi Dir gesitt, kënne mir nach ëmmer Messagen verléieren.

Awer wat wa mir d'Datesécherheet erhéijen wëllen? Dir kënnt setzen unclean.leader.election.enable = falsch, awer dëst wäert eis net onbedéngt virun Datenverloscht schützen. Wann de Leader schwéier gefall ass an d'Donnéeën mat sech geholl huet, da sinn d'Messagen nach ëmmer verluer, plus d'Disponibilitéit ass verluer bis den Administrateur d'Situatioun restauréiert.

Et ass besser fir sécherzestellen datt all Messagen iwwerflësseg sinn, an d'Opnahm soss ofzeginn. Dann, op d'mannst aus der Siicht vum Broker, ass Datenverloscht nëmme méiglech am Fall vun zwee oder méi simultan Ausfäll.

Acks=all, min.insync.replicas an ISR

Mat Thema Configuratioun min.insync.repliken Mir erhéijen den Niveau vun der Datesécherheet. Loosst eis de leschten Deel vum viregte Szenario nach eng Kéier duerchgoën, awer dës Kéier mat min.insync.replicas=2.

Also Broker 2 huet e Replica Leader an de Follower um Broker 3 gëtt aus dem ISR geläscht.

Reis. 19. ISR aus zwee replicas

Broker 2 fällt a Leedung geet un de Broker 1 ouni Verloscht vu Messagen. Awer elo besteet den ISR aus nëmmen enger Replik. Dëst entsprécht net der Mindestzuel fir Rekorder ze kréien, an dofir reagéiert de Broker op de Schreifversuch mat engem Feeler NotEnoughReplicas.

Reis. 20. D'Zuel vun ISRs ass eent manner wéi an min.insync.replicas uginn

Dës Konfiguratioun offréiert Disponibilitéit fir Konsistenz. Ier mir e Message unerkennen, suerge mir datt et op d'mannst zwee Repliken geschriwwe gëtt. Dëst gëtt dem Hiersteller vill méi Vertrauen. Hei ass Messageverloscht nëmme méiglech wann zwee Repliken gläichzäiteg an engem kuerzen Intervall falen, bis de Message un en zousätzleche Follower replizéiert gëtt, wat onwahrscheinlech ass. Awer wann Dir super paranoid sidd, kënnt Dir de Replikatiounsfaktor op 5 setzen, an min.insync.repliken vun 3. Hei mussen dräi Courtiere falen gläichzäiteg de Rekord ze verléieren! Natierlech bezuelt Dir fir dës Zouverlässegkeet an zousätzlech latency.

Wann Accessibilitéit fir Datesécherheet néideg ass

Wéi an Fall mat RabbitMQ, heiansdo ass Accessibilitéit néideg fir Datesécherheet. Hei ass wat Dir musst iwwerdenken:

Kann de Verlag einfach e Feeler zréckginn an den Upstream Service oder de Benotzer méi spéit nach eng Kéier probéieren?
Kann de Verlag de Message lokal oder an enger Datebank späicheren fir spéider nach eng Kéier ze probéieren?

Wann d'Äntwert nee ass, da verbessert d'Disponibilitéit d'Datesécherheet ze optimiséieren. Dir verléiert manner Daten wann Dir Disponibilitéit wielt anstatt net opzehuelen. Et geet also dorëms e Gläichgewiicht ze fannen, an d'Entscheedung hänkt vun der spezifescher Situatioun of.

D'Bedeitung vun ISR

D'ISR Suite erlaabt Iech den optimale Gläichgewiicht tëscht Datesécherheet an Latenz ze wielen. Zum Beispill, suergen d'Disponibilitéit am Fall vun Echec vun der Majoritéit vun Replicaen, miniméiert den Impakt vun doudege oder luesen Repliken am Sënn vun latency.

Mir wielen d'Bedeitung selwer replica.lag.time.max.ms no Äre Besoinen. Weesentlechen heescht dëse Parameter wéi vill Retard mir bereet sinn ze akzeptéieren wann acks = all. De Standardwäert ass zéng Sekonnen. Wann dëst ze laang fir Iech ass, kënnt Dir et reduzéieren. Da wäert d'Frequenz vun den Ännerungen am ISR eropgoen, well d'Unhänger geläscht a méi dacks bäigefüügt ginn.

RabbitMQ ass einfach eng Rei vu Spigelen déi musse replizéiert ginn. Lues Spigelen aféieren zousätzlech Latenz, an dout Spigel kënnen waarden bis d'Päckchen, déi d'Disponibilitéit vun all Node (Nett Tick) iwwerpréift, fir ze reagéieren. ISR ass en interessante Wee fir dës latency Themen ze vermeiden. Awer mir riskéieren Redundanz ze verléieren well d'ISR nëmmen op de Leader ka schrumpfen. Fir dëse Risiko ze vermeiden, benotzt d'Astellung min.insync.repliken.

Client Verbindung Garantie

An Astellungen bootstrap.servers Produzent a Konsument kënne verschidde Broker spezifizéieren fir Clienten ze verbannen. D'Iddi ass datt wann een Node erof geet, et e puer Ersatzstécker bleiwen, mat deenen de Client eng Verbindung kann opmaachen. Dëst sinn net onbedéngt Sektiounsleit, awer einfach e Sprangbriet fir initial Luede. De Client kann hinnen froen, wéi engem Node de Lies- / Schreifpartitionsleader hëlt.

Am RabbitMQ kënnen d'Clientë mat all Node konnektéieren, an intern Routing schéckt d'Ufro un wou se muss goen. Dëst bedeit datt Dir e Lastbalancer virun RabbitMQ installéiere kënnt. Kafka erfuerdert Cliente fir mam Node ze verbannen, deen de korrespondéierte Partition Leader host. An esou enger Situatioun kënnt Dir e Lastbalancer net installéieren. Lëscht bootstrap.servers Et ass kritesch datt Clienten Zougang kënnen an déi richteg Noden no engem Feeler fannen.

Kafka Konsens Architektur

Bis elo hu mir net berücksichtegt wéi de Cluster iwwer de Fall vum Broker léiert a wéi en neie Leader gewielt gëtt. Fir ze verstoen wéi Kafka mat Netzwierkpartitionen funktionnéiert, musst Dir als éischt d'Konsensarchitektur verstoen.

All Kafka-Cluster gëtt zesumme mat engem Zookeeper-Cluster ofgesat, deen e verdeelt Konsensservice ass, deen de System erlaabt Konsens iwwer e bestëmmte Staat z'erreechen, prioritär Konsistenz iwwer Disponibilitéit. D'Zoustëmmung vun enger Majoritéit vun Zookeeper Knäppercher ass erfuerderlech fir Lies- a Schreifoperatiounen z'accordéieren.

Zookeeper späichert den Zoustand vum Cluster:

Lëscht vun Themen, Sektiounen, Konfiguratioun, aktuell Leader Repliken, Preferenze Repliken.
Cluster Memberen. All Broker pingt den Zookeeper Cluster. Wann et net e Ping bannent enger spezifizéierter Zäit kritt, registréiert Zookeeper de Broker als net verfügbar.
Wielt d'Haapt- an Ersatzknäppchen fir de Controller.

De Controller Node ass ee vun de Kafka Broker déi verantwortlech ass fir d'Replika Leader ze wielen. Zookeeper schéckt Notifikatiounen un de Controller iwwer Cluster Memberschaft an Thema Ännerungen, an de Controller muss op dës Ännerungen handelen.

Zum Beispill, loosst eis en neit Thema huelen mat zéng Partitionen an engem Replikatiounsfaktor vun 3. De Controller muss e Leader fir all Partition wielen, a probéiert d'Leader optimal tëscht de Brokeren ze verdeelen.

Fir all Sektioun Controller:

aktualiséiert Informatioun am Zookeeper iwwer ISR a Leader;
Schéckt e LeaderAndISRCommand un all Broker, deen eng Replica vun dëser Partition hält, informéiert de Broker iwwer den ISR an de Leader.

Wann e Broker mat engem Leader fällt, schéckt Zookeeper eng Notifikatioun un de Controller, an et wielt en neie Leader. Erëm, de Controller aktualiséiert Zookeeper fir d'éischt a schéckt dann e Kommando un all Broker, deen se iwwer d'Leedung änneren.

All Leader ass verantwortlech fir ISRs ze rekrutéieren. Astellungen replica.lag.time.max.ms bestëmmt, wien do erakënnt. Wann den ISR ännert, iwwerdréit de Leader nei Informatioun un Zookeeper.

Zookeeper gëtt ëmmer iwwer all Ännerungen informéiert, sou datt am Fall vun engem Echec, d'Gestioun glat op en neie Leader iwwerdréit.

Reis. 21. Kafka Konsens

Replikatiounsprotokoll

D'Detailer vun der Replikatioun ze verstoen hëlleft Iech potenziell Datenverloscht Szenarie besser ze verstoen.

Sampling Ufroen, Log End Offset (LEO) an Highwater Mark (HW)

Mir hu geduecht datt Unhänger periodesch Ufroen un de Leader schécken. De Standardintervall ass 500ms. Dëst ënnerscheet sech vum RabbitMQ an deem an der RabbitMQ Replikatioun net vum Schlaangspigel initiéiert gëtt, mee vum Master. De Meeschter dréckt Ännerungen un de Spigelen.

De Leader an all Unhänger späicheren de Log End Offset (LEO) an den Highwater (HW) Label. D'LEO Mark späichert den Offset vum leschte Message an der lokaler Replika, an den HW hält den Offset vum leschte Verpflichtung. Denkt drun datt fir de Verpflichtungsstatus de Message muss iwwer all ISR Repliken bestoe bleiwen. Dëst bedeit datt de LEO normalerweis liicht virum HW ass.

Wann de Leader e Message kritt, späichert se se lokal. De Follower mécht eng Ufro fir ze sichen andeems hien säi LEO iwwerdroen. De Leader schéckt dann eng Partie vu Messagen aus dësem LEO an iwwerdréit och den aktuellen HW. Wann de Leader d'Informatioun kritt datt all Repliken d'Botschaft um gegebene Offset gespäichert hunn, bewegt et d'HW Mark. Nëmmen de Leader kann den HW réckelen, an dofir kennen all Unhänger den aktuelle Wäert an den Äntwerten op hir Ufro. Dëst bedeit datt Unhänger hannert dem Leader a béid Message an HW Wëssen kënne bleiwen. Konsumenten kréien Messagen nëmme bis den aktuellen HW.

Notéiert datt "persistéiert" heescht an d'Erënnerung geschriwwe ginn, net op d'Disk. Fir d'Performance synchroniséiert de Kafka op Scheif mat engem spezifeschen Intervall. RabbitMQ huet och esou en Intervall, awer et schéckt eng Unerkennung un de Verlag nëmmen nodeems de Meeschter an all Spigel de Message op Scheif geschriwwen hunn. D'Kafka-Entwéckler, aus Performancegrënn, hunn decidéiert en Ack ze schécken soubal de Message an d'Erënnerung geschriwwe gëtt. Kafka wetten datt Redundanz de Risiko kompenséiert fir unerkannte Messagen kuerz an der Erënnerung ze späicheren.

Leader Echec

Wann e Leader fällt, informéiert Zookeeper de Controller, an et wielt eng nei Leader Replica. Den neie Leader setzt eng nei HW Mark no sengem LEO. Follower kréien dann Informatioun iwwer den neie Leader. Ofhängeg vun der Versioun vu Kafka, wäert de Follower ee vun zwee Szenarie wielen:

Et wäert de lokale Logbuch op e bekannten HW ofschneiden an eng Ufro un den neie Leader fir Messagen no dëser Mark schécken.
Schéckt eng Ufro un de Leader fir den HW erauszefannen an der Zäit wou hien als Leader gewielt gouf, an dann de Logbuch op dës Offset ofschneiden. Et fänkt dann un periodesch Fetch-Ufroen unzefänken mat dëser Offset.

E Follower muss vläicht de Log aus de folgende Grënn ofschneiden:

Wann e Leader feelt, gewënnt den éischte Follower am ISR Set, dee mam Zookeeper registréiert ass, d'Wahlen a gëtt de Leader. All Follower op ISR, obwuel als "synchroniséiert" ugesi gëtt, hu vläicht keng Kopie vun all Message vum fréiere Leader kritt. Et ass ganz méiglech datt de Feature Follower net déi aktuellst Kopie huet. Kafka garantéiert datt et keng Divergenz tëscht Repliken gëtt. Also, fir Ënnerscheeder ze vermeiden, muss all Follower säi Log op den HW Wäert vum neie Leader am Moment vu senge Wahlen ofschneiden. Dëst ass en anere Grond firwat Astellung acks = all sou wichteg fir Konsistenz.
Messagen ginn periodesch op Disk geschriwwe ginn. Wann all Cluster Node gläichzäiteg feelen, da ginn Repliken mat verschiddene Offsets op den Disken gespäichert. Et ass méiglech datt wann d'Broker erëm online kommen, den neie Leader, dee gewielt gëtt, hannert sengen Unhänger wäert sinn, well hie virun deenen aneren op Disk gespäichert gouf.

Reunioun mam Cluster

Wann se erëm an de Cluster bäitrieden, maachen d'Repliken datselwecht wéi wann e Leader feelt: si kontrolléieren d'Replika vum Leader an truncéieren hire Log op säin HW (zu der Zäit vun de Wahlen). Am Verglach behandelt RabbitMQ gläich vereenegt Noden als komplett nei. A béide Fäll verschwënnt de Broker all existent Staat. Wann automatesch Synchroniséierung benotzt gëtt, da muss de Meeschter absolut all aktuellen Inhalt op den neie Spigel replizéieren an enger Method "Loosst d'ganz Welt waarden". De Master akzeptéiert keng Lies- oder Schreifoperatioune während dëser Operatioun. Dës Approche schaaft Problemer a grousse Schlaangen.

Kafka ass e verdeelt Logbuch an allgemeng späichert et méi Messagen wéi eng RabbitMQ Schlaang, wou Daten aus der Schlaang geläscht ginn nodeems se gelies ginn. Aktiv Schlaangen sollen relativ kleng bleiwen. Awer Kafka ass e Logbuch mat senger eegener Retentiounspolitik, déi eng Period vun Deeg oder Wochen astellen kann. D'Schlaangblockéierung a voll Synchroniséierung Approche ass absolut inakzeptabel fir e verdeelt Logbuch. Amplaz, verkierzen de Kafka-Unhänger einfach hire Logbuch op den HW vum Leader (zu der Zäit vu senge Wahlen) wann hir Kopie virum Leader ass. Am méi wahrscheinleche Fall, wann de Follower hannendrun ass, fänkt en einfach unzefänken Ufroen unzefänken mat sengem aktuellen LEO.

Nei oder rejoined Follower fänken ausserhalb vum ISR un a bedeelegen net un Verpflichtungen. Si schaffen einfach niewent der Grupp, kréien Messagen sou séier wéi se kënnen, bis se mam Leader ophalen an an den ISR kommen. Et gëtt kee Sperrung a kee Besoin all Är Donnéeën ewech ze geheien.

Verloscht vun Konnektivitéit

Kafka huet méi Komponenten wéi RabbitMQ, sou datt et e méi komplexe Set vu Behuelen huet wann de Stärekoup ofgeschalt gëtt. Awer Kafka war ursprénglech fir Cluster entworf, sou datt d'Léisungen ganz gutt geduecht sinn.

Drënner sinn e puer Konnektivitéitsfehler Szenarie:

Szenario 1: De Follower gesäit de Leader net, awer gesäit ëmmer nach den Zookeeper.
Szenario 2: De Leader gesäit keng Follower, awer gesäit nach ëmmer Zookeeper.
Szenario 3: De Follower gesäit de Leader, awer gesäit den Zookeeper net.
Szenario 4: De Leader gesäit d'Unhänger, awer gesäit den Zookeeper net.
Szenario 5: De Follower ass komplett getrennt vu béiden anere Kafka Noden an Zookeeper.
Szenario 6: De Leader ass komplett getrennt vu béiden anere Kafka Noden an Zookeeper.
Szenario 7: De Kafka Controller Node kann net en anere Kafka Node gesinn.
Szenario 8: Kafka Controller gesäit Zookeeper net.

All Szenario huet säin eegent Verhalen.

Szenario 1: Follower gesäit de Leader net, awer gesäit ëmmer nach Zookeeper

Reis. 22. Szenario 1: ISR vun dräi replicas

De Konnektivitéitsfehler trennt de Broker 3 vum Broker 1 an 2, awer net vum Zookeeper. Broker 3 kann net méi Empfangsufroe schécken. No der Zäit ass vergaangen replica.lag.time.max.ms et gëtt aus dem ISR geläscht a bedeelegt net un de Message engagéiert. Eemol d'Konnektivitéit restauréiert ass, wäert et d'Ufroen erëmfannen an den ISR bäitrieden wann et mam Leader erakënnt. Zookeeper wäert weider Pings kréien an huelen un datt de Broker lieweg a gutt ass.

Reis. 23. Szenario 1: De Broker gëtt aus dem ISR geläscht, wann keng Fetch-Ufro vun him am Replica.lag.time.max.ms Intervall kritt gëtt

Et gëtt keng Split-Gehir oder Node Suspension wéi am RabbitMQ. Amplaz gëtt Redundanz reduzéiert.

Szenario 2: Leader gesäit keng Follower, awer gesäit nach ëmmer Zookeeper

Reis. 24. Szenario 2. Leader an zwee Matleefer

En Decompte an der Netzkonnektivitéit trennt de Leader vun den Unhänger, awer de Broker kann nach ëmmer Zookeeper gesinn. Wéi am éischte Szenario schrumpft d'ISR, awer dës Kéier nëmmen un de Leader well all Follower ophalen d'Fetch-Ufroen ze schécken. Och erëm gëtt et keng logesch Divisioun. Amplaz gëtt et e Verloscht vu Redundanz fir nei Messagen bis d'Konnektivitéit restauréiert ass. Zookeeper kritt weider Pings a mengt datt de Broker lieweg a gutt ass.

Reis. 25. Szenario 2. ISR huet schrumpft nëmmen un de Leader

Szenario 3. Follower gesäit de Leader, awer gesäit den Zookeeper net

Den Follower gëtt vum Zookeeper getrennt, awer net vum Broker mam Leader. Als Resultat geet de Follower weider fir Ufroen ze sichen a Member vum ISR ze sinn. Zookeeper kritt net méi Pings a registréiert e Broker Crash, awer well et nëmmen e Follower ass, ginn et keng Konsequenzen no der Genesung.

Reis. 26. Szenario 3: De Follower schéckt weider Erhuelungsufroen un de Leader

Szenario 4. Leader gesäit Matleefer, mee gesäit Zookeeper net

Reis. 27. Szenario 4. Leader an zwee Matleefer

De Leader gëtt vum Zookeeper getrennt, awer net vun de Broker mat Unhänger.

Reis. 28. Szenario 4: Leader vun Zookeeper isoléiert

No enger Zäit registréiert Zookeeper e Brokerfehler an informéiert de Controller doriwwer. Hie wäert en neie Leader ënner sengen Unhänger wielen. Wéi och ëmmer, den urspréngleche Leader wäert weiderhin denken datt et de Leader ass a wäert weider Entréen akzeptéieren aus acks=1. Follower schécken him net méi Ufroe fir ze sichen, sou datt hien se als dout betruecht a probéiert den ISR fir sech selwer ze schrumpfen. Mee well et keng Verbindung mat Zookeeper huet, kann et dat net maachen, a wäert deemools refuséieren all weider Entréen ze akzeptéieren.

Messagen acks = all wäert keng Unerkennung kréien, well den ISR fir d'éischt all Repliken ageschalt, a Messagen erreechen se net. Wann den urspréngleche Leader probéiert se aus dem ISR ze läschen, wäert et net fäeg sinn dat ze maachen a wäert ophalen all Messagen ze akzeptéieren.

D'Clientë bemierken geschwënn d'Verännerung vum Leader a fänken un records op den neie Server ze schécken. Wann d'Netzwierk restauréiert ass, gesäit den urspréngleche Leader datt et net méi e Leader ass a truncéiert säi Logbuch op den HW-Wäert, deen den neie Leader am Moment vum Echec hat fir Log-Divergenz ze vermeiden. Et fänkt dann un d'Fetch-Ufro un den neie Leader ze schécken. All Opzeechnunge vum urspréngleche Leader, déi net op den neie Leader replizéiert ginn, gi verluer. Dat ass, Messagen déi net vum urspréngleche Leader an deene puer Sekonnen unerkannt goufen, wou zwee Leader geschafft hunn, wäerte verluer goen.

Reis. 29. Szenario 4. De Leader um Broker 1 gëtt e Follower nodeems de Reseau restauréiert ass

Szenario 5: De Follower ass komplett getrennt vu béiden anere Kafka Noden an Zookeeper

De Follower ass komplett isoléiert vu béiden anere Kafka Noden an Zookeeper. Hien hëlt sech einfach aus dem ISR bis de Reseau restauréiert ass, an dann mat deenen aneren ophalen.

Reis. 30. Szenario 5: Isoléiert Follower gëtt aus ISR geläscht

Szenario 6: De Leader ass komplett getrennt vu béiden anere Kafka Noden an Zookeeper

Reis. 31. Szenario 6. Leader an zwee Matleefer

De Leader ass komplett isoléiert vu senge Follower, dem Controller an Zookeeper. Fir eng kuerz Period wäert et weider Entréen aus akzeptéieren acks=1.

Reis. 32. Szenario 6: Isoléieren de Leader vun anere Kafka an Zookeeper Node

Hutt keng Ufroe nom Verfall kritt replica.lag.time.max.ms, et wäert probéieren den ISR fir sech selwer ze schrumpfen, awer wäert net fäeg sinn dat ze maachen, well et keng Kommunikatioun mam Zookeeper ass, da wäert et ophalen Schreiwen ze akzeptéieren.

Mëttlerweil wäert Zookeeper den isoléierte Broker als dout markéieren an de Controller wäert en neie Leader wielen.

Reis. 33. Szenario 6. Zwee Cheffen

Den urspréngleche Leader kann Entréen fir e puer Sekonnen akzeptéieren, awer hält dann op all Messagen ze akzeptéieren. D'Clientë ginn all 60 Sekonnen mat de leschten Metadaten aktualiséiert. Si ginn iwwer de Leaderwiessel informéiert a fänken un d'Entréen un den neie Leader ze schécken.

Reis. 34. Szenario 6: Hiersteller schalt op en neie Leader

All bestätegt Entréen, déi vum ursprénglechen Leader gemaach goufen zënter dem Verloscht vun der Konnektivitéit, wäerte verluer goen. Wann d'Netzwierk restauréiert ass, entdeckt den urspréngleche Leader duerch Zookeeper datt et net méi de Leader ass. Da wäert et säi Logbuch un den HW vum neie Leader an der Zäit vun de Wahlen truncéieren a fänkt Ufroen als Follower ze schécken.

Reis. 35. Szenario 6: Den urspréngleche Leader gëtt e Follower nodeems d'Netzverbindung restauréiert ass

An dëser Situatioun kann logesch Trennung fir eng kuerz Zäit geschéien, awer nëmmen wann acks=1 и min.insync.repliken och 1. Logesch Trennung endet automatesch entweder no der Reseau restauréiert ass, wann der Original Leader realiséiert, datt hien net méi de Leader ass, oder wann all Clienten mierken, datt de Leader geännert huet a fänkt un déi nei Leader ze schreiwen - wat och ëmmer éischt geschitt. Op jidde Fall wäert e puer Messagen verluer ginn, awer nëmmen mat acks=1.

Et gëtt eng aner Variant vun dësem Szenario wou, just virum Netz gespléckt, d'Unhänger hannendrun gefall sinn an de Leader den ISR just fir sech selwer kompriméiert. Et gëtt dann isoléiert wéinst Verloscht vun Konnektivitéit. En neie Leader gëtt gewielt, awer den urspréngleche Leader akzeptéiert weider Entréen, souguer acks = all, well et keen aneren am ISR ausser hien ass. Dës Opzeechnunge ginn verluer wann d'Netzwierk restauréiert ass. Deen eenzege Wee fir dës Optioun ze vermeiden ass min.insync.replicas = 2.

Szenario 7: Kafka Controller Node Kann en anere Kafka Node net gesinn

Am Allgemengen, wann d'Verbindung mat engem Kafka Node verluer ass, kann de Controller keng Leader Change Informatioun doriwwer iwwerdroen. Am schlëmmste Fall wäert dëst zu enger kuerzfristeg logescher Trennung féieren, wéi am Szenario 6. Méi dacks wéi net, gëtt de Broker einfach net e Kandidat fir d'Leedung, wann dee leschte feelt.

Szenario 8: Kafka Controller gesäit Zookeeper net

Zookeeper kritt kee Ping vum gefallene Controller a wielt en neie Kafka Node als Controller. Den urspréngleche Controller ka weiderhin sech als solch presentéieren, awer et kritt keng Notifikatioune vum Zookeeper, sou datt et keng Aufgaben huet ze maachen. Wann d'Netzwierk restauréiert ass, wäert hien mierken datt hien net méi e Controller ass, awer e regelméisseg Kafka Node ginn ass.

Conclusiounen aus den Szenarien

Mir gesinn datt de Verloscht vun der Followerkonnektivitéit net zu Messageverloscht resultéiert, awer einfach temporär Redundanz reduzéiert bis d'Netzwierk restauréiert ass. Dëst kann natierlech zu Datenverloscht féieren, wann een oder méi Node verluer sinn.

Wann de Leader vum Zookeeper getrennt gëtt wéinst engem Verloscht vun der Konnektivitéit, kann dat dozou féieren datt Messagen aus acks=1. Mangel u Kommunikatioun mam Zookeeper verursaacht eng kuerz logesch Spaltung mat den zwee Leader. Dëse Problem gëtt vum Parameter geléist acks = all.

Parameter min.insync.repliken an zwee oder méi Repliken gëtt zousätzlech Assurance datt esou kuerzfristeg Szenarie net zu verluerene Messagen resultéieren wéi am Szenario 6.

Resumé vun verluer Messagen

Loosst eis all d'Weeër opzielen wéi Dir Daten am Kafka verléiere kënnt:

All Leader Echec wann Messagen bestätegt goufen benotzt acks=1
All onrein Transitioun vun Leedung, dat ass, zu engem Matleefer ausserhalb der ISR, souguer mat acks = all
Isoléieren de Leader vun Zookeeper wann Messagen bestätegt goufen benotzt acks=1
Komplett Isolatioun vum Leader, deen d'ISR-Grupp scho fir sech selwer erofgedréckt huet. All Messagen wäert verluer ginn, souguer acks = all. Dëst ass nëmmen richteg wann min.insync.replicas=1.
Simultan Feeler vun all Partition Node. Well Messagen aus Erënnerung unerkannt ginn, kënnen e puer nach net op Disk geschriwwe ginn. Nodeems Dir d'Server nei gestart hutt, kënnen e puer Messagen fehlen.

Onreine Leadership Transitioune kënne vermeit ginn andeems se se verbidden oder op d'mannst zwee Entloossunge garantéieren. Déi haltbarst Konfiguratioun ass eng Kombinatioun acks = all и min.insync.repliken iwwer 1.

Direkte Verglach vun der Zouverlässegkeet vu RabbitMQ a Kafka

Fir Zouverlässegkeet an héich Disponibilitéit ze garantéieren, implementéiere béid Plattformen e primären a sekundäre Replikatiounssystem. Wéi och ëmmer, RabbitMQ huet en Achilles Ferse. Wann d'Verbindung no engem Versoen, Noden hir Donnéeën ofginn an d'Synchroniséierung blockéiert. Dës duebel Whammy stellt d'Längegkeet vu grousse Schlaangen am RabbitMQ a Fro. Dir musst entweder reduzéiert Redundanz oder laang Spärzäiten akzeptéieren. Redundanz reduzéieren erhéicht de Risiko vu massiven Dateverloscht. Awer wann d'Schlaangen kleng sinn, da fir Redundanz, kuerz Perioden vun der Onverfügbarkeet (e puer Sekonnen) kënne mat widderholl Verbindungsversuch behandelt ginn.

Kafka huet dëse Problem net. Et verwerft Daten nëmmen aus dem Punkt vun der Divergenz tëscht dem Leader an dem Follower. All gedeelt Daten ginn gespäichert. Zousätzlech blockéiert d'Replikatioun de System net. De Leader akzeptéiert weider Posts wärend den neie Follower ophëlt, sou datt fir Devops, de Cluster bäitrieden oder erëm anzeschreiwen, gëtt eng trivial Aufgab. Natierlech ginn et nach ëmmer Themen wéi Netzwierkbandbreedung wärend der Replikatioun. Wann Dir méi Unhänger zur selwechter Zäit bäidréit, kënnt Dir eng Bandbreedlimit stoussen.

RabbitMQ ass superior wéi Kafka an Zouverlässegkeet wann verschidde Serveren an engem Cluster zur selwechter Zäit versoen. Wéi mir scho gesot hunn, schéckt RabbitMQ eng Bestätegung un de Verlag nëmmen nodeems d'Botschaft vum Master an all Spigelen op Disk geschriwwe gëtt. Awer dëst füügt zousätzlech latency aus zwee Grënn:

fsync all puer honnert Millisekonnen
De Versoen vum Spigel kann nëmme bemierkt ginn nodeems d'Liewensdauer vun de Paketen, déi d'Disponibilitéit vun all Node (Nettotick) iwwerpréift, ofgelaf ass. Wann de Spigel verlangsamt gëtt oder fällt, gëtt dat eng Verspéidung.

Dem Kafka seng Wette ass datt wann e Message iwwer verschidde Wirbelen gespäichert ass, et kann Messagen unerkennen soubal se d'Erënnerung treffen. Dofir besteet e Risiko fir Messagen vun iergendenger Aart ze verléieren (och acks = all, min.insync.replicas=2) am Fall vun simultan Echec.

Insgesamt weist de Kafka besser Software Performance an ass vun Ufank un fir Cluster entworf. D'Zuel vun den Unhänger kann op 11 erhéicht ginn wann néideg fir Zouverlässegkeet. Replikatiounsfaktor 5 a Minimum Zuel vu Repliken an der Synchroniséierung min.insync.replicas=3 wäert Message Verloscht engem ganz seelen Event maachen. Wann Är Infrastruktur dëst Replikatiounsverhältnis an Niveau vun der Redundanz ënnerstëtzen kann, da kënnt Dir dës Optioun wielen.

RabbitMQ Clustering ass gutt fir kleng Schlaangen. Awer och kleng Schlaangen kënne séier wuessen wann et schwéier Traffic ass. Wann d'Schlaangen grouss ginn, musst Dir haart Choixen tëscht Disponibilitéit an Zouverlässegkeet treffen. RabbitMQ Clustering ass am Beschten gëeegent fir net typesch Situatiounen, wou d'Virdeeler vun der RabbitMQ Flexibilitéit all Nodeeler vu senger Clustering iwwerwannen.

Een Antidot fir dem RabbitMQ seng Schwachstelle fir grouss Schlaangen ass se a vill méi kleng Schlaangen opzedeelen. Wann Dir keng komplett Uerdnung vun der ganzer Schlaang brauch, awer nëmmen déi relevant Messagen (zum Beispill Messagen vun engem spezifesche Client), oder guer näischt bestallt, dann ass dës Optioun akzeptabel: kuckt mäi Projet Rebalancer d'Schlaang opzedeelen (de Projet ass nach an engem fréie Stadium).

Schlussendlech, vergiesst net iwwer eng Zuel vu Bugs an de Cluster- a Replikatiounsmechanismen vu RabbitMQ a Kafka. Mat der Zäit si Systemer méi reift a stabil ginn, awer kee Message wäert jeemools 100% sécher vu Verloscht sinn! Donieft komme grouss-Skala Accidenter an den Datenzenteren!

Wann ech eppes verpasst hunn, e Feeler gemaach hunn, oder Dir sidd net mat engem vun de Punkten averstanen, fillt Iech gratis e Kommentar ze schreiwen oder mech ze kontaktéieren.

Ech ginn dacks gefrot: "Wat fir ze wielen, Kafka oder RabbitMQ?", "Wéi eng Plattform ass besser?". D'Wourecht ass, datt et wierklech op Är Situatioun hänkt, aktuell Erfahrung, etc.. Ech zécke meng Meenung ze ginn, well et wier ze vill vun enger Iwwersimplifikatioun eng Plattform fir all Benotzungsfäll a méiglech Aschränkungen ze recommandéieren. Ech hunn dës Serie vun Artikelen geschriwwen fir datt Dir Är eege Meenung forméiere kënnt.

Ech wëll soen datt béid Systemer Leader an dësem Beräich sinn. Ech sinn vläicht e bësse bias well aus menger Erfahrung mat Projeten tendéieren ech Saachen ze schätzen wéi garantéiert Messagebestellung an Zouverlässegkeet.

Ech gesinn aner Technologien déi dës Zouverlässegkeet a garantéiert Uerdnung feelen, da kucken ech op RabbitMQ a Kafka a realiséieren den onheemleche Wäert vu béide vun dëse Systemer.

Source: will.com

RabbitMQ vs Kafka: Feeler Toleranz an Héich Disponibilitéit