Saga-mönster för distribuerade transaktioner

Upprätthålla datakonsekvens i distribuerade system genom att samordna en sekvens med lokala transaktioner mellan flera tjänster. Varje tjänst utför sin åtgärd och utlöser nästa steg genom händelser eller meddelanden. Om ett steg misslyckas ångras de ändringar som de slutförda stegen har gjort i en serie kompenserande transaktioner.

Kontext och problem

En transaktion representerar en arbetsenhet som kan innehålla flera åtgärder. I en transaktion refererar en händelse till en tillståndsändring som påverkar en entitet. Ett -kommando kapslar in all information som behövs för att utföra en åtgärd eller utlösa en efterföljande händelse.

Transaktioner måste följa principerna om atomitet, konsekvens, isolering och hållbarhet (ACID).

• Atomicity: Alla åtgärder lyckas eller inga åtgärder lyckas.
• Konsistens: Data övergår från ett giltigt tillstånd till ett annat giltigt tillstånd.
• Isolering: samtidiga transaktioner ger samma resultat som sekventiella transaktioner.
• Varaktighet: Ändringar kvarstår efter att de har bekräftats, även om fel uppstår.

I en enda tjänst följer transaktioner ACID-principer eftersom de fungerar i en enda databas. Det kan dock vara mer komplext att uppnå ACID-efterlevnad för flera tjänster.

Utmaningar i mikrotjänstarkitekturer

Mikrotjänstarkitekturer tilldelar vanligtvis en dedikerad databas till varje mikrotjänst. Den här metoden ger flera fördelar:

• Varje tjänst kapslar in sina egna data.
• Varje tjänst kan använda den lämpligaste databastekniken och schemat för sina specifika behov.
• Databaser för varje tjänst kan skalas separat.
• Fel i en tjänst är isolerade från andra tjänster.

Trots dessa fördelar komplicerar den här arkitekturen datakonsekvens mellan tjänster. Traditionella databasgarantier som ACID gäller inte direkt för flera oberoende hanterade datalager. På grund av dessa begränsningar passar arkitekturer som förlitar sig på kommunikation mellan processer eller traditionella transaktionsmodeller som tvåfas incheckningsprotokoll ofta bättre för Saga-mönstret.

Lösning

Saga-mönstret hanterar transaktioner genom att dela upp dem i en sekvens med lokala transaktioner.

Varje lokal transaktion:

1. Slutför sitt arbete atomiskt inom en enda tjänst.
2. Uppdaterar tjänstens databas.
3. Initierar nästa transaktion via en händelse eller ett meddelande.

Om en lokal transaktion misslyckas utför sagan en serie kompenserande transaktioner för att återställa de ändringar som de föregående lokala transaktionerna gjorde.

Viktiga begrepp i Saga-mönstret

• Kompenserbara transaktioner kan ångras eller kompenseras genom andra transaktioner med motsatt effekt. Om ett steg i sagan misslyckas ångrar kompenserande transaktioner de ändringar som de kompenserbara transaktionerna har gjort.

• Pivottransaktioner fungerar som punkten utan återvändo i förloppet. När en pivottransaktion har slutförts är kompenserbara transaktioner inte längre relevanta. Alla efterföljande åtgärder måste slutföras för att systemet ska uppnå ett konsekvent slutligt tillstånd. En pivottransaktion kan anta olika roller, beroende på flödet i sagan:

  • Oåterkalleliga eller icke kompenserbara transaktioner kan inte ångras eller försökas igen.

  • Gränsen mellan reversibel och bekräftad innebär att pivottransaktionen kan vara den sista ångrabara eller kompenserbara transaktionen. Eller så kan det vara den första återförsöksbara åtgärden i sagan.

• Transaktioner som kan göras om följer pivottransaktionen. Återförsöksbara transaktioner är idempotenta och hjälper till att säkerställa att sagan kan nå sitt slutliga tillstånd, även om tillfälliga fel inträffar. De hjälper sagan att så småningom uppnå ett konsekvent tillstånd.

Saga-implementeringsmetoder

De två typiska metoderna för sagaimplementering är koreografi och orkestrering. Varje metod har en egen uppsättning utmaningar och tekniker för att samordna arbetsflödet.

Koreografi

I koreografimetoden utbyter tjänster händelser utan en centraliserad kontrollant. Med koreografi publicerar varje lokal transaktion domänhändelser som utlöser lokala transaktioner i andra tjänster.

Orkestrering

I orkestrering hanterar en centraliserad styrenhet, eller orchestrator, alla transaktioner och talar om för deltagarna vilken åtgärd som ska utföras baserat på händelser. Orkestratorn utför saga-begäranden, lagrar och tolkar tillstånden för varje uppgift och hanterar återställning av fel med hjälp av kompenserande transaktioner.

Problem och överväganden

Tänk på följande när du bestämmer hur du ska implementera det här mönstret:

• Förändring i designtänkande: Att anta Saga-mönstret kräver ett annat tänkesätt. Det kräver att du fokuserar på transaktionssamordning och datakonsekvens mellan flera mikrotjänster.

• Komplexiteten i felsökning av sagor: Att felsöka sagor kan vara komplext, särskilt när antalet deltagande tjänster ökar.

• Irreversibla lokala databasändringar: Data kan inte rullas tillbaka eftersom deltagarna i sagan genomför ändringar i sina respektive databaser.

• Hantering av tillfälliga fel och idempotens: Systemet måste hantera tillfälliga fel effektivt och säkerställa idempotens när samma åtgärd upprepas ändrar inte resultatet. Mer information finns i Idempotent Konsumentmönster.

• Behovet av att övervaka och spåra sagor: Att övervaka och spåra en sagas arbetsflöde är väsentliga uppgifter för att upprätthålla operativ överblick.

• Begränsningar för kompenserande transaktioner: Kompenserande transaktioner kanske inte alltid lyckas, vilket kan göra systemet inkonsekvent.

Potentiella dataavvikelser i sagor

Dataavvikelser är inkonsekvenser som kan uppstå när sagas fungerar i flera tjänster. Eftersom varje tjänst hanterar sina egna data, som kallas deltagardata, finns det ingen inbyggd isolering mellan tjänster. Den här konfigurationen kan resultera i datainkonsekvenser eller hållbarhetsproblem, till exempel delvis tillämpade uppdateringar eller konflikter mellan tjänster. Vanliga problem är:

• Förlorade uppdateringar: När en saga ändrar data utan att överväga ändringar som gjorts av en annan saga, resulterar det i överskrivna eller saknade uppdateringar.

• Smutsiga läsningar: När en saga eller transaktion läser data som en annan saga har ändrat, men ändringen inte är slutförd.

• Suddiga eller icke-repeterbara läsningar: När olika steg i en saga läser inkonsistenta data eftersom uppdateringar sker mellan läsningarna.

Strategier för att hantera dataavvikelser

Om du vill minska eller förhindra dessa avvikelser bör du överväga följande motåtgärder:

• Semantiskt lås: Använd lås på applikationsnivå när en sagas kompenserbara transaktion använder en semafor för att indikera att en uppdatering pågår.

• Kommutativa uppdateringar: Designuppdateringar så att de kan tillämpas i valfri ordning samtidigt som samma resultat skapas. Den här metoden hjälper till att minska konflikterna mellan sagor.

• Pessimistisk syn: Ändra ordningsföljden i sagan så att datauppdateringar sker i transaktioner som kan köras om för att eliminera smutsläsningar. Annars kan en saga läsa felaktiga data eller icke-bakåtkompatibla ändringar, medan en annan saga samtidigt utför en kompenserbar transaktion för att återställa uppdateringarna.

• Läsa om värden: Bekräfta att data förblir oförändrade innan du gör uppdateringar. Om data ändras stoppar du det aktuella steget och startar om sagan efter behov.

• Versionsfiler: Underhålla en logg över alla åtgärder som utförs på en post och se till att de utförs i rätt ordning för att förhindra konflikter.

• Riskbaserad samtidighet baserat på värde: dynamiskt välja lämplig samtidighetsmekanism baserat på den potentiella affärsrisken. Använd till exempel sagamönster för uppdateringar med låg risk och distribuerade transaktioner för uppdateringar med hög risk.

När du ska använda det här mönstret

Använd det här mönstret när:

• Du måste säkerställa datakonsekvens i ett distribuerat system utan nära koppling.
• Du måste rulla tillbaka eller kompensera om en av operationerna i sekvensen misslyckas.

Det här mönstret kanske inte är lämpligt när:

• Transaktionerna är nära kopplade.
• Kompenserande transaktioner sker hos tidigare deltagare.
• Det finns cykliska beroenden.

Nästa steg

• molnbaserade datamönster

Relaterade resurser

Följande mönster kan vara relevanta när du implementerar det här mönstret:

• Det koreografimönstret har varje komponent i systemet som deltar i beslutsprocessen om arbetsflödet för en affärstransaktion, i stället för att förlita sig på en central kontrollpunkt.

• Mönstret kompenserande transaktion ångrar arbete som utförs av en serie steg och definierar slutligen en konsekvent åtgärd om ett eller flera steg misslyckas. Molnbaserade program som implementerar komplexa affärsprocesser och arbetsflöden följer ofta den här eventuell konsekvensmodell.

• Mönstret Försök igen låter ett program hantera tillfälliga fel när det försöker ansluta till en tjänst eller nätverksresurs genom att transparent försöka utföra den misslyckade åtgärden igen. Det här mönstret kan förbättra programmets stabilitet.

• Circuit Breaker-mönstret hanterar fel som tar olika lång tid att återhämta sig från när du ansluter till en fjärrtjänst eller en resurs. Det här mönstret kan förbättra ett programs stabilitet och återhämtning.

• Mönstret hälsoslutpunktsövervakning implementerar funktionella kontroller i ett program som externa verktyg kan komma åt via exponerade slutpunkter med jämna mellanrum. Det här mönstret kan hjälpa dig att kontrollera att program och tjänster fungerar korrekt.