Feltolerans och hög tillgänglighet är stora ämnen, så vi kommer att ägna separata artiklar åt RabbitMQ och Kafka. Den här artikeln handlar om RabbitMQ, och nästa handlar om Kafka, i jämförelse med RabbitMQ. Det här är en lång artikel, så gör dig bekväm.

Låt oss titta på feltolerans, konsekvens och hög tillgänglighet (HA) strategier och de avvägningar som varje strategi gör. RabbitMQ kan köras på ett kluster av noder – och klassas då som ett distribuerat system. När det kommer till distribuerade system pratar vi ofta om konsekvens och tillgänglighet.

Dessa begrepp beskriver hur ett system beter sig när det misslyckas. Nätverksanslutningsfel, serverfel, hårddiskfel, servern tillfälligt otillgänglig på grund av sophämtning, paketförlust eller nedgång i nätverksanslutningen. Allt detta kan leda till dataförlust eller konflikter. Det visar sig att det är praktiskt taget omöjligt att sätta upp ett system som är både helt konsekvent (ingen dataförlust, ingen datadivergens) och tillgänglig (kommer att acceptera läsning och skrivning) för alla felscenarier.

Vi kommer att se att konsekvens och tillgänglighet finns i motsatta ändar av spektrumet, och du måste välja vilket sätt att optimera. Den goda nyheten är att med RabbitMQ är detta val möjligt. Du har den här typen av "nördiga" spakar för att flytta balansen mot större konsekvens eller större tillgänglighet.

Vi kommer att ägna särskild uppmärksamhet åt vilka konfigurationer som leder till dataförlust på grund av bekräftade uppgifter. Det finns en ansvarskedja mellan förlag, mäklare och konsumenter. När meddelandet väl har överförts till mäklaren är det hans jobb att inte förlora meddelandet. När mäklaren bekräftar förlagets mottagande av meddelandet räknar vi inte med att det går förlorat. Men vi kommer att se att detta faktiskt kan hända beroende på din mäklare och utgivares konfiguration.

Resiliensprimitiver för en nod

Fjädrande köning/dirigering

Det finns två typer av köer i RabbitMQ: hållbara och icke-hållbara. Alla köer sparas i Mnesia-databasen. Varaktiga köer annonseras om vid nodstart och överlever således omstarter, systemkraschar eller serverkrascher (så länge data finns kvar). Det betyder att så länge du deklarerar routing (utbyte) och kö som motståndskraftiga, kommer kö-/routing-infrastrukturen att komma tillbaka online.

Flyktiga köer och routing tas bort när noden startas om.

Ihållande meddelanden

Bara för att en kö är hållbar betyder det inte att alla dess meddelanden kommer att överleva en omstart av noden. Endast meddelanden som anges av utgivaren som ihållande (beständig). Beständiga meddelanden skapar ytterligare belastning på mäklaren, men om meddelandeförlust är oacceptabelt finns det inget annat alternativ.

Ris. 1. Hållbarhetsmatris

Klustring med köspegling

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

Köspegling:

• en huvudkö (master), som tar emot alla skriv- och läskommandon
• en eller flera speglar som tar emot alla meddelanden och metadata från huvudkön. Dessa speglar är inte till för skalning, utan enbart för redundans.

Ris. 2. Köspegling

Spegling ställs in av lämplig policy. I den kan du välja replikeringskoefficienten och till och med de noder som kön ska placeras på. Exempel:

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

Förlagsbekräftelse

För att uppnå konsekvent inspelning krävs utgivarbekräftelser. Utan dem finns det risk för att meddelanden går förlorade. En bekräftelse skickas till utgivaren efter att meddelandet har skrivits till disken. RabbitMQ skriver meddelanden till disken inte vid mottagandet, utan på en periodisk basis, i området flera hundra millisekunder. När en kö speglas skickas en bekräftelse först efter att alla speglar också har skrivit sin kopia av meddelandet till disken. Detta innebär att användning av bekräftelser ger latens, men om datasäkerhet är viktigt är de nödvändiga.

Failover-kö

När en mäklare avslutar eller kraschar kraschar alla köledare (masters) på den noden tillsammans med den. Klustret väljer sedan den äldsta spegeln för varje master och marknadsför den som den nya mastern.

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

Broker 3 går ner. Observera att Queue C-spegeln på Broker 2 befordras till master. Observera också att en ny spegel har skapats för kö C på mäklare 1. RabbitMQ försöker alltid behålla replikeringsfaktorn som anges i dina policyer.

Ris. 4. Broker 3 misslyckas, vilket gör att kö C misslyckas

Nästa Broker 1 faller! Vi har bara en mäklare kvar. Kö B-spegeln befordras till master.

FIG. 5

Vi har returnerat Broker 1. Oavsett hur väl data överlever förlusten och återställningen av mäklaren, kasseras alla speglade kömeddelanden vid omstart. Detta är viktigt att notera eftersom det kommer att få konsekvenser. Vi kommer att titta på dessa konsekvenser inom kort. Så Broker 1 är nu medlem i klustret igen, och klustret försöker följa policyerna och skapar därför speglar på Broker 1.

I det här fallet var förlusten av Broker 1 fullständig, liksom data, så den ospegelvända kö B gick helt förlorad.

Ris. 6. Mäklare 1 återgår till tjänst

Broker 3 är tillbaka online, så köerna A och B får tillbaka de speglar som skapats på den för att uppfylla deras HA-policyer. Men nu är alla huvudköer på en nod! Detta är inte idealiskt, en jämn fördelning mellan noder är bättre. Tyvärr finns det inte många alternativ här för att återbalansera masters. Vi kommer tillbaka till det här problemet senare eftersom vi måste titta på kösynkronisering först.

Ris. 7. Mäklare 3 återgår till tjänst. Alla huvudköer på en nod!

Så nu borde du ha en uppfattning om hur speglar ger redundans och feltolerans. Detta säkerställer tillgänglighet i händelse av ett enstaka nodfel och skyddar mot dataförlust. Men vi är inte klara än, för i verkligheten är det mycket mer komplicerat.

synkronisering

När du skapar en ny spegel kommer alla nya meddelanden alltid att replikeras till den här spegeln och alla andra. När det gäller befintlig data i masterkön kan vi replikera den till en ny spegel, som blir en komplett kopia av mastern. Vi kan också välja att inte replikera befintliga meddelanden och låta huvudkön och den nya spegeln konvergera i tid, med nya meddelanden som kommer till slutet och befintliga meddelanden lämnar huvudet i huvudkön.

Denna synkronisering utförs automatiskt eller manuellt och hanteras med hjälp av en köpolicy. Låt oss titta på ett exempel.

Vi har två speglade köer. Kö A synkroniseras automatiskt och kö B synkroniseras manuellt. Båda köerna innehåller tio meddelanden.

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

Nu tappar vi Broker 3.

Ris. 9. Mäklare 3 föll

Broker 3 återgår till tjänst. Klustret skapar en spegel för varje kö på den nya noden och synkroniserar automatiskt den nya Kön A med mastern. Spegeln i den nya kö B förblir dock tom. På så sätt har vi full redundans på kö A och endast en spegel för befintliga kö B-meddelanden.

Ris. 10. Den nya spegeln av kö A tar emot alla befintliga meddelanden, men den nya spegeln i kö B gör det inte.

Ytterligare tio meddelanden kommer i båda köerna. Broker 2 kraschar sedan och kö A rullar tillbaka till den äldsta spegeln, som finns på Broker 1. Det finns ingen dataförlust när den misslyckas. I kö B finns det tjugo meddelanden i mastern och bara tio i spegeln eftersom denna kö aldrig replikerade de ursprungliga tio meddelandena.

Ris. 11. Kö A rullar tillbaka till mäklare 1 utan att förlora meddelanden

Ytterligare tio meddelanden kommer i båda köerna. Nu kraschar Broker 1. Kö A växlar enkelt till spegeln utan att tappa meddelanden. Kö B har dock problem. Vid denna tidpunkt kan vi optimera antingen tillgänglighet eller konsekvens.

Om vi ​​vill optimera tillgängligheten så är policyn ha-befordra-på-misslyckande ska installeras i alltid. Detta är standardvärdet, så du kan helt enkelt inte ange policyn alls. I det här fallet tillåter vi i huvudsak fel i osynkroniserade speglar. Detta gör att meddelanden går förlorade, men kön kommer att förbli läsbar och skrivbar.

Ris. 12. Kö A rullas tillbaka till Broker 3 utan att förlora meddelanden. Kö B rullar tillbaka till Broker 3 med tio meddelanden förlorade

Vi kan även installera ha-promote-on-failure till mening when-synced. I det här fallet, istället för att rulla tillbaka till spegeln, väntar kön tills Broker 1 med sina data återgår till online-läge. Efter att den kommit tillbaka är huvudkön tillbaka på Broker 1 utan någon dataförlust. Tillgängligheten offras för datasäkerheten. Men detta är ett riskabelt läge som till och med kan leda till fullständig dataförlust, vilket vi kommer att titta på inom kort.

Ris. 13. Kö B förblir otillgänglig efter att ha förlorat mäklare 1

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

Låt oss titta på ett exempel. Nu har vi väldigt långa köer. Hur kan de växa till en sådan storlek? Av olika anledningar:

• Köer används inte aktivt
• Det är höghastighetsköer och just nu är konsumenterna långsamma
• Det är höghastighetsköer, det har skett ett fel och konsumenterna kommer ikapp

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

Nu faller Broker 3.

Ris. 15. Mäklare 3 faller och lämnar en master och spegel i varje kö

Broker 3 kommer tillbaka online och nya speglar skapas. Huvudkö A börjar replikera befintliga meddelanden till den nya spegeln, och under denna tid är kön inte tillgänglig. Det tar två timmar att replikera data, vilket resulterar i två timmars driftstopp för denna kö!

Kö B förblir dock tillgänglig under hela perioden. Hon offrade en del redundans för tillgänglighet.

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

Efter två timmar blir även kö A tillgänglig och kan börja acceptera läsning och skrivning igen.

Uppdateringar

Detta blockerande beteende under synkronisering gör det svårt att uppdatera kluster med mycket stora köer. Vid något tillfälle måste masternoden startas om, vilket innebär att antingen byta till en spegel eller inaktivera kön medan servern uppgraderas. Om vi ​​väljer att gå över kommer vi att förlora meddelanden om speglarna inte är synkroniserade. Som standard, under ett mäklaravbrott, utförs inte en failover till en osynkroniserad spegel. Det betyder att så fort mäklaren kommer tillbaka så tappar vi inga meddelanden, den enda skadan var en enkel kö. Regler för beteende när en mäklare är frånkopplad bestäms av policy ha-promote-on-shutdown. Du kan ställa in ett av två värden:

• always= övergång till osynkroniserade speglar är aktiverad
• when-synced= övergång till endast en synkroniserad spegel, annars blir kön oläsbar och oskrivbar. Kön återgår till tjänst så snart mäklaren kommer tillbaka

På ett eller annat sätt, med stora köer måste du välja mellan dataförlust och otillgänglighet.

När tillgänglighet förbättrar datasäkerheten

Det finns ytterligare en komplikation att överväga innan du fattar ett beslut. Även om automatisk synkronisering är bättre för redundans, hur påverkar det datasäkerheten? Naturligtvis, med bättre redundans är det mindre troligt att RabbitMQ förlorar befintliga meddelanden, men hur är det med nya meddelanden från utgivare?

Här måste du tänka på följande:

• Kan utgivaren helt enkelt returnera ett fel och låta uppströmstjänsten eller användaren försöka igen senare?
• Kan utgivaren spara meddelandet lokalt eller i en databas för att försöka igen senare?

Om utgivaren bara kan slänga meddelandet, förbättrar förbättring av tillgängligheten faktiskt också datasäkerheten.

En balans måste alltså sökas, och lösningen beror på den specifika situationen.

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

Idé ha-befordra-på-misslyckande= när den synkroniseras är att vi förhindrar byte till en osynkroniserad spegel och därmed undviker dataförlust. Kön förblir oläsbar eller skrivbar. Istället försöker vi återställa den kraschade mäklaren med dess data intakt så att den kan återuppta fungera som en master utan dataförlust.

Men (och detta är ett stort men) om mäklaren har förlorat sin data, då har vi ett stort problem: kön är förlorad! All data är borta! Även om du har speglar som mestadels kommer ikapp huvudkön, så slängs även dessa speglar.

För att lägga till en nod med samma namn igen, säger vi till klustret att glömma den förlorade noden (med kommandot rabbitmqctl forget_cluster_node) och starta en ny mäklare med samma värdnamn. Medan klustret kommer ihåg den förlorade noden, kommer det ihåg den gamla kön och osynkroniserade speglar. När ett kluster blir tillsagt att glömma en föräldralös nod, glöms den kön också. Nu måste vi deklarera det på nytt. Vi förlorade all data, även om vi hade speglar med en ofullständig datauppsättning. Det vore bättre att byta till en icke-synkroniserad spegel!

Därför manuell synkronisering (och underlåtenhet att synkronisera) i kombination med ha-promote-on-failure=when-synced, enligt min mening, ganska riskabelt. Dokumenten säger att det här alternativet finns för datasäkerhet, men det är en tveeggad kniv.

Mästare ombalansering

Som utlovat återgår vi till problemet med ackumuleringen av alla masters på en eller flera noder. Detta kan till och med hända som ett resultat av en rullande klusteruppdatering. I ett kluster med tre noder kommer alla masterköer att samlas på en eller två noder.

Att återbalansera mästare kan vara problematiskt av två anledningar:

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

Det finns en tredje part för ombalansering plugin, som inte stöds officiellt. Angående tredjeparts plugins i RabbitMQ manualen sa: “Pluginet tillhandahåller några ytterligare konfigurations- och rapporteringsverktyg, men stöds eller verifieras inte av RabbitMQ-teamet. Använd på egen risk."

Det finns ett annat knep för att flytta huvudkön genom HA-policyer. Manualen nämner manus för detta. Det fungerar så här:

• Tar bort alla speglar med en tillfällig policy som har högre prioritet än den befintliga HA-policyn.
• Ändrar den tillfälliga HA-policyn för att använda nodläge, och specificerar noden till vilken huvudkön ska överföras.
• Synkroniserar kön för push-migrering.
• När migreringen är klar raderas den tillfälliga policyn. Den ursprungliga HA-policyn träder i kraft och det erforderliga antalet speglar skapas.

Nackdelen är att det här tillvägagångssättet kanske inte fungerar om du har stora köer eller strikta redundanskrav.

Låt oss nu se hur RabbitMQ-kluster fungerar med nätverkspartitioner.

Förlust av anslutning

Noderna i ett distribuerat system är sammankopplade med nätverkslänkar, och nätverkslänkar kan och kommer att kopplas bort. Frekvensen av avbrott beror på den lokala infrastrukturen eller tillförlitligheten hos det valda molnet. Distribuerade system måste i alla fall klara av dem. Återigen har vi ett val mellan tillgänglighet och konsistens, och återigen är den goda nyheten att RabbitMQ erbjuder båda alternativen (bara inte samtidigt).

Med RabbitMQ har vi två huvudalternativ:

• Tillåt logisk division (split-brain). Detta säkerställer tillgänglighet, men kan orsaka dataförlust.
• Inaktivera logisk separation. Kan resultera i kortsiktig förlust av tillgänglighet beroende på hur klienter ansluter till klustret. Kan också leda till fullständig otillgänglighet i ett kluster med två noder.

Men vad är logisk separation? Detta är när ett kluster delas i två på grund av förlust av nätverksanslutningar. På varje sida befordras speglarna till en master, så att det så småningom blir flera masters per tur.

Ris. 17. Huvudkö och två speglar, var och en på en separat nod. Sedan uppstår ett nätverksfel och en spegel lossnar. Den separerade noden ser att de andra två har fallit av och främjar sina speglar till mastern. Vi har nu två huvudköer, både skrivbara och läsbara.

Om publicister skickar data till båda masterna får vi två divergerande kopior av kön.

RabbitMQs olika lägen ger antingen tillgänglighet eller konsekvens.

Ignorera läge (standard)

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

Ris. 18. Tre förlag är knutna till tre mäklare. Internt dirigerar klustret alla förfrågningar till huvudkön på Broker 2.

Nu tappar vi Broker 3. Han ser att andra mäklare har ramlat av och promotar sin spegel till mästaren. Det är så en logisk separation uppstår.

Ris. 19. Logisk division (split-brain). Posterna hamnar i två huvudköer, och de två kopiorna divergerar.

Anslutningen återställs, men logisk separation kvarstår. Administratören måste manuellt välja den förlorande sidan. I fallet nedan startar administratören om Broker 3. Alla meddelanden som han inte lyckades överföra går förlorade.

Ris. 20. Administratören inaktiverar Broker 3.

Ris. 21. Administratören startar Broker 3 och ansluter sig till klustret och förlorar alla meddelanden som lämnats där.

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

Autoheal-läge

Fungerar på samma sätt som Ignore-läget, förutom att klustret självt automatiskt väljer den förlorande sidan efter att ha delat upp och återställt anslutningen. Den förlorande sidan återvänder till klustret tom, och kön förlorar alla meddelanden som skickades endast till den sidan.

Pausa minoritetsläge

Om vi ​​inte vill tillåta logisk partitionering är vårt enda alternativ att kassera läsning och skrivning på den mindre sidan efter klusterpartitionen. När mäklaren ser att den är på den mindre sidan avbryter den arbetet, det vill säga stänger alla befintliga anslutningar och vägrar nya. En gång per sekund söker den efter anslutningsåterställning. När anslutningen är återställd återupptar den driften och ansluter sig till klustret.

Ris. 22. Tre förlag är knutna till tre mäklare. Internt dirigerar klustret alla förfrågningar till huvudkön på Broker 2.

Mäklare 1 och 2 splittrades sedan från Broker 3. Istället för att marknadsföra sin spegel för att bemästra, avbryts Broker 3 och blir otillgänglig.

Ris. 23. Broker 3 pausar, kopplar bort alla klienter och avvisar anslutningsförfrågningar.

När anslutningen är återställd återgår den till klustret.

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

Ris. 24. Huvudkö på Broker 3.

Då inträffar samma förlust av anslutning. Mäklare 3 pausar för att den är på den mindre sidan. På andra sidan ser noderna att Broker 3 har ramlat av, så den äldre spegeln från Brokers 1 och 2 befordras till master.

Ris. 25. Övergång till Broker 2 om Broker 3 inte är tillgänglig.

När anslutningen är återställd kommer Broker 3 att gå med i klustret.

Ris. 26. Klustret har återgått till normal drift.

Det viktiga att förstå här är att vi får konsekvens, men vi kan också få tillgänglighet, om Vi kommer framgångsrikt att överföra kunder till större delen av sektionen. För de flesta situationer skulle jag personligen välja Pause Minority-läget, men det beror verkligen på det enskilda fallet.

För att säkerställa tillgänglighet är det viktigt att säkerställa att klienter lyckas ansluta till värden. Låt oss titta på våra alternativ.

Säkerställa kundanslutning

Vi har flera alternativ för hur man dirigerar klienter till huvuddelen av klustret eller till fungerande noder (efter att en nod misslyckats) efter en förlust av anslutning. Låt oss först komma ihåg att en specifik kö finns på en specifik nod, men routing och policyer replikeras över alla noder. Klienter kan ansluta till vilken nod som helst, och intern routing leder dem dit de behöver gå. Men när en nod är avstängd, avvisar den anslutningar, så klienter måste ansluta till en annan nod. Om noden faller av finns det lite han kan göra alls.

Våra alternativ:

• Klustret nås med hjälp av en lastbalanserare som helt enkelt cyklar genom noderna och klienter försöker ansluta igen tills de lyckas. Om en nod är nere eller avstängd, kommer försök att ansluta till den noden att misslyckas, men efterföljande försök kommer att gå till andra servrar (på ett round-robin-sätt). Detta är lämpligt för en kortvarig förlust av anslutning eller en nedstängd server som snabbt kommer att tas upp igen.
• Få åtkomst till klustret genom en lastbalanserare och ta bort avstängda/misslyckade noder från listan så snart de upptäcks. Om vi ​​gör detta snabbt, och om klienter kan prova anslutningen igen, kommer vi att uppnå konstant tillgänglighet.
• Ge varje klient en lista över alla noder, och klienten väljer slumpmässigt en av dem när han ansluter. Om den får ett felmeddelande när den försöker ansluta, flyttar den till nästa nod i listan tills den ansluter.
• Ta bort trafik från en misslyckad/avstängd nod med DNS. Detta görs med en liten TTL.

Resultat

RabbitMQ-klustring har sina fördelar och nackdelar. De allvarligaste nackdelarna är att:

• när de går med i ett kluster kasserar noder sina data;
• blockering av synkronisering gör att kön blir otillgänglig.

Alla svåra beslut härrör från dessa två arkitektoniska egenskaper. Om RabbitMQ kunde spara data när klustret återförenas, skulle synkroniseringen gå snabbare. Om den hade förmåga till icke-blockerande synkronisering, skulle den bättre stödja stora köer. Att åtgärda dessa två problem skulle avsevärt förbättra RabbitMQs prestanda som en feltolerant och högtillgänglig meddelandeteknik. Jag skulle vara tveksam till att rekommendera RabbitMQ med klustring i följande situationer:

• Otillförlitligt nätverk.
• Otillförlitlig lagring.
• Väldigt långa köer.

Tänk på följande när det gäller inställningar för hög tillgänglighet:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (eller autoheal)
• ihållande meddelanden
• se till att klienter ansluter till den aktiva noden när någon nod misslyckas

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

• Publisher bekräftar och manuella erkännanden på konsumentsidan
• ha-promote-on-failure=when-synced, om förlagen kan försöka igen senare och om du har mycket tillförlitlig lagring! Annars sätt =always.
• ha-sync-mode=automatic (men för stora inaktiva köer kan manuellt läge krävas; överväg också om otillgänglighet kommer att göra att meddelanden går förlorade)
• Pausa minoritetsläge
• ihållande meddelanden

Vi har inte täckt alla frågor om feltolerans och hög tillgänglighet ännu; till exempel hur man säkert utför administrativa procedurer (som rullande uppdateringar). Vi måste också prata om federation och Shovel-plugin.

Om jag har missat något mer, vänligen meddela mig.

Se även min post, där jag utför en förödelse på ett RabbitMQ-kluster med Docker och Blockade för att testa några av de scenarier för meddelandeförlust som beskrivs i den här artikeln.

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: will.com