В laatste artikel we hebben gekeken naar RabbitMQ-clustering voor fouttolerantie en hoge beschikbaarheid. Laten we nu diep in Apache Kafka duiken.

Hier is de replicatie-eenheid de partitie. Elk onderwerp heeft een of meer secties. Elke sectie heeft een leider met of zonder volgers. Wanneer u een onderwerp maakt, geeft u het aantal partities en de replicatiecoëfficiënt op. De gebruikelijke waarde is 3, wat drie replica's betekent: één leider en twee volgers.

Rijst. 1. Vier secties zijn verdeeld over drie makelaars

Alle lees- en schrijfverzoeken gaan naar de leider. Volgers sturen periodiek verzoeken naar de leider om de laatste berichten te ontvangen. Consumenten wenden zich nooit tot volgers; deze laatste bestaan ​​alleen voor redundantie en fouttolerantie.

Partitiefout

Als een makelaar faalt, falen vaak de leiders van verschillende secties. In elk van hen wordt een volger van een ander knooppunt de leider. In feite is dit niet altijd het geval, aangezien de synchronisatiefactor ook van invloed is: of er gesynchroniseerde volgers zijn, en zo niet, of er mag worden overgeschakeld naar een niet-gesynchroniseerde replica. Maar laten we de zaken voorlopig niet ingewikkeld maken.

Broker 3 verlaat het netwerk en er wordt een nieuwe leider gekozen voor sectie 2 bij makelaar 2.

Rijst. 2. Broker 3 sterft en zijn volgeling op makelaar 2 wordt gekozen als de nieuwe leider van partitie 2

Dan vertrekt makelaar 1 en verliest sectie 1 ook zijn leider, wiens rol overgaat op makelaar 2.

Rijst. 3. Er is nog één makelaar over. Alle leiders zitten op één makelaar zonder redundantie

Wanneer makelaar 1 weer online komt, worden er vier volgers toegevoegd, waardoor elke partitie enige redundantie krijgt. Maar alle leiders bleven nog steeds op makelaar 2.

Rijst. 4. Leiders blijven op makelaar 2

Wanneer makelaar 3 verschijnt, zijn we terug bij drie replica's per partitie. Maar alle leiders zitten nog steeds op makelaar 2.

Rijst. 5. Onevenwichtige plaatsing van leiders na het herstel van makelaars 1 en 3

Kafka heeft een tool voor een betere herbalancering van leiders dan RabbitMQ. Daar moest je een plug-in of script van derden gebruiken dat het beleid voor het migreren van het masterknooppunt veranderde door de redundantie tijdens de migratie te verminderen. Bovendien moesten we voor grote wachtrijen tijdens de synchronisatie onbeschikbaarheid accepteren.

Kafka hanteert het concept van ‘voorkeursreplica’s’ voor de leidersrol. Wanneer onderwerppartities worden gemaakt, probeert Kafka leiders gelijkmatig over knooppunten te verdelen en deze eerste leiders als voorkeur te markeren. Na verloop van tijd kunnen leiders, als gevolg van het opnieuw opstarten van servers, storingen en verbroken verbindingen, op andere knooppunten terechtkomen, zoals in het extreme geval dat hierboven is beschreven.

Om dit op te lossen biedt Kafka twee opties:

• optie auto.leader.rebalance.enable=waar Hiermee kan het controllerknooppunt leiders automatisch opnieuw toewijzen aan voorkeursreplica's en daardoor de uniforme distributie herstellen.
• De beheerder kan het script uitvoeren kafka-preferred-replica-election.sh voor handmatige hertoewijzing.

Rijst. 6. Replica's na herbalancering

Dit was een vereenvoudigde versie van de mislukking, maar de realiteit is complexer, hoewel hier niets te ingewikkeld is. Het komt allemaal neer op gesynchroniseerde replica's (In-Sync Replica's, ISR).

Gesynchroniseerde replica's (ISR)

Een ISR is een set replica's van een partitie die als 'gesynchroniseerd' (in-sync) wordt beschouwd. Er is een leider, maar er zijn misschien geen volgers. Een volger wordt als gesynchroniseerd beschouwd als hij exacte kopieën heeft gemaakt van alle berichten van de leider voordat het interval is verstreken replica.lag.time.max.ms.

Een volger wordt uit de ISR-set verwijderd als deze:

• heeft geen verzoek ingediend om voor het interval te selecteren replica.lag.time.max.ms (vermoedelijk dood)
• slaagde er niet in om tijdens het interval te updaten replica.lag.time.max.ms (beschouwd als langzaam)

Volgers doen in het interval bemonsteringsverzoeken replica.fetch.wait.max.ms, standaard ingesteld op 500 ms.

Om het doel van ISR duidelijk uit te leggen, moeten we kijken naar bevestigingen van de producent en enkele faalscenario’s. Producenten kunnen kiezen wanneer de makelaar een bevestiging stuurt:

• acks=0, er wordt geen bevestiging verzonden
• acks=1, bevestiging wordt verzonden nadat de leider een bericht naar zijn lokale log heeft geschreven
• acks=all, er wordt een bevestiging verzonden nadat alle replica's in de ISR het bericht naar de lokale logboeken hebben geschreven

In Kafka-terminologie: als de ISR een bericht heeft opgeslagen, is het 'toegewijd'. Acks=all is de veiligste optie, maar voegt ook extra vertraging toe. Laten we eens kijken naar twee voorbeelden van mislukkingen en hoe de verschillende 'acks'-opties in wisselwerking staan ​​met het ISR-concept.

Acks=1 en ISR

In dit voorbeeld zullen we zien dat als de leider niet wacht tot elk bericht van alle volgers is opgeslagen, er gegevensverlies mogelijk is als de leider faalt. Navigeren naar een niet-gesynchroniseerde volger kan worden in- of uitgeschakeld door instelling onrein.leider.verkiezing.enable.

In dit voorbeeld heeft de fabrikant de waarde acks=1. De sectie is verdeeld over alle drie de makelaars. Broker 3 loopt achter, heeft acht seconden geleden gesynchroniseerd met de leider en staat nu 7456 berichten achter. Makelaar 1 had slechts één seconde achterstand. Onze producer stuurt een bericht en krijgt snel een antwoord terug, zonder de overhead van langzame of dode volgers waar de leider niet op zit te wachten.

Rijst. 7. ISR met drie replica's

Broker 2 valt uit en de producent krijgt een verbindingsfout. Nadat het leiderschap is overgedragen aan makelaar 1, verliezen we 123 berichten. De volger op makelaar 1 maakte deel uit van de ISR, maar was niet volledig gesynchroniseerd met de leider toen deze viel.

Rijst. 8. Berichten gaan verloren als het crasht

In configuratie bootstrap.servers De fabrikant heeft meerdere makelaars op de lijst staan ​​en kan een andere makelaar vragen wie de nieuwe sectieleider wordt. Vervolgens wordt een verbinding met makelaar 1 tot stand gebracht en wordt het verzenden van berichten voortgezet.

Rijst. 9. Het verzenden van berichten wordt na een korte pauze hervat

Makelaar 3 loopt nog verder achter. Het maakt ophaalverzoeken, maar kan niet synchroniseren. Dit kan te wijten zijn aan een trage netwerkverbinding tussen makelaars, opslagproblemen, enz. Het wordt verwijderd uit de ISR. Nu bestaat de ISR uit één replica: de leider! De fabrikant blijft berichten sturen en bevestigingen ontvangen.

Rijst. 10. Volger op makelaar 3 wordt verwijderd uit de ISR

Broker 1 gaat ten onder en de leiderschapsrol gaat naar makelaar 3 met het verlies van 15286 berichten! De fabrikant ontvangt een verbindingsfoutmelding. De overgang naar een leider buiten de ISR was alleen mogelijk vanwege de setting onclean.leader.election.enable=waar. Als het is geïnstalleerd in vals, dan zou de overgang niet plaatsvinden en zouden alle lees- en schrijfverzoeken worden afgewezen. In dit geval wachten we tot makelaar 1 terugkeert met zijn intacte gegevens in de replica, die opnieuw de leiding zal overnemen.

Rijst. 11. Makelaar 1 valt. Wanneer er een storing optreedt, gaat een groot aantal berichten verloren

De producent legt een verbinding met de laatste makelaar en ziet dat hij nu de leider van de sectie is. Hij begint berichten te sturen naar makelaar 3.

Rijst. 12. Na een korte pauze worden er opnieuw berichten verzonden naar sectie 0

We zagen dat de fabrikant, afgezien van korte onderbrekingen om nieuwe verbindingen tot stand te brengen en op zoek te gaan naar een nieuwe leider, voortdurend berichten stuurde. Deze configuratie garandeert beschikbaarheid ten koste van de consistentie (databeveiliging). Kafka verloor duizenden berichten, maar bleef nieuwe berichten accepteren.

Acks=alles en ISR

Laten we dit scenario nog een keer herhalen, maar dan met acks=alles. Broker 3 heeft een gemiddelde latentie van vier seconden. De fabrikant stuurt een bericht met acks=alles, en krijgt nu geen snel antwoord. De leider wacht tot het bericht door alle replica's in de ISR is opgeslagen.

Rijst. 13. ISR met drie replica's. De ene is langzaam, wat resulteert in opnamevertragingen

Na vier seconden extra vertraging stuurt makelaar 2 een ack. Alle replica's zijn nu volledig bijgewerkt.

Rijst. 14. Alle replica's slaan berichten op en sturen een bevestiging

Broker 3 raakt nu verder achterop en wordt verwijderd uit de ISR. De latentie wordt aanzienlijk verminderd omdat er geen langzame replica's meer in de ISR zitten. Broker 2 wacht nu alleen op makelaar 1 en hij heeft een gemiddelde vertraging van 500 ms.

Rijst. 15. De replica op makelaar 3 wordt verwijderd uit de ISR

Dan valt makelaar 2 en gaat de leiding zonder verlies van berichten over naar makelaar 1.

Rijst. 16. Makelaar 2 valt

De fabrikant vindt een nieuwe leider en begint hem berichten te sturen. De latency wordt verder verlaagd doordat de ISR nu uit één replica bestaat! Daarom de optie acks=alles voegt geen redundantie toe.

Rijst. 17. Replica op makelaar 1 neemt de leiding zonder berichten te verliezen

Dan crasht makelaar 1 en gaat de voorsprong naar makelaar 3 met een verlies van 14238 berichten!

Rijst. 18. Makelaar 1 sterft en leiderschapstransitie met een onreine omgeving resulteert in groot gegevensverlies

We konden de optie niet installeren onrein.leider.verkiezing.enable in betekenis waar. Standaard is dit gelijk vals. Instellingen acks=alles с onclean.leader.election.enable=waar biedt toegankelijkheid met enige extra gegevensbeveiliging. Maar zoals je kunt zien, kunnen we nog steeds berichten kwijtraken.

Maar wat als we de gegevensbeveiliging willen vergroten? Je kan zetten unclean.leader.election.enable = onwaar, maar dit beschermt ons niet noodzakelijkerwijs tegen gegevensverlies. Als de leider hard viel en de gegevens meenam, gaan berichten nog steeds verloren, en gaat de beschikbaarheid verloren totdat de beheerder de situatie herstelt.

Het is beter om ervoor te zorgen dat alle berichten redundant zijn en anders de opname weg te gooien. Dan is gegevensverlies, althans vanuit het oogpunt van de makelaar, alleen mogelijk bij twee of meer gelijktijdige storingen.

Acks=all, min.insync.replicas en ISR

Met onderwerpconfiguratie min.insync.replica's We verhogen het niveau van gegevensbeveiliging. Laten we het laatste deel van het vorige scenario nog eens doornemen, maar deze keer met min.insync.replicas=2.

Broker 2 heeft dus een replicaleider en de volger op makelaar 3 wordt verwijderd uit de ISR.

Rijst. 19. ISR van twee replica's

Makelaar 2 valt en de leiding gaat zonder verlies van berichten over naar makelaar 1. Maar nu bestaat de ISR uit slechts één replica. Dit voldoet niet aan het minimumaantal om records te ontvangen, en daarom reageert de makelaar op de schrijfpoging met een fout Niet GenoegReplica's.

Rijst. 20. Het aantal ISR's is één lager dan gespecificeerd in min.insync.replicas

Deze configuratie offert beschikbaarheid op voor consistentie. Voordat we een bericht bevestigen, zorgen we ervoor dat het naar ten minste twee replica's wordt geschreven. Dit geeft de fabrikant veel meer vertrouwen. Hier is berichtverlies alleen mogelijk als twee replica's tegelijkertijd in een kort interval falen totdat het bericht wordt gerepliceerd naar een extra volger, wat onwaarschijnlijk is. Maar als je super paranoïde bent, kun je de replicatiefactor instellen op 5, en min.insync.replica's tegen 3. Hier moeten drie makelaars tegelijkertijd vallen om het record te verliezen! Uiteraard betaal je voor deze betrouwbaarheid in extra latentie.

Wanneer toegankelijkheid noodzakelijk is voor gegevensbeveiliging

Zoals in geval met RabbitMQ, is toegankelijkheid soms noodzakelijk voor gegevensbeveiliging. Dit is waar u aan moet denken:

• Kan de uitgever eenvoudigweg een fout retourneren en de upstream-service of gebruiker het later opnieuw laten proberen?
• Kan de uitgever het bericht lokaal of in een database opslaan om het later opnieuw te proberen?

Als het antwoord nee is, verbetert het optimaliseren van de beschikbaarheid de gegevensbeveiliging. U verliest minder gegevens als u voor beschikbaarheid kiest in plaats van niet opnemen. Het komt dus allemaal neer op het vinden van een balans, en de beslissing hangt af van de specifieke situatie.

De betekenis van ISR

Met de ISR-suite kunt u de optimale balans kiezen tussen gegevensbeveiliging en latentie. Zorg bijvoorbeeld voor beschikbaarheid bij uitval van de meeste replica’s, waardoor de impact van dode of langzame replica’s op het gebied van latentie wordt geminimaliseerd.

De betekenis kiezen we zelf replica.lag.time.max.ms volgens uw behoeften. In wezen betekent deze parameter hoeveel vertraging we wanneer willen accepteren acks=alles. De standaardwaarde is tien seconden. Als dit te lang voor je is, kun je het inkorten. Dan zal de frequentie van veranderingen in de ISR toenemen, omdat volgers vaker zullen worden verwijderd en toegevoegd.

RabbitMQ is eenvoudigweg een set spiegels die moeten worden gerepliceerd. Langzame spiegels introduceren extra latentie, en dode spiegels kunnen wachten totdat de pakketten die de beschikbaarheid van elk knooppunt controleren (net tick) reageren. ISR is een interessante manier om deze latentieproblemen te voorkomen. Maar we lopen het risico dat we overtollig personeel kwijtraken, omdat de ISR zich alleen maar kan terugtrekken tot de leider. Gebruik de instelling om dit risico te voorkomen min.insync.replica's.

Klantverbindingsgarantie

In instellingen bootstrap.servers producent en consument kunnen meerdere makelaars opgeven voor het verbinden van klanten. Het idee is dat wanneer één knooppunt uitvalt, er meerdere reserveknooppunten overblijven waarmee de client een verbinding kan openen. Dit zijn niet noodzakelijkerwijs sectieleiders, maar eenvoudigweg een springplank voor de eerste belasting. De client kan vragen welk knooppunt de leider van de lees-/schrijfpartitie host.

In RabbitMQ kunnen clients verbinding maken met elk knooppunt, en interne routering stuurt het verzoek naar de plaats waar het naartoe moet. Dit betekent dat u een load balancer vóór RabbitMQ kunt installeren. Kafka vereist dat clients verbinding maken met het knooppunt dat de corresponderende partitieleider host. In een dergelijke situatie kunt u geen load balancer installeren. Lijst bootstrap.servers Het is van cruciaal belang dat clients na een storing toegang kunnen krijgen tot de juiste knooppunten en deze kunnen vinden.

Kafka-consensusarchitectuur

Tot nu toe hebben we er niet bij stilgestaan ​​hoe het cluster leert over de val van de makelaar en hoe een nieuwe leider wordt gekozen. Om te begrijpen hoe Kafka met netwerkpartities werkt, moet u eerst de consensusarchitectuur begrijpen.

Elk Kafka-cluster wordt ingezet samen met een Zookeeper-cluster, een gedistribueerde consensusservice waarmee het systeem consensus kan bereiken over een bepaalde status, waarbij consistentie prioriteit krijgt boven beschikbaarheid. De toestemming van een meerderheid van de Zookeeper-knooppunten is vereist om lees- en schrijfbewerkingen goed te keuren.

Zookeeper slaat de status van het cluster op:

• Lijst met onderwerpen, secties, configuratie, huidige leiderreplica's, voorkeursreplica's.
• Clusterleden. Elke makelaar pingt het Zookeeper-cluster. Als er binnen een bepaalde periode geen ping wordt ontvangen, registreert Zookeeper de makelaar als niet beschikbaar.
• Het selecteren van de hoofd- en reserveknooppunten voor de controller.

Het controllerknooppunt is een van de Kafka-makelaars die verantwoordelijk is voor het kiezen van replicaleiders. Zookeeper stuurt meldingen naar de controller over clusterlidmaatschap en onderwerpwijzigingen, en de controller moet op deze wijzigingen reageren.

Laten we bijvoorbeeld een nieuw onderwerp nemen met tien partities en een replicatiefactor van 3. De controller moet voor elke partitie een leider kiezen, in een poging de leiders optimaal onder de makelaars te verdelen.

Voor elke sectiecontroller:

• werkt informatie in Zookeeper bij over ISR en leider;
• Stuurt een LeaderAndISRCommand naar elke makelaar die als host fungeert voor een replica van deze partitie, waarbij de makelaars worden geïnformeerd over de ISR en de leider.

Wanneer een makelaar met een leider valt, stuurt Zookeeper een melding naar de controller en kiest deze een nieuwe leider. Ook hier werkt de controller eerst Zookeeper bij en stuurt vervolgens een opdracht naar elke makelaar om hen op de hoogte te stellen van de leiderschapsverandering.

Elke leider is verantwoordelijk voor het rekruteren van ISR's. Instellingen replica.lag.time.max.ms bepaalt wie daar binnenkomt. Wanneer de ISR verandert, verzendt de leider nieuwe informatie naar Zookeeper.

Zookeeper wordt altijd op de hoogte gehouden van eventuele wijzigingen, zodat in geval van een storing het management soepel overgaat naar een nieuwe leider.

Rijst. 21. Kafka-consensus

Replicatieprotocol

Als u de details van replicatie begrijpt, krijgt u een beter inzicht in mogelijke scenario's voor gegevensverlies.

Bemonsteringsquery's, Log End Offset (LEO) en Highwater Mark (HW)

We waren van mening dat volgers periodiek ophaalverzoeken naar de leider sturen. Het standaardinterval is 500 ms. Dit verschilt van RabbitMQ doordat bij RabbitMQ de replicatie niet wordt geïnitieerd door de wachtrijspiegel, maar door de master. De meester pusht wijzigingen in de spiegels.

De leider en alle volgers bewaren het Log End Offset (LEO) en het Highwater (HW) label. Het LEO-teken slaat de offset van het laatste bericht op in de lokale replica, en de HW bewaart de offset van de laatste commit. Houd er rekening mee dat voor de commit-status het bericht moet worden gehandhaafd in alle ISR-replica's. Dit betekent dat LEO meestal iets voorloopt op HW.

Wanneer de leider een bericht ontvangt, slaat hij dit lokaal op. De volger doet een ophaalverzoek door zijn LEO te verzenden. De leider verzendt vervolgens een reeks berichten vanaf deze LEO en verzendt ook de huidige HW. Wanneer de leider informatie ontvangt dat alle replica's het bericht op de gegeven offset hebben opgeslagen, verplaatst hij de HW-markering. Alleen de leider kan de HW verplaatsen, en dus weten alle volgers de huidige waarde in de antwoorden op hun verzoek. Dit betekent dat volgers mogelijk achterlopen op de leider in zowel boodschap als HW-kennis. Consumenten ontvangen alleen berichten tot en met de huidige hardware.

Merk op dat "aanhoudend" betekent dat het naar het geheugen wordt geschreven, niet naar de schijf. Voor prestaties synchroniseert Kafka met een specifiek interval naar schijf. RabbitMQ heeft ook zo'n interval, maar zal pas een bevestiging naar de uitgever sturen nadat de master en alle mirrors het bericht naar schijf hebben geschreven. De Kafka-ontwikkelaars hebben om prestatieredenen besloten een bevestiging te sturen zodra het bericht in het geheugen is geschreven. Kafka vermoedt dat redundantie het risico compenseert dat bevestigde berichten slechts kortstondig in het geheugen worden opgeslagen.

Het falen van de leider

Wanneer een leider valt, waarschuwt Zookeeper de controller en selecteert deze een nieuwe leiderreplica. De nieuwe leider zet een nieuw HW-teken neer volgens zijn LEO. Volgers ontvangen vervolgens informatie over de nieuwe leider. Afhankelijk van de versie van Kafka kiest de volger een van de twee scenario's:

1. Het zal het lokale logboek naar een bekende HW afkappen en een verzoek naar de nieuwe leider sturen voor berichten na deze markering.
2. Zal een verzoek naar de leider sturen om de HW te achterhalen op het moment dat hij tot leider werd gekozen, en vervolgens het logboek inkorten tot deze verschuiving. Het zal dan beginnen met het maken van periodieke ophaalverzoeken, beginnend bij deze offset.

Een volger moet mogelijk het logboek inkorten om de volgende redenen:

• Wanneer een leider faalt, wint de eerste volger in de ISR-set die bij Zookeeper is geregistreerd de verkiezing en wordt hij de leider. Alle volgers op ISR hebben, hoewel ze als “gesynchroniseerd” worden beschouwd, mogelijk niet alle berichten van de voormalige leider ontvangen. Het is heel goed mogelijk dat de aanbevolen volger niet over de meest actuele kopie beschikt. Kafka zorgt ervoor dat er geen divergentie bestaat tussen replica's. Om discrepanties te voorkomen, moet elke volger dus zijn logboek inkorten tot de HW-waarde van de nieuwe leider op het moment van zijn verkiezing. Dit is nog een reden waarom instelling acks=alles zo belangrijk voor consistentie.
• Berichten worden periodiek naar schijf geschreven. Als alle clusterknooppunten tegelijkertijd uitvallen, worden replica's met verschillende offsets op de schijven opgeslagen. Het is mogelijk dat wanneer makelaars weer online komen, de nieuwe leider die wordt gekozen achter zijn volgers staat omdat hij vóór de anderen op schijf werd opgeslagen.

Hereniging met het cluster

Wanneer ze zich weer bij het cluster voegen, doen de replica's hetzelfde als wanneer een leider faalt: ze controleren de replica van de leider en kappen hun logboek af naar de HW (op het moment van verkiezing). Ter vergelijking: RabbitMQ behandelt herenigde knooppunten net zo goed als volledig nieuw. In beide gevallen gooit de makelaar elke bestaande status weg. Als automatische synchronisatie wordt gebruikt, moet de master absoluut alle huidige inhoud naar de nieuwe spiegel repliceren in een “laat de hele wereld wachten” -methode. De master accepteert tijdens deze bewerking geen lees- of schrijfbewerkingen. Deze aanpak zorgt voor problemen bij grote wachtrijen.

Kafka is een gedistribueerd logboek en slaat over het algemeen meer berichten op dan een RabbitMQ-wachtrij, waarbij gegevens uit de wachtrij worden verwijderd nadat deze zijn gelezen. Actieve wachtrijen moeten relatief klein blijven. Maar Kafka is een logboek met een eigen bewaarbeleid, dat een periode van dagen of weken kan instellen. Het blokkeren van wachtrijen en volledige synchronisatie zijn absoluut onaanvaardbaar voor een gedistribueerd logbestand. In plaats daarvan korten Kafka-volgers eenvoudigweg hun logboek in op de HW van de leider (op het moment van zijn verkiezing) als hun kopie voorloopt op de leider. In het meer waarschijnlijke geval, wanneer de volger achterloopt, begint hij eenvoudigweg ophaalverzoeken te doen, te beginnen met zijn huidige LEO.

Nieuwe of opnieuw aangesloten volgers starten buiten de ISR en nemen niet deel aan commits. Ze werken gewoon samen met de groep en ontvangen zo snel mogelijk berichten totdat ze de leider hebben ingehaald en de ISR binnenkomen. Er is geen sprake van een lock-in en het is niet nodig om al uw gegevens weg te gooien.

Verlies van connectiviteit

Kafka heeft meer componenten dan RabbitMQ, dus het heeft een complexere reeks gedragingen wanneer de verbinding met het cluster wordt verbroken. Maar Kafka is oorspronkelijk ontworpen voor clusters, dus de oplossingen zijn zeer goed doordacht.

Hieronder staan ​​verschillende scenario's voor connectiviteitsfouten:

• Scenario 1: De volger ziet de leider niet, maar ziet nog steeds de dierenverzorger.
• Scenario 2: De leider ziet geen volgers, maar ziet nog steeds Zookeeper.
• Scenario 3: De volger ziet de leider, maar ziet de dierenverzorger niet.
• Scenario 4: De leider ziet de volgers, maar ziet de dierenverzorger niet.
• Scenario 5: De volger staat volledig los van zowel andere Kafka-knooppunten als Zookeeper.
• Scenario 6: De leider staat volledig los van zowel andere Kafka-knooppunten als Zookeeper.
• Scenario 7: Het Kafka-controllerknooppunt kan geen ander Kafka-knooppunt zien.
• Scenario 8: Kafka-controller ziet Zookeeper niet.

Elk scenario heeft zijn eigen gedrag.

Scenario 1: Volger ziet de leider niet, maar ziet nog steeds Dierenverzorger

Rijst. 22. Scenario 1: ISR van drie replica's

De connectiviteitsfout scheidt makelaar 3 van makelaars 1 en 2, maar niet van Zookeeper. Broker 3 kan geen ophaalverzoeken meer verzenden. Nadat de tijd is verstreken replica.lag.time.max.ms het wordt verwijderd uit de ISR en neemt niet deel aan berichtcommits. Zodra de connectiviteit is hersteld, hervat het de ophaalverzoeken en sluit het zich aan bij de ISR wanneer het de leider inhaalt. Zookeeper blijft pings ontvangen en gaat ervan uit dat de makelaar springlevend is.

Rijst. 23. Scenario 1: De broker wordt uit de ISR verwijderd als er geen ophaalverzoek van wordt ontvangen binnen het replica.lag.time.max.ms-interval

Er is geen sprake van split-brain of node-opschorting zoals in RabbitMQ. In plaats daarvan wordt de redundantie verminderd.

Scenario 2: Leider ziet geen volgers, maar ziet nog steeds Zookeeper

Rijst. 24. Scenario 2. Leider en twee volgers

Een storing in de netwerkconnectiviteit scheidt de leider van de volgers, maar de makelaar kan Zookeeper nog steeds zien. Net als in het eerste scenario krimpt de ISR, maar deze keer alleen voor de leider, omdat alle volgers stoppen met het verzenden van ophaalverzoeken. Opnieuw is er geen logische scheiding. In plaats daarvan is er sprake van een verlies aan redundantie voor nieuwe berichten totdat de connectiviteit is hersteld. Zookeeper blijft pings ontvangen en gelooft dat de makelaar springlevend is.

Rijst. 25. Scenario 2. ISR is alleen gekrompen tot de leider

Scenario 3. De volger ziet de leider, maar ziet de dierenverzorger niet

De volger is gescheiden van Zookeeper, maar niet van de makelaar met de leider. Als gevolg hiervan blijft de volger ophaalverzoeken doen en lid blijven van de ISR. Zookeeper ontvangt geen pings meer en registreert een brokercrash, maar aangezien het slechts een volger is, zijn er na herstel geen gevolgen.

Rijst. 26. Scenario 3: De volger blijft ophaalverzoeken naar de leider sturen

Scenario 4. Leider ziet volgers, maar ziet Dierenverzorger niet

Rijst. 27. Scenario 4. Leider en twee volgers

De leider is gescheiden van Zookeeper, maar niet van de makelaars met volgers.

Rijst. 28. Scenario 4: Leider geïsoleerd van Zookeeper

Na enige tijd zal Zookeeper een makelaarsfout registreren en de beheerder hiervan op de hoogte stellen. Hij zal onder zijn volgelingen een nieuwe leider kiezen. De oorspronkelijke leider zal echter blijven denken dat hij de leider is en zal inzendingen van blijven accepteren acks=1. Volgers sturen hem niet langer ophaalverzoeken, dus hij zal ze als dood beschouwen en proberen de ISR tot zichzelf te verkleinen. Maar omdat het geen verbinding heeft met Zookeeper, kan het dit niet doen en zal het op dat moment weigeren verdere inzendingen te accepteren.

berichten acks=alles ontvangt geen bevestiging omdat de ISR eerst alle replica's inschakelt en berichten hen niet bereiken. Wanneer de oorspronkelijke leider hen uit de ISR probeert te verwijderen, zal dit niet lukken en zal hij helemaal geen berichten meer accepteren.

Klanten merken al snel de verandering in leider en beginnen records naar de nieuwe server te verzenden. Zodra het netwerk is hersteld, ziet de oorspronkelijke leider dat deze niet langer een leider is en wordt de log ingekort tot de HW-waarde die de nieuwe leider had op het moment van de mislukking om logdivergentie te voorkomen. Vervolgens zal het ophaalverzoeken naar de nieuwe leider sturen. Alle records van de oorspronkelijke leider die niet naar de nieuwe leider worden gerepliceerd, gaan verloren. Dat wil zeggen dat berichten die niet door de oorspronkelijke leider werden erkend in die paar seconden waarin twee leiders aan het werk waren, verloren zullen gaan.

Rijst. 29. Scenario 4. De leider op makelaar 1 wordt een volger nadat het netwerk is hersteld

Scenario 5: De volger staat volledig los van zowel andere Kafka-knooppunten als Zookeeper

De volger is volledig geïsoleerd van zowel andere Kafka-knooppunten als Zookeeper. Hij verwijdert zichzelf eenvoudigweg uit de ISR totdat het netwerk is hersteld, en haalt dan de anderen in.

Rijst. 30. Scenario 5: Geïsoleerde volger wordt verwijderd uit ISR

Scenario 6: De leider staat volledig los van zowel andere Kafka-knooppunten als Zookeeper

Rijst. 31. Scenario 6. Leider en twee volgers

De leider is volledig geïsoleerd van zijn volgers, de controller en Zookeeper. Gedurende een korte periode blijven er inzendingen van worden geaccepteerd acks=1.

Rijst. 32. Scenario 6: Isoleren van de leider van andere Kafka- en Zookeeper-knooppunten

Geen verzoeken ontvangen na het verstrijken van de geldigheidsduur replica.lag.time.max.ms, zal het proberen de ISR tot zichzelf te verkleinen, maar zal dit niet kunnen omdat er geen communicatie is met Zookeeper, en dan zal het stoppen met het accepteren van schrijfbewerkingen.

Ondertussen zal Zookeeper de geïsoleerde makelaar als dood markeren en zal de controller een nieuwe leider kiezen.

Rijst. 33. Scenario 6. Twee leiders

De oorspronkelijke leider accepteert mogelijk een paar seconden inzendingen, maar accepteert dan geen berichten meer. Clients worden elke 60 seconden bijgewerkt met de nieuwste metadata. Ze worden op de hoogte gebracht van de leiderwisseling en beginnen inzendingen naar de nieuwe leider te sturen.

Rijst. 34. Scenario 6: Fabrikanten schakelen over naar een nieuwe leider

Alle bevestigde inzendingen die door de oorspronkelijke leider zijn gedaan sinds het verlies van connectiviteit, gaan verloren. Zodra het netwerk is hersteld, zal de oorspronkelijke leider via Zookeeper ontdekken dat hij niet langer de leider is. Vervolgens zal het zijn logboek naar de HW van de nieuwe leider op het moment van verkiezing inkorten en beginnen met het verzenden van verzoeken als volger.

Rijst. 35. Scenario 6: De oorspronkelijke leider wordt een volger nadat de netwerkconnectiviteit is hersteld

In deze situatie kan een logische scheiding gedurende een korte periode optreden, maar alleen als dat zo is acks=1 и min.insync.replica's ook 1. De logische scheiding eindigt automatisch nadat het netwerk is hersteld, wanneer de oorspronkelijke leider zich realiseert dat hij niet langer de leider is, of wanneer alle cliënten zich realiseren dat de leider is veranderd en beginnen te schrijven naar de nieuwe leider - afhankelijk van wat zich het eerst voordoet. In ieder geval zullen sommige berichten verloren gaan, maar alleen met acks=1.

Er is een andere variant van dit scenario waarbij, net voordat het netwerk zich splitste, de volgers achterop raakten en de leider de ISR tot alleen zichzelf comprimeerde. Het raakt dan geïsoleerd vanwege verlies van connectiviteit. Er wordt een nieuwe leider gekozen, maar de oorspronkelijke leider blijft zelfs inzendingen accepteren acks=alles, omdat er behalve hij niemand anders in ISR is. Deze gegevens gaan verloren zodra het netwerk is hersteld. De enige manier om deze optie te vermijden is min.insync.replicas = 2.

Scenario 7: Kafka-controllerknooppunt kan geen ander Kafka-knooppunt zien

Over het algemeen zal de controller, zodra de verbinding met een Kafka-knooppunt is verbroken, geen leiderwijzigingsinformatie ernaar kunnen verzenden. In het ergste geval zal dit op de korte termijn leiden tot een logische scheiding, zoals in scenario 6. Vaker wel dan niet zal de makelaar eenvoudigweg geen kandidaat voor leiderschap worden als deze faalt.

Scenario 8: Kafka-controller ziet Zookeeper niet

Zookeeper ontvangt geen ping van de gevallen controller en selecteert een nieuw Kafka-knooppunt als controller. De originele controller kan zich als zodanig blijven presenteren, maar ontvangt geen meldingen van Zookeeper en hoeft dus geen taken uit te voeren. Zodra het netwerk hersteld is, zal hij zich realiseren dat hij niet langer een controller is, maar een regulier Kafka-knooppunt is geworden.

Conclusies uit de scenario’s

We zien dat het verlies van volgerconnectiviteit niet resulteert in berichtverlies, maar simpelweg de redundantie tijdelijk vermindert totdat het netwerk is hersteld. Dit kan uiteraard leiden tot gegevensverlies als een of meer knooppunten verloren gaan.

Als de leider gescheiden raakt van Zookeeper vanwege een verlies van connectiviteit, kan dit ertoe leiden dat berichten verloren gaan acks=1. Gebrek aan communicatie met Zookeeper veroorzaakt een korte logische breuk met de twee leiders. Dit probleem wordt opgelost door de parameter acks=alles.

Parameter min.insync.replica's in twee of meer replica's biedt extra zekerheid dat dergelijke kortetermijnscenario's niet zullen resulteren in verloren berichten zoals in scenario 6.

Samenvatting van verloren berichten

Laten we alle manieren opsommen waarop u gegevens in Kafka kunt verliezen:

• Elke leiderfout als berichten werden bevestigd met behulp van acks=1
• Elke onreine overgang van leiderschap, dat wil zeggen naar een volgeling buiten de ISR, zelfs met acks=alles
• De leider isoleren van Zookeeper als berichten werden bevestigd met behulp van acks=1
• Volledige isolatie van de leider die de ISR-groep al tot zichzelf heeft gekrompen. Alle berichten gaan zelfs verloren acks=alles. Dit is alleen waar als min.insync.replicas=1.
• Gelijktijdige storingen van alle partitieknooppunten. Omdat berichten vanuit het geheugen worden bevestigd, zijn sommige mogelijk nog niet naar schijf geschreven. Na het opnieuw opstarten van de servers kunnen sommige berichten ontbreken.

Onzuivere leiderschapstransities kunnen worden vermeden door deze te verbieden of door ten minste twee ontslagen te garanderen. De meest duurzame configuratie is een combinatie acks=alles и min.insync.replica's meer dan 1.

Directe vergelijking van de betrouwbaarheid van RabbitMQ en Kafka

Om betrouwbaarheid en hoge beschikbaarheid te garanderen, implementeren beide platforms een primair en secundair replicatiesysteem. RabbitMQ heeft echter een achilleshiel. Wanneer na een storing opnieuw verbinding wordt gemaakt, verwijderen knooppunten hun gegevens en wordt de synchronisatie geblokkeerd. Deze dubbele klap doet twijfels rijzen over de lange levensduur van grote wachtrijen in RabbitMQ. U zult ofwel minder redundantie ofwel lange blokkeertijden moeten accepteren. Het verminderen van redundantie vergroot het risico op grootschalig gegevensverlies. Maar als de wachtrijen klein zijn, kunnen vanwege de redundantie korte periodes van onbeschikbaarheid (enkele seconden) worden opgevangen door herhaalde verbindingspogingen.

Kafka heeft dit probleem niet. Het negeert alleen gegevens die betrekking hebben op het punt van verschil tussen de leider en de volger. Alle gedeelde gegevens worden opgeslagen. Bovendien blokkeert replicatie het systeem niet. De leider blijft berichten accepteren terwijl de nieuwe volger de achterstand inhaalt, dus voor devops wordt het een triviale taak om lid te worden of opnieuw lid te worden van het cluster. Natuurlijk zijn er nog steeds problemen zoals netwerkbandbreedte tijdens replicatie. Als u meerdere volgers tegelijkertijd toevoegt, kunt u een bandbreedtelimiet tegenkomen.

RabbitMQ is superieur aan Kafka wat betreft betrouwbaarheid wanneer meerdere servers in een cluster tegelijkertijd uitvallen. Zoals we al hebben gezegd, stuurt RabbitMQ pas een bevestiging naar de uitgever nadat het bericht door de master en alle mirrors naar schijf is geschreven. Maar dit voegt om twee redenen extra latentie toe:

• fsync elke paar honderd milliseconden
• Het falen van de spiegel kan pas worden opgemerkt nadat de levensduur van de pakketten die de beschikbaarheid van elk knooppunt (net tick) controleren, is verstreken. Als de spiegel langzamer gaat of valt, voegt dit een vertraging toe.

Kafka's weddenschap is dat als een bericht op meerdere knooppunten wordt opgeslagen, het berichten kan bevestigen zodra ze in het geheugen terechtkomen. Hierdoor bestaat het risico dat berichten van welk type dan ook (zelfs acks=alles, min.insync.replicas=2) bij gelijktijdige storing.

Over het algemeen vertoont Kafka betere softwareprestaties en is het vanaf de basis ontworpen voor clusters. Het aantal volgers kan indien nodig worden verhoogd naar 11 voor de betrouwbaarheid. Replicatiefactor 5 en minimaal aantal replica's gesynchroniseerd min.insync.replicas=3 zal het verlies van berichten tot een zeer zeldzame gebeurtenis maken. Als uw infrastructuur deze replicatieverhouding en redundantieniveau kan ondersteunen, kunt u voor deze optie kiezen.

RabbitMQ-clustering is goed voor kleine wachtrijen. Maar zelfs kleine wachtrijen kunnen snel groeien als er veel verkeer is. Zodra de wachtrijen groot worden, moet u moeilijke keuzes maken tussen beschikbaarheid en betrouwbaarheid. RabbitMQ-clustering is het meest geschikt voor atypische situaties waarin de voordelen van de flexibiliteit van RabbitMQ opwegen tegen de eventuele nadelen van de clustering.

Een tegengif voor de kwetsbaarheid van RabbitMQ voor grote wachtrijen is om ze op te delen in veel kleinere wachtrijen. Als u niet de volledige bestelling van de hele wachtrij wilt, maar alleen de relevante berichten (bijvoorbeeld berichten van een specifieke klant), of helemaal niets wilt bestellen, dan is deze optie acceptabel: kijk naar mijn project Herbalancer om de wachtrij te splitsen (het project bevindt zich nog in een vroeg stadium).

Vergeet ten slotte een aantal bugs in de cluster- en replicatiemechanismen van zowel RabbitMQ als Kafka niet. In de loop van de tijd zijn systemen volwassener en stabieler geworden, maar geen enkel bericht zal ooit 100% veilig zijn tegen verlies! Daarnaast gebeuren er grootschalige ongelukken in datacenters!

Als ik iets heb gemist, een fout heb gemaakt of als je het niet eens bent met een van de punten, schrijf dan gerust een reactie of neem contact met mij op.

Vaak wordt mij gevraagd: “Wat te kiezen, Kafka of RabbitMQ?”, “Welk platform is beter?”. De waarheid is dat het echt afhangt van je situatie, huidige ervaring, enz. Ik aarzel om mijn mening te geven, omdat het een te grote vereenvoudiging zou zijn om één platform aan te bevelen voor alle gebruiksscenario's en mogelijke beperkingen. Ik heb deze serie artikelen geschreven zodat jij je eigen mening kunt vormen.

Ik wil zeggen dat beide systemen leiders zijn op dit gebied. Ik ben misschien een beetje bevooroordeeld omdat ik vanuit mijn ervaring met projecten de neiging heb waarde te hechten aan zaken als gegarandeerde berichtvolgorde en betrouwbaarheid.

Ik zie andere technologieën die deze betrouwbaarheid en gegarandeerde bestelling missen, dan kijk ik naar RabbitMQ en Kafka en besef ik de ongelooflijke waarde van beide systemen.

Bron: www.habr.com