Felhantering och hög tillgänglighet är omfattande ämnen, så vi kommer att ägna artiklar åt RabbitMQ och Kafka var för sig. Den här artikeln handlar om RabbitMQ, och nästa handlar om Kafka i jämförelse med RabbitMQ. Artikeln är lång, så gör dig bekväm.

Vi kommer att gå igenom strategier för felhantering, konsistens och hög tillgänglighet (HA), samt kompromisser som måste göras i varje strategi. RabbitMQ kan köras på en kluster av noder - och då klassificeras den som ett distribuerat system. När vi pratar om distribuerade system pratar vi ofta om konsistens och tillgänglighet.

Dessa begrepp beskriver hur systemet beter sig vid fel. Fel på nätverksanslutningen, serverfel, hårddiskfel, tillfällig otillgänglighet på servern på grund av skräpunghämtning, paketförlust eller nedsatt nätverksanslutning. Allt detta kan leda till dataförlust eller konflikter. Det visar sig att det är praktiskt taget omöjligt att bygga ett system som samtidigt är helt konsekvent (utan dataförlust, utan datakollisioner) och tillgängligt (som kommer att ta emot läs- och skrivoperationer) för alla felalternativ.

Vi kommer att se att konsistens och tillgänglighet finns i olika ändar av spektrumet, och du måste välja åt vilket håll du ska optimera. Den goda nyheten är att med RabbitMQ är ett sådant val möjligt. Du har sådana "nördiga" reglage för att flytta balansen mot större konsistens eller större tillgänglighet.

Vi kommer att fokusera särskilt på vilka konfigurationer som leder till dataförlust på grund av bekräftade meddelanden. Det finns en ansvarskedja mellan publicerare, mäklare och konsumenter. När ett meddelande har överlämnats till mäklaren är det hans uppgift att inte förlora meddelandet. När mäklaren bekräftar för publiceraren att han har fått meddelandet, förväntar vi oss att det inte kommer att gå förlorat. Men vi kommer att se att detta faktiskt kan hända beroende på din mäklares och publicerares konfiguration.

Uthållighet för enskild nod

Uthålliga köer/rutter

I RabbitMQ finns det två typer av köer: långvariga/stabila (durable) och icke-stabila (non-durable). Alla köer sparas i databasen Mnesia. Stabil köer deklareras på nytt vid start av noden och överlever därmed omstart, systemkrasch eller serverkrasch (så länge data sparas). Det innebär att så länge som du deklarerar routing (exchange) och kö som stabila kommer kö-/routinginfrastrukturen att återgå till driftläge.

Icke-stabila köer och routing tas bort vid omstart av noden.

Stabila meddelanden

Att en kö är hållbar innebär inte att alla dess meddelanden överlever omstarten av noden. Endast meddelanden som publiceraren har ställt in som stabila (persistent) kommer att återställas. Stabila meddelanden innebär faktiskt en extra belastning på mäklaren, men om förlusten av ett meddelande är oacceptabel, finns det inget annat alternativ.

Fig. 1. Stabilitetsmatris

Klassificering med kö-mirroring

För att överleva förlusten av mäklaren behöver vi redundans. Vi kan kombinera flera RabbitMQ-noder i ett kluster och sedan lägga till ytterligare redundans genom att replikera köer mellan flera noder. På så sätt, om en nod går ner, förlorar vi inga data och förblir tillgängliga.

Kö-mirroring:

• en huvudkö (master) som tar emot alla kommandon för skrivning och läsning
• en eller flera spegeln som tar emot alla meddelanden och metadata från huvudkön. Dessa spegeln finns inte för att öka kapaciteten, utan uteslutande för redundans.

Fig. 2. Kö-mirroring

Mirroring ställs in med en motsvarande policy. I den kan du välja replikationsfaktor och till och med noder där kön ska placeras. Exempel:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (en master och en spegel)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Bekräftelse till publiceraren

För att uppnå konsekvent registrering krävs bekräftelser från pubilsharen (Publisher Confirms). Utan dessa finns det risk för att meddelanden går förlorade. Bekräftelsen skickas till pubilsharen efter att meddelandet har skrivits till disk. RabbitMQ skriver meddelanden till disk inte vid mottagning, utan på periodisk basis, inom några hundra millisekunder. När kön speglas skickas bekräftelsen endast efter att alla speglar också har skrivit sin kopia av meddelandet till disk. Detta innebär att användning av bekräftelser tillför fördröjning, men ifall dataskydd är viktigt är de nödvändiga.

Felfri kö

När broker avslutar eller kraschar, kopplas alla ledande köer (master) på denna nod bort tillsammans med den. Klustret väljer därefter den äldsta spegeln av varje master och främjar den som ny master.

Fig. 3. Flera speglade köer och deras policyer

Broker 3 kraschar. Observera att spegeln av Kö C på Broker 2 höjs till master. Observera också att en ny spegel för Kö C har skapats på Broker 1. RabbitMQ försöker alltid upprätthålla den angivna reproduktionskvoten i dina policyer.

Fig. 4. Broker 3 kopplas bort, vilket orsakar en köavbrott för Kö C

Nästa broker 1 kraschar! Vi har bara en broker kvar. Spegeln av Kö B höjs till master.

Fig. 5

Vi har återfått Broker 1. Oavsett hur framgångsrikt datan överlevde förlusten och återställningen av brokern, kastas alla speglade meddelanden i kön bort vid omstart. Det är viktigt att notera, eftersom det får konsekvenser. Vi kommer snart att titta på dessa konsekvenser. Således är Broker 1 nu återigen en medlem av klustret, och klustret försöker att följa policyerna och skapar därför speglar på Broker 1.

I detta fall var förlusten av Broker 1 total, liksom datan, så den ospeglar Kö B har gått förlorad helt.

Fig. 6. Broker 1 återkommer till tjänst

Broker 3 har återupptagit sin funktion, så köerna A och B får tillbaka sina skapade spegelkopior för att tillfredsställa sina HA-policyer. Men nu finns alla huvudköer på en och samma nod! Detta är inte idealiskt, bättre med en jämn fördelning mellan noderna. Tyvärr finns det inga särskilda alternativ för att ombalansera mästarna här. Vi återkommer till detta problem senare, eftersom vi först behöver se på synkroniseringen av kön.

Fig. 7. Broker 3 återupptar funktion. Alla huvudköer på en enda nod!

Så nu bör ni ha en uppfattning om hur speglar ger redundans och failover. Detta garanterar tillgänglighet vid nodfel och skyddar mot datarisker. Men vi är inte klara, för allt är faktiskt mer komplicerat.

Synkronisering

Vid skapandet av en ny spegel kommer alla nya meddelanden alltid att replikeras till denna spegel och eventuella andra. När det gäller existerande data i huvudkön kan vi replikera dem till den nya spegeln, som blir en fullständig kopia av mästaren. Vi kan också välja att inte replikera existerande meddelanden och låta huvudkön och den nya spegeln synka med tiden, så att nya meddelanden kommer in i slutet och existerande meddelanden tas bort från början av huvudkön.

Sådan synkronisering utförs automatiskt eller manuellt och hanteras med hjälp av köpolicyer. Låt oss ta ett exempel.

Vi har två speglade köer. Köt A synkroniseras automatiskt, medan Köt B synkroniseras manuellt. Båda köerna har tio meddelanden.

Fig. 8. Två köer med olika synkroniseringslägen

Nu förlorar vi Broker 3.

Fig. 9. Broker 3 har kraschat

Broker 3 återupptar sin funktion. Klustret skapar en spegel för varje kö på den nya noden och synkroniserar automatiskt den nya Köt A med mästaren. Emellertid förblir spegeln för den nya Köt B tom. Så vi har full redundans för Köt A och bara en spegel för existerande meddelanden i Köt B.

Fig. 10. Den nya spegeln för Köt A får alla existerande meddelanden, medan den nya spegeln för Köt B inte får något.

I båda köerna tas ytterligare tio meddelanden emot. Sedan går Broker 2 ner, och Kö A återgår till den äldsta kopian som finns på Broker 1. Vid ett fel inträffar ingen dataloss. I Kö B finns tjugo meddelanden i master och bara tio i kopian, eftersom denna kö aldrig replikerade de ursprungliga tio meddelandena.

Fig. 11. Kö A återgår till Broker 1 utan meddelandeloss

I båda köerna tas ytterligare tio meddelanden emot. Nu går Broker 1 ner. Kö A växlar utan problem till kopian utan dataloss. Däremot upplever Kö B problem. Vid detta skede kan vi optimera antingen tillgänglighet eller konsistens.

Om vi vill optimera tillgänglighet, bör policyn ha-promote-on-failure ställas in till always. Detta är standardvärdet, så man kan helt enkelt avstå från att ange policyn. I så fall tillåter vi i praktiken fel i osynkroniserade kopior. Detta kommer att leda till dataloss, men kön förblir tillgänglig för läsning och skrivning.

Fig. 12. Kö A återgår till Broker 3 utan meddelandeloss. Kö B återgår till Broker 3 med förlust av tio meddelanden

Vi kan också ställa in ha-promote-on-failure till värdet when-synced. I detta fall kommer kön istället för att återgå till kopian att vänta tills Broker 1 med sina data återvänder i drift. Efter dess återgång finns huvudkön återigen på Broker 1 utan dataloss. Tillgänglighet offras för dataskydd. Men detta är ett riskabelt läge som kan leda till fullständig dataloss, vilket vi kommer att titta på inom kort.

Fig. 13. Kö B förblir otillgänglig efter att Broker 1 förlorats

Du kanske ställer dig frågan: "Kanske är det bättre att aldrig använda automatisk synkronisering?". Svaret är att synkronisering är en blockerande operation. Under synkroniseringen kan huvudkön inte utföra några läs- eller skrivoperationer!

Låt oss titta på ett exempel. Nu har vi mycket stora kötider. Hur kan de växa till sådana storlekar? Av flera skäl:

• Köerna används inte aktivt
• Detta är höghastighetsköer, och just nu arbetar konsumenterna långsamt
• Detta är höghastighetsköer, en fel inträffade, och konsumenterna försöker komma ikapp

Figur 14. Två stora köer med olika synkroniseringslägen

Nu faller Broker 3.

Figur 15. Broker 3 faller och lämnar en master och en spegel i varje kö

Broker 3 återgår i drift och nya speglar skapas. Huvudkö A börjar replikera befintliga meddelanden till den nya spegeln, och under tiden är kön otillgänglig. Det tar två timmar att replikera data, vilket innebär två timmars stillestånd för denna kö!

Kö B förblir dock tillgänglig under hela perioden. Den har offrat en del redundans för tillgänglighet.

Figur 16. Kön förblir otillgänglig under synkronisering

Efter två timmar blir kö A också tillgänglig och kan återigen börja ta emot läs- och skrivoperationer.

Uppdateringar

Detta blockerande beteende under synkronisering försvårar uppdatering av kluster med mycket stora köer. Vid något tillfälle måste noden med master startas om, vilket innebär antingen en övergång till spegeln eller avstängning av kön under serveruppdateringen. Om vi väljer att övergå, kommer vi att förlora meddelanden om speglarna inte är synkroniserade. Som standard görs inte övergången till en osynkroniserad spegel när broker stängs av. Det innebär att så snart broker återkommer, förlorar vi inga meddelanden, den enda kostnaden var stilleståndet för kön. Beteendereglerna för avstängning av broker definieras av policyn ha-promote-on-shutdown. Ett av två värden kan sättas:

• always= aktivera övergång till osynkroniserade speglar
• when-synced= övergång endast till synkroniserad spegel, annars blir kön otillgänglig för läsning och skrivning. Kön återgår i drift så snart broker återkommer

Oavsett vilket måste man välja mellan databasförlust och otillgänglighet med stora köer.

När tillgänglighet ökar, ökar dataskyddet

Innan man fattar ett beslut bör man ta hänsyn till en annan komplikation. Även om automatisk synkronisering är bättre för redundans, hur påverkar det dataskyddet? Självklart, med bättre redundans är RabbitMQ mindre benäget att förlora befintliga meddelanden, men vad händer med nya meddelanden från publicerare?

Här måste följande beaktas:

• Kan en publicist bara returnera ett fel, och kan den överordnade tjänsten eller användaren försöka igen senare?
• Kan en publicist spara meddelandet lokalt eller i databasen för att försöka igen senare?

Om publicisten bara kan kassera meddelandet, så förbättrar faktiskt ökad tillgänglighet även datasekretessen.

Således måste man söka en balans, och lösningen beror på den specifika situationen.

Problem med ha-promote-on-failure=when-synced

Tanken ha-promote-on-failure= when-synced innebär att vi förhindrar växling till ett osynkroniserat spegel och därmed undviker databasförlust. Kön förblir otillgänglig för läsning eller skrivning. Istället försöker vi återfå den kraschade brokern med oskadd data, så att den kan återuppta sin funktion som master utan dataförlust.

Men (och det är ett stort men) om brokern har förlorat sina data har vi ett stort problem: kön har försvunnit! All data är borta! Även om du har speglar som huvudsakligen följer huvudkön, kastas även dessa speglar bort.

För att lägga tillbaka noden med samma namn, ber vi klustret att glömma den borttappade noden (med kommandot rabbitmqctl forget_cluster_node) och starta en ny broker med samma värdnamn. Så länge klustret minns den borttappade noden, minns det den gamla kön och osynkroniserade speglar. När klustret ber att glömma den borttappade noden, glöms också denna kö bort. Nu måste vi deklarera om den. Vi har förlorat all data, även om vi hade speglar med ett delvis dataset. Det skulle ha varit bättre att växla till en osynkroniserad spegel!

Därför är manuell synkronisering (och att inte utföra synkronisering) i kombination med ha-promote-on-failure=when-synced, enligt min mening, ganska riskabelt. Dokumenten säger att detta alternativ finns för dataskydd, men det är ett tveeggat svärd.

Ombalansering av master

Som lovat, återvänder vi till problemet med att alla master samlas på en eller flera noder. Detta kan även inträffa som resultat av en "rullande" uppdatering av klustret. I ett kluster med tre noder kommer alla huvudköer att samlas på en eller två noder.

Ombalansering av master kan bli problematiskt av två skäl:

• Det finns inga bra verktyg för att utföra ombalansering
• Kö-synkronisering

För att ombalansera finns det en tredje part plugin, som inte stöds officiellt. Angående tredjepartsplugins i RabbitMQ-handboken står det: «Plugin erbjuder ytterligare anpassnings- och rapporteringsverktyg, men stöds inte och har inte verifierats av RabbitMQ-teamet. Använd på egen risk.»

Det finns en annan trick för att flytta huvudkojan via HA-policyer. Handboken nämner skript detta. Det fungerar på följande sätt:

• Tar bort alla speglingar med en temporär policy med högre prioritet än den befintliga HA-policyn.
• Ändrar den temporära HA-policyn för att använda "noder"-läge med angivande av noden dit huvudkojan ska flyttas.
• Synkroniserar kön för tvångsmigration.
• När migrationen är klar tas den temporära policyn bort. Den ursprungliga HA-policyn träder i kraft och rätt antal speglingar skapas.

Nackdelen är att en sådan metod kanske inte fungerar om du har stora köer eller strikta krav på redundans.

Låt oss nu titta på hur RabbitMQ-kluster fungerar vid nätverksavbrott.

Brytning av sammanhang

Noder i ett distribuerat system är kopplade via nätverkskopplingar, och nätverkskopplingar kan och kommer att kopplas ifrån. Frekvensen av avkopplingar beror på den lokala infrastrukturen eller pålitligheten hos den valda molnleverantören. I alla fall måste distribuerade system kunna hantera dem. Vi står återigen inför valet mellan tillgänglighet och konsekvens, och den goda nyheten är att RabbitMQ erbjuder båda alternativen (men inte samtidigt).

Med RabbitMQ har vi två grundläggande alternativ:

• Tillåta logisk uppdelning (split-brain). Detta säkerställer tillgänglighet, men kan orsaka datakorruption.
• Förbjuda logisk uppdelning. Kan leda till kortvarig förlust av tillgänglighet beroende på hur klienterna ansluter till klustret. Kan också leda till fullständig otillgänglighet i klustret med två noder.

Men vad är logisk uppdelning? Det är när klustret delas i två på grund av förlust av nätverkskopplingar. På varje sida uppgraderas speglingarna till master, så att det i slutänden finns flera masterar för varje kö.

Figur 17. Huvudkö och två spegelkopior, var och en på en separat nod. Sedan uppstår ett nätverksfel, och en spegelkopia separeras. Den separerade noden ser att de två andra har fallit bort och befordrar sina spegelkopior till huvudkopian. Nu har vi två huvudköer, och båda tillåter skrivning och läsning.

Om publicerare skickar data till båda huvudkopiorna, får vi två divergerande kopior av kön.

Olika lägen i RabbitMQ tillhandahåller antingen tillgänglighet eller konsistens.

Ignore-läget (standard)

Detta läge säkerställer tillgänglighet. Efter förlust av anslutning sker en logisk separation. Efter att anslutningen återställs måste administratören bestämma vilken del som ska prioriteras. Den förlorande sidan kommer att startas om, och all ackumulerad data från den sidan går förlorad.

Figur 18. Tre publicerare är kopplade till tre mäklare. Klustret dirigerar internt alla förfrågningar till huvudköen på Mäklare 2.

Nu förlorar vi Mäklare 3. Den ser att de andra mäklarna har fallit bort och befordrar sin spegelkopia till huvudkopian. Så sker en logisk separation.

Figur 19. Logisk separation (split-brain). Skriftliga poster går in i två huvudköer, och två kopior divergerar.

Anslutning återställs, men den logiska separationen kvarstår. Administratören måste manuellt välja den förlorande sidan. I det följande fallet startar administratören om Mäklare 3. Alla meddelanden som den inte hann överföra går förlorade.

Figur 20. Administratören stänger av Mäklare 3.

Figur 21. Administratören startar Mäklare 3, och den ansluter till klustret, och förlorar alla meddelanden som fanns kvar där.

Under förlust av anslutning och efter dess återställning var klustret och denna kö tillgängliga för läsning och skrivning.

Autoheal-läget

Fungerar på liknande sätt som Ignore-läget, förutom att själva klustret automatiskt väljer den förlorande sidan efter separation och återställning av anslutning. Den förlorande sidan återvänder till klustret tom, och kön förlorar alla meddelanden som endast skickades till den sidan.

Pause Minority-läget

Om vi inte vill tillåta logisk partitionering är vårt enda alternativ att avstå från läsning och skrivning på den mindre sidan efter partitionen i klustret. När en broker ser att den är på den mindre sidan pausas den, vilket innebär att alla befintliga anslutningar stängs och alla nya begärningar avslås. En gång per sekund kontrollerar den återställningen av anslutningen. Så snart anslutningen har återställts återupptar den arbetet och ansluter till klustret.

Fig. 22. Tre publicerare är kopplade till tre brokers. Internt riktar klustret alla förfrågningar till huvudköen på Broker 2.

Därefter separeras Broker 1 och 2 från Broker 3. Istället för att uppgradera sin spegel till mästare pausar Broker 3 arbetet och blir otillgänglig.

Fig. 23. Broker 3 pausar arbetet, kopplar bort alla kunder och avvisar anslutningsförfrågningar.

Så snart anslutningen återställs kommer den att återvända till klustret.

Låt oss titta på ett annat exempel där huvudköen befinner sig på Broker 3.

Fig. 24. Huvudköen på Broker 3.

Därefter inträffar samma anslutningsförlust. Broker 3 pausas eftersom den är på den mindre sidan. På den andra sidan ser noderna att Broker 3 har fallit bort, så den äldre spegeln med Brokers 1 och 2 uppgraderas till mästare.

Fig. 25. Övergång till Broker 2 när Broker 3 är otillgänglig.

När anslutningen har återställts kommer Broker 3 att ansluta till klustret.

Fig. 26. Klustret har återvänt till normal drift.

Här är det viktigt att förstå att vi får konsistens, men vi kan också få tillgänglighet, om vi framgångsrikt överför kunder till den större delen av partitionen. För de flesta situationer skulle jag personligen välja läget Pause Minority, men det beror verkligen på det specifika fallet.

För att säkerställa tillgänglighet är det viktigt att se till att kunderna framgångsrikt ansluter till noden. Låt oss överväga våra alternativ.

Säkerställande av klientanslutning

Vi har flera alternativ för hur kunder kan omdirigeras till huvudklustret eller till fungerande noder efter en förlust av anslutning (efter att en nod har kraschat). Låt oss först påminna oss om att varje kö är placerad på en specifik nod, men rutten och policyn replikeras på alla noder. Kunder kan ansluta till vilken nod som helst, och den interna rutten dirigerar dem dit de behöver. Men när en nod är avstängd avvisar den anslutningar, så kunderna måste ansluta till en annan nod. Om en nod kraschar kan den överhuvudtaget inget göra.

Våra alternativ:

• Åtkomst till klustret sker via en lastbalanserare som helt enkelt cykliskt går igenom noderna, medan kunderna gör omanslutningsförsök tills de lyckas. Om en nod inte fungerar eller är avstängd avslutas anslutningsförsöken till den noden misslyckat, men efterföljande försök går till andra servrar (i cyklisk ordning). Detta passar för kortvarig förlust av anslutning eller en kraschad server som snabbt kan återställas.
• Åtkomst till klustret via en lastbalanserare och borttagning av avstängda/kraschat noder från listan så snart de upptäcks. Om detta görs snabbt och om kunderna kan göra omanslutningsförsök så får vi konstant tillgänglighet.
• Ge varje kund en lista över alla noder, och kunden väljer slumpmässigt en av dem vid anslutningen. Om de får ett fel vid anslutningsförsöket går de vidare till nästa nod i listan tills de ansluter.
• Ta bort trafik från den kraschat/avstängda noden med hjälp av DNS. Detta görs med en låg TTL.

Slutsatser

RabbitMQ:s klustring har sina fördelar och nackdelar. De mest allvarliga nackdelarna är att:

• vid anslutning till klustret kastar noder sina data;
• blockerande synkronisering leder till att kön blir otillgänglig.

Alla svåra beslut härrör från dessa två egenskaper hos arkitekturen. Om RabbitMQ kunde spara data vid omkopplingen av klustret, skulle synkroniseringen ske snabbare. Om det hade kapacitet för icke-blockerande synkronisering skulle det bättre kunna stödja stora köer. Att åtgärda dessa två problem skulle allvarligt förbättra RabbitMQ:s prestanda som en fel-tolerant och hög tillgänglig teknik för meddelandehantering. Jag skulle inte våga rekommendera RabbitMQ med klustring i följande situationer:

• Opålitligt nätverk.
• Opålitlig lagring.
• Mycket stora köer.

När det gäller inställningar för hög tillgänglighet, överväga följande:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (eller autoheal)
• beständiga meddelanden
• se till att klienterna ansluter till en aktiv nod när en nod går ner

För konsekvens (datasäkerhet) överväg följande inställningar:

• Publisher Confirms och Manual Acknowledgements på konsumentsidan
• ha-promote-on-failure=when-synced, om utgivarna kan försöka igen senare och om du har en mycket pålitlig lagring! Annars, sätt =always.
• ha-sync-mode=automatic (men för stora inaktiva köer kan det krävas manuell läge; dessutom, fundera på om otillgänglighet kan leda till förlust av meddelanden)
• Pause Minority-läget
• beständiga meddelanden

Vi har ännu inte behandlat alla frågor om fel-tolerans och hög tillgänglighet; till exempel hur man säkert utför administrativa procedurer (såsom glidande uppdateringar). Det behöver även pratas om federering och Shovel-pluginet.

Om jag har missat något, vänligen låt mig veta.

Se även min inlägg, där jag genomför en genomgång av RabbitMQ-klustret med hjälp av Docker och Blockade för att testa några scenarier för meddelandeförlust som beskrivs i denna artikel.

Tidigare artiklar i serien:
Nr 1 — habr.com/ru/company/itsumma/blog/416629
Nr 2 — habr.com/ru/company/itsumma/blog/418389
Nr 3 — habr.com/ru/company/itsumma/blog/437446

Källa: habr.com