Saga-patroon voor gedistribueerde transacties

Azure

Behoud gegevensconsistentie in gedistribueerde systemen door een reeks lokale transacties over meerdere services te coördineren. Elke service voert de bewerking uit en activeert de volgende stap door gebeurtenissen of berichten. Als een stap mislukt, maakt een reeks compenserende transacties de wijzigingen ongedaan die de voltooide stappen hebben aangebracht.

Context en probleem

Een transactie vertegenwoordigt een werkeenheid, die meerdere bewerkingen kan bevatten. Binnen een transactie verwijst een gebeurtenis naar een statuswijziging die van invloed is op een entiteit. Een opdracht bevat alle informatie die nodig is om een actie uit te voeren of een volgende gebeurtenis te activeren.

Transacties moeten voldoen aan de principes van atomiciteit, consistentie, isolatie en duurzaamheid (ACID).

• Atomiciteit: alle bewerkingen slagen of niet.
• consistentie: gegevens worden van de ene geldige status naar een andere geldige status overgestapt.
• Isolatie: Gelijktijdige transacties leveren dezelfde resultaten op als opeenvolgende transacties.
• Duurzaamheid: wijzigingen blijven behouden nadat ze zijn doorgevoerd, zelfs wanneer er fouten optreden.

In één service volgen transacties ACID-principes omdat ze binnen één database werken. Het kan echter complexer zijn om ACID-naleving te bereiken voor meerdere services.

Uitdagingen in microservicesarchitecturen

Microservicesarchitecturen wijzen doorgaans een toegewezen database toe aan elke microservice-. Deze aanpak biedt verschillende voordelen:

• Elke service bevat zijn eigen gegevens.
• Elke service kan gebruikmaken van de meest geschikte databasetechnologie en het schema voor de specifieke behoeften.
• Databases voor elke service kunnen onafhankelijk worden geschaald.
• Fouten in de ene service worden geïsoleerd van andere services.

Ondanks deze voordelen maakt deze architectuur de consistentie van gegevens in meerdere services ingewikkeld. Traditionele databasegaranties zoals ACID zijn niet rechtstreeks van toepassing op meerdere onafhankelijk beheerde gegevensarchieven. Vanwege deze beperkingen zijn architecturen die afhankelijk zijn van communicatie tussen processen of traditionele transactiemodellen, zoals protocol voor doorvoeren in twee fasen, vaak beter geschikt voor het Saga-patroon.

Oplossing

Het Saga-patroon beheert transacties door ze op te breken in een reeks lokale transacties.

Elke lokale transactie:

1. Voert zijn werk atomisch uit binnen een enkele service.
2. Hiermee wordt de database van de service bijgewerkt.
3. Start de volgende transactie via een gebeurtenis of bericht.

Als een lokale transactie mislukt, voert de saga een reeks compenserende transacties uit om de wijzigingen die de voorgaande lokale transacties hebben aangebracht, om te keren.

Belangrijkste concepten in het Saga-patroon

• Compenseerbare transacties kunnen ongedaan worden gemaakt of worden gecompenseerd door andere transacties met een tegengesteld effect. Als een stap in de saga mislukt, maken compenserende transacties de wijzigingen ongedaan die de compenserende transacties hebben aangebracht.

• Spiltransacties vormen het punt waarop er in het verhaal geen weg terug meer is. Nadat een draaitransactie is geslaagd, zijn compenserende transacties niet meer relevant. Alle volgende acties moeten worden voltooid voor het systeem om een consistente eindstatus te bereiken. Een spiltransactie kan verschillende rollen aannemen, afhankelijk van het verloop van de saga:

  • Onomkeerbare of niet-compenseerbare transacties kunnen niet ongedaan worden gemaakt of opnieuw worden uitgevoerd.

  • De grens tussen omkeerbare en doorgevoerde houdt in dat de scharniertransactie de laatste transactie kan zijn die ongedaan kan worden gemaakt of gecompenseerd. Of het kan de eerste nieuwe poging in de saga zijn.

• Opnieuw uitvoerbare transacties volgen op de spiltransactie. Transacties die opnieuw kunnen worden uitgevoerd, zijn idempotent en helpen ervoor te zorgen dat de saga de eindstatus kan bereiken, zelfs als er tijdelijke fouten optreden. Ze helpen de saga uiteindelijk een consistente toestand te bereiken.

Saga-implementatiemethoden

De twee typische saga-implementatiemethoden zijn choreografie en orchestration. Elke benadering heeft een eigen set uitdagingen en technologieën om de werkstroom te coördineren.

Choreografie

In de choreografiebenadering wisselen diensten gebeurtenissen uit zonder gecentraliseerde controller. Met choreografie publiceert elke lokale transactie domeingebeurtenissen die lokale transacties in andere services activeren.

Voordelen van choreografie	Nadelen van choreografie
Geschikt voor eenvoudige werkstromen die weinig services hebben en geen coördinatielogica nodig hebben.	Werkstroom kan verwarrend zijn wanneer u nieuwe stappen toevoegt. Het is moeilijk om bij te houden op welke opdrachten elke saga deelnemer reageert.
Er is geen andere service vereist voor coördinatie.	Er bestaat een risico op cyclische afhankelijkheid tussen saga-deelnemers, omdat ze elkaars opdrachten moeten gebruiken.
Veroorzaakt geen enkel storingspunt omdat de verantwoordelijkheden over de saga-deelnemers zijn verdeeld.	Integratietests zijn moeilijk omdat alle services moeten worden uitgevoerd om een transactie te simuleren.

Orkestratie

Bij orkestratie verwerkt een gecentraliseerde controller, of orchestrator, alle transacties en vertelt deze de deelnemers welke operatie ze op basis van gebeurtenissen moeten uitvoeren. De orchestrator voert saga-aanvragen uit, slaat en interpreteert de statussen van elke taak en verwerkt foutherstel met behulp van compenserende transacties.

Voordelen van orkestratie	Nadelen van orkestratie
Beter geschikt voor complexe werkstromen of wanneer u nieuwe services toevoegt.	Andere ontwerpcomplexiteit vereist een implementatie van een coördinatielogica.
Vermijd cyclische afhankelijkheden omdat de orchestrator de stroom beheert.	Introduceert een foutpunt omdat de orchestrator de volledige werkstroom beheert.
Duidelijke scheiding van verantwoordelijkheden vereenvoudigt servicelogica.

Problemen en overwegingen

Houd rekening met de volgende punten wanneer u besluit hoe u dit patroon implementeert:

• Verschuiving in het ontwerpdenken: Het toepassen van het Saga-patroon vereist een andere denkwijze. Hiervoor moet u zich richten op transactiecoördinatie en gegevensconsistentie tussen meerdere microservices.

• Complexiteit van foutopsporingssages: Debugging-saga's kunnen complex zijn, met name naarmate het aantal deelnemende services groeit.

• Onomkeerbare wijzigingen in de lokale database: Gegevens kunnen niet ongedaan worden gemaakt omdat sagadeelnemers wijzigingen vastleggen in hun respectieve databases.

• Afhandeling van tijdelijke fouten en idempotentie: Het systeem moet tijdelijke fouten effectief afhandelen en idempotentie garanderen wanneer dezelfde bewerking wordt herhaald, verandert het resultaat niet. Zie Idempotent message processingvoor meer informatie.

• Noodzaak van het monitoren en volgen van saga's: Het monitoren en volgen van de workflow van een saga zijn essentiële taken om het operationele overzicht te behouden.

• Beperkingen van compenserende transacties: Compenserende transacties slagen mogelijk niet altijd, waardoor het systeem in een inconsistente toestand kan blijven.

Mogelijke gegevensafwijkingen in saga's

Gegevensafwijkingen zijn inconsistenties die kunnen optreden wanneer saga's over meerdere services heen actief zijn. Omdat elke service zijn eigen gegevens beheert, genaamd gegevens van deelnemers, is er geen ingebouwde isolatie tussen services. Deze installatie kan leiden tot inconsistenties van gegevens of duurzaamheidsproblemen, zoals gedeeltelijk toegepaste updates of conflicten tussen services. Veelvoorkomende problemen zijn:

• Verloren updates: Wanneer een saga gegevens wijzigt zonder rekening te houden met wijzigingen die door een andere saga zijn aangebracht, resulteert dit in overschreven of ontbrekende updates.

• Dirty reads: Wanneer een saga of transactie gegevens leest die een andere saga heeft gewijzigd, maar de wijziging nog niet is voltooid.

• Fuzzy, of niet-herhaalbare, leesbewerkingen: Wanneer verschillende stappen in een saga inconsistente gegevens lezen doordat er tussen de leesbewerkingen updates plaatsvinden.

Strategieën voor het aanpakken van gegevensafwijkingen

Als u deze afwijkingen wilt verminderen of voorkomen, kunt u de volgende tegenmaatregelen overwegen:

• Semantische vergrendeling: Gebruik vergrendelingen op applicatieniveau wanneer een compenseerbare transactie van een saga een semafoor gebruikt om aan te geven dat er een update wordt uitgevoerd.

• commutatieve updates: Ontwerpupdates, zodat ze in elke volgorde kunnen worden toegepast terwijl hetzelfde resultaat wordt geproduceerd. Deze aanpak helpt conflicten tussen saga's te verminderen.

• pessimistische weergave: de volgorde van de saga opnieuw ordenen, zodat gegevensupdates plaatsvinden in opnieuw te proberen transacties om vuile leesbewerkingen te elimineren. Anders kan één saga vuile gegevens lezen of niet-doorgevoerde wijzigingen, terwijl een andere saga tegelijkertijd een compenserende transactie uitvoert om de updates terug te draaien.

• Waarden voor opnieuw lezen: bevestig dat de gegevens ongewijzigd blijven voordat u updates uitvoert. Als de gegevens veranderen, stopt u de huidige stap en start u de saga zo nodig opnieuw op.

• versiebestanden: een logboek bijhouden van alle bewerkingen die worden uitgevoerd op een record en ervoor zorgen dat ze in de juiste volgorde worden uitgevoerd om conflicten te voorkomen.

• op risico gebaseerde gelijktijdigheid op basis van waarde: kies dynamisch het juiste gelijktijdigheidsmechanisme op basis van het potentiële bedrijfsrisico. Gebruik bijvoorbeeld saga's voor updates met een laag risico en gedistribueerde transacties voor updates met een hoog risico.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer:

• U moet zorgen voor gegevensconsistentie in een gedistribueerd systeem zonder strakke koppeling.
• U moet terugdraaien of compenseren als een van de bewerkingen in de reeks mislukt.

Dit patroon is mogelijk niet geschikt wanneer:

• Transacties zijn nauw gekoppeld.
• Compenserende transacties vinden plaats in eerdere deelnemers.
• Er zijn cyclische afhankelijkheden.

Volgende stap

• cloudeigen gegevenspatronen

Gerelateerde resources

De volgende patronen zijn mogelijk relevant wanneer u dit patroon implementeert:

• Het Choreografiepatroon laat elk onderdeel van het systeem deelnemen aan het besluitvormingsproces over de workflow van een bedrijfstransactie, in plaats van te vertrouwen op een centraal besturingspunt.

• Het patroon voor compenserende transacties maakt werk ongedaan dat door een reeks stappen is uitgevoerd, en zorgt er uiteindelijk voor dat een consistente bewerking wordt gedefinieerd als een of meer stappen mislukken. In de cloud gehoste toepassingen die complexe bedrijfsprocessen en werkstromen implementeren, volgen vaak dit uiteindelijke consistentiemodel.

• Met het opnieuw proberen-patroon kan een toepassing tijdelijke fouten afhandelen wanneer deze verbinding probeert te maken met een service of netwerkbron, door de mislukte bewerking transparant opnieuw te proberen. Dit patroon kan de stabiliteit van de toepassing verbeteren.

• Het patroon circuitonderbreker verwerkt fouten die een variabele hoeveelheid tijd in beslag nemen om van te herstellen, wanneer u verbinding maakt met een externe service of resource. Dit patroon kan de stabiliteit en tolerantie van een toepassing verbeteren.

• Het patroon Health Endpoint Monitoring implementeert functionele controles in een toepassing waartoe externe hulpprogramma's met regelmatige tussenpozen toegang hebben via weergegeven eindpunten. Met dit patroon kunt u controleren of toepassingen en services correct presteren.

Behoud gegevensconsistentie in gedistribueerde systemen door een reeks lokale transacties over meerdere services te coördineren. Elke service voert de bewerking uit en activeert de volgende stap door gebeurtenissen of berichten. Als een stap mislukt, maakt een reeks compenserende transacties de wijzigingen ongedaan die de voltooide stappen hebben aangebracht.

Context en probleem

Een transactie vertegenwoordigt een werkeenheid, die meerdere bewerkingen kan bevatten. Binnen een transactie verwijst een gebeurtenis naar een statuswijziging die van invloed is op een entiteit. Een opdracht bevat alle informatie die nodig is om een actie uit te voeren of een volgende gebeurtenis te activeren.

Transacties moeten voldoen aan de principes van atomiciteit, consistentie, isolatie en duurzaamheid (ACID).

• Atomiciteit: alle bewerkingen slagen of niet.
• consistentie: gegevens worden van de ene geldige status naar een andere geldige status overgestapt.
• Isolatie: Gelijktijdige transacties leveren dezelfde resultaten op als opeenvolgende transacties.
• Duurzaamheid: wijzigingen blijven behouden nadat ze zijn doorgevoerd, zelfs wanneer er fouten optreden.

In één service volgen transacties ACID-principes omdat ze binnen één database werken. Het kan echter complexer zijn om ACID-naleving te bereiken voor meerdere services.

Uitdagingen in microservicesarchitecturen

Microservicesarchitecturen wijzen doorgaans een toegewezen database toe aan elke microservice-. Deze aanpak biedt verschillende voordelen:

• Elke service bevat zijn eigen gegevens.
• Elke service kan gebruikmaken van de meest geschikte databasetechnologie en het schema voor de specifieke behoeften.
• Databases voor elke service kunnen onafhankelijk worden geschaald.
• Fouten in de ene service worden geïsoleerd van andere services.

Ondanks deze voordelen maakt deze architectuur de consistentie van gegevens in meerdere services ingewikkeld. Traditionele databasegaranties zoals ACID zijn niet rechtstreeks van toepassing op meerdere onafhankelijk beheerde gegevensarchieven. Vanwege deze beperkingen zijn architecturen die afhankelijk zijn van communicatie tussen processen of traditionele transactiemodellen, zoals protocol voor doorvoeren in twee fasen, vaak beter geschikt voor het Saga-patroon.

Oplossing

Het Saga-patroon beheert transacties door ze op te breken in een reeks lokale transacties.

Elke lokale transactie:

1. Voert zijn werk atomisch uit binnen een enkele service.
2. Hiermee wordt de database van de service bijgewerkt.
3. Start de volgende transactie via een gebeurtenis of bericht.

Als een lokale transactie mislukt, voert de saga een reeks compenserende transacties uit om de wijzigingen die de voorgaande lokale transacties hebben aangebracht, om te keren.

Belangrijkste concepten in het Saga-patroon

• Compenseerbare transacties kunnen ongedaan worden gemaakt of worden gecompenseerd door andere transacties met een tegengesteld effect. Als een stap in de saga mislukt, maken compenserende transacties de wijzigingen ongedaan die de compenserende transacties hebben aangebracht.

• Spiltransacties vormen het punt waarop er in het verhaal geen weg terug meer is. Nadat een draaitransactie is geslaagd, zijn compenserende transacties niet meer relevant. Alle volgende acties moeten worden voltooid voor het systeem om een consistente eindstatus te bereiken. Een spiltransactie kan verschillende rollen aannemen, afhankelijk van het verloop van de saga:

  • Onomkeerbare of niet-compenseerbare transacties kunnen niet ongedaan worden gemaakt of opnieuw worden uitgevoerd.

  • De grens tussen omkeerbare en doorgevoerde houdt in dat de scharniertransactie de laatste transactie kan zijn die ongedaan kan worden gemaakt of gecompenseerd. Of het kan de eerste nieuwe poging in de saga zijn.

• Opnieuw uitvoerbare transacties volgen op de spiltransactie. Transacties die opnieuw kunnen worden uitgevoerd, zijn idempotent en helpen ervoor te zorgen dat de saga de eindstatus kan bereiken, zelfs als er tijdelijke fouten optreden. Ze helpen de saga uiteindelijk een consistente toestand te bereiken.

Saga-implementatiemethoden

De twee typische saga-implementatiemethoden zijn choreografie en orchestration. Elke benadering heeft een eigen set uitdagingen en technologieën om de werkstroom te coördineren.

Choreografie

In de choreografiebenadering wisselen diensten gebeurtenissen uit zonder gecentraliseerde controller. Met choreografie publiceert elke lokale transactie domeingebeurtenissen die lokale transacties in andere services activeren.

Voordelen van choreografie	Nadelen van choreografie
Geschikt voor eenvoudige werkstromen die weinig services hebben en geen coördinatielogica nodig hebben.	Werkstroom kan verwarrend zijn wanneer u nieuwe stappen toevoegt. Het is moeilijk om bij te houden op welke opdrachten elke saga deelnemer reageert.
Er is geen andere service vereist voor coördinatie.	Er bestaat een risico op cyclische afhankelijkheid tussen saga-deelnemers, omdat ze elkaars opdrachten moeten gebruiken.
Veroorzaakt geen enkel storingspunt omdat de verantwoordelijkheden over de saga-deelnemers zijn verdeeld.	Integratietests zijn moeilijk omdat alle services moeten worden uitgevoerd om een transactie te simuleren.

Orkestratie

Bij orkestratie verwerkt een gecentraliseerde controller, of orchestrator, alle transacties en vertelt deze de deelnemers welke operatie ze op basis van gebeurtenissen moeten uitvoeren. De orchestrator voert saga-aanvragen uit, slaat en interpreteert de statussen van elke taak en verwerkt foutherstel met behulp van compenserende transacties.

Voordelen van orkestratie	Nadelen van orkestratie
Beter geschikt voor complexe werkstromen of wanneer u nieuwe services toevoegt.	Andere ontwerpcomplexiteit vereist een implementatie van een coördinatielogica.
Vermijd cyclische afhankelijkheden omdat de orchestrator de stroom beheert.	Introduceert een foutpunt omdat de orchestrator de volledige werkstroom beheert.
Duidelijke scheiding van verantwoordelijkheden vereenvoudigt servicelogica.

Problemen en overwegingen

Houd rekening met de volgende punten wanneer u besluit hoe u dit patroon implementeert:

• Verschuiving in het ontwerpdenken: Het toepassen van het Saga-patroon vereist een andere denkwijze. Hiervoor moet u zich richten op transactiecoördinatie en gegevensconsistentie tussen meerdere microservices.

• Complexiteit van foutopsporingssages: Debugging-saga's kunnen complex zijn, met name naarmate het aantal deelnemende services groeit.

• Onomkeerbare wijzigingen in de lokale database: Gegevens kunnen niet ongedaan worden gemaakt omdat sagadeelnemers wijzigingen vastleggen in hun respectieve databases.

• Afhandeling van tijdelijke fouten en idempotentie: Het systeem moet tijdelijke fouten effectief afhandelen en idempotentie garanderen wanneer dezelfde bewerking wordt herhaald, verandert het resultaat niet. Zie Idempotent message processingvoor meer informatie.

• Noodzaak van het monitoren en volgen van saga's: Het monitoren en volgen van de workflow van een saga zijn essentiële taken om het operationele overzicht te behouden.

• Beperkingen van compenserende transacties: Compenserende transacties slagen mogelijk niet altijd, waardoor het systeem in een inconsistente toestand kan blijven.

Mogelijke gegevensafwijkingen in saga's

Gegevensafwijkingen zijn inconsistenties die kunnen optreden wanneer saga's over meerdere services heen actief zijn. Omdat elke service zijn eigen gegevens beheert, genaamd gegevens van deelnemers, is er geen ingebouwde isolatie tussen services. Deze installatie kan leiden tot inconsistenties van gegevens of duurzaamheidsproblemen, zoals gedeeltelijk toegepaste updates of conflicten tussen services. Veelvoorkomende problemen zijn:

• Verloren updates: Wanneer een saga gegevens wijzigt zonder rekening te houden met wijzigingen die door een andere saga zijn aangebracht, resulteert dit in overschreven of ontbrekende updates.

• Dirty reads: Wanneer een saga of transactie gegevens leest die een andere saga heeft gewijzigd, maar de wijziging nog niet is voltooid.

• Fuzzy, of niet-herhaalbare, leesbewerkingen: Wanneer verschillende stappen in een saga inconsistente gegevens lezen doordat er tussen de leesbewerkingen updates plaatsvinden.

Strategieën voor het aanpakken van gegevensafwijkingen

Als u deze afwijkingen wilt verminderen of voorkomen, kunt u de volgende tegenmaatregelen overwegen:

• Semantische vergrendeling: Gebruik vergrendelingen op applicatieniveau wanneer een compenseerbare transactie van een saga een semafoor gebruikt om aan te geven dat er een update wordt uitgevoerd.

• commutatieve updates: Ontwerpupdates, zodat ze in elke volgorde kunnen worden toegepast terwijl hetzelfde resultaat wordt geproduceerd. Deze aanpak helpt conflicten tussen saga's te verminderen.

• pessimistische weergave: de volgorde van de saga opnieuw ordenen, zodat gegevensupdates plaatsvinden in opnieuw te proberen transacties om vuile leesbewerkingen te elimineren. Anders kan één saga vuile gegevens lezen of niet-doorgevoerde wijzigingen, terwijl een andere saga tegelijkertijd een compenserende transactie uitvoert om de updates terug te draaien.

• Waarden voor opnieuw lezen: bevestig dat de gegevens ongewijzigd blijven voordat u updates uitvoert. Als de gegevens veranderen, stopt u de huidige stap en start u de saga zo nodig opnieuw op.

• versiebestanden: een logboek bijhouden van alle bewerkingen die worden uitgevoerd op een record en ervoor zorgen dat ze in de juiste volgorde worden uitgevoerd om conflicten te voorkomen.

• op risico gebaseerde gelijktijdigheid op basis van waarde: kies dynamisch het juiste gelijktijdigheidsmechanisme op basis van het potentiële bedrijfsrisico. Gebruik bijvoorbeeld saga's voor updates met een laag risico en gedistribueerde transacties voor updates met een hoog risico.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer:

• U moet zorgen voor gegevensconsistentie in een gedistribueerd systeem zonder strakke koppeling.
• U moet terugdraaien of compenseren als een van de bewerkingen in de reeks mislukt.

Dit patroon is mogelijk niet geschikt wanneer:

• Transacties zijn nauw gekoppeld.
• Compenserende transacties vinden plaats in eerdere deelnemers.
• Er zijn cyclische afhankelijkheden.

Volgende stap

• cloudeigen gegevenspatronen

Gerelateerde resources

De volgende patronen zijn mogelijk relevant wanneer u dit patroon implementeert:

• Het Choreografiepatroon laat elk onderdeel van het systeem deelnemen aan het besluitvormingsproces over de workflow van een bedrijfstransactie, in plaats van te vertrouwen op een centraal besturingspunt.

• Het patroon voor compenserende transacties maakt werk ongedaan dat door een reeks stappen is uitgevoerd, en zorgt er uiteindelijk voor dat een consistente bewerking wordt gedefinieerd als een of meer stappen mislukken. In de cloud gehoste toepassingen die complexe bedrijfsprocessen en werkstromen implementeren, volgen vaak dit uiteindelijke consistentiemodel.

• Met het opnieuw proberen-patroon kan een toepassing tijdelijke fouten afhandelen wanneer deze verbinding probeert te maken met een service of netwerkbron, door de mislukte bewerking transparant opnieuw te proberen. Dit patroon kan de stabiliteit van de toepassing verbeteren.

• Het patroon circuitonderbreker verwerkt fouten die een variabele hoeveelheid tijd in beslag nemen om van te herstellen, wanneer u verbinding maakt met een externe service of resource. Dit patroon kan de stabiliteit en tolerantie van een toepassing verbeteren.

• Het patroon Health Endpoint Monitoring implementeert functionele controles in een toepassing waartoe externe hulpprogramma's met regelmatige tussenpozen toegang hebben via weergegeven eindpunten. Met dit patroon kunt u controleren of toepassingen en services correct presteren.