Designmönstret Saga hjälper till att upprätthålla datakonsekvens i distribuerade system genom att samordna transaktioner mellan flera tjänster. En saga är en sekvens med lokala transaktioner där varje tjänst utför sin åtgärd och initierar nästa steg genom händelser eller meddelanden. Om ett steg i sekvensen misslyckas utför sagan kompenserande transaktioner för att ångra de slutförda stegen. Den här metoden hjälper till att upprätthålla datakonsekvens.
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.
- Konsekvens: Data övergår från ett giltigt tillstånd till ett annat giltigt tillstånd.
- Isolering: samtidiga transaktioner ger samma resultat som sekventiella transaktioner.
- Hållbarhet: Ändringar kvarstår när de har checkats in, även när fel inträffar.
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:
- Slutför sitt arbete atomiskt inom en enda tjänst.
- Uppdaterar tjänstens databas.
- 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
Compensable-transaktioner kan ångras eller kompenseras av andra transaktioner med motsatt effekt. Om ett steg i sagan misslyckas ångrar kompenserande transaktioner de ändringar som de kompenserbara transaktionerna har gjort.
pivoteringstransaktioner fungera som en punkt utan avkastning i sagan. 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 inkompatibla transaktioner inte kan ångras eller göras om.
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.
Återförsöksbara transaktioner följa pivottransaktionen. Återförsöksbara transaktioner är idempotent 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.
| Fördelar med koreografi | Nackdelar med koreografi |
|---|---|
| Bra för enkla arbetsflöden som har få tjänster och inte behöver någon samordningslogik. | Arbetsflödet kan vara förvirrande när du lägger till nya steg. Det är svårt att spåra vilka kommandon varje sagadeltagare svarar på. |
| Ingen annan tjänst krävs för samordning. | Det finns en risk för cykliskt beroende mellan sagadeltagare eftersom de måste använda varandras kommandon. |
| Introducerar inte en enskild felpunkt eftersom ansvarsområdena fördelas över sagadeltagarna. | Integreringstestning är svårt eftersom alla tjänster måste köras för att simulera en transaktion. |
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.
| Fördelar med orkestrering | Orkestrerings nackdelar |
|---|---|
| Passar bättre för komplexa arbetsflöden eller när du lägger till nya tjänster. | Annan designkomplexitet kräver en implementering av en samordningslogik. |
| Undviker cykliska beroenden eftersom orkestratorn hanterar flödet. | Introducerar en felpunkt eftersom orkestratorn hanterar det fullständiga arbetsflödet. |
| Tydlig ansvarsfördelning förenklar tjänstlogik. |
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ökningssagor: felsökningssagor kan vara komplext, särskilt när antalet deltagande tjänster växer.
Oåterkalleliga lokala databasändringar: Data kan inte återställas eftersom saga-deltagare checkar in ä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 meddelandebearbetning.
Behovet av övervaknings- och spårningssagor: Övervakning och spårning av arbetsflödet för en saga är viktiga uppgifter för att upprätthålla driftstillsyn.
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.
Dirty läser: När en saga eller transaktion läser data som en annan saga har ändrat, men ändringen inte är klar.
Fuzzy, eller icke-repeatable, läser: När olika steg i en saga läser inkonsekventa 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:
semantiklås: Använd lås på programnivå 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 vy: Ordna om sekvensen i sagan så att datauppdateringar sker i återförsöksbara transaktioner för att eliminera smutsiga lä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. Du kan till exempel använda sagor för uppdateringar med låg risk och distribuerade transaktioner för högriskuppdateringar.
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 återställa eller kompensera om någon av åtgärderna 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
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.
Mönstret kretsbrytare hanterar fel som tar en varierande tid att återställa från när du ansluter till en fjärrtjänst eller 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.