Het patroon van compenserende transacties

Gebruik dit patroon om werk ongedaan te maken wanneer een of meer stappen mislukken in een uiteindelijk consistente bewerking. In de cloud gehoste toepassingen die complexe bedrijfsprocessen en werkstromen implementeren, maken vaak gebruik van bewerkingen die voldoen aan het uiteindelijke consistentiemodel.

Context en probleem

Cloudtoepassingen wijzigen regelmatig gegevens die verspreid zijn over verschillende gegevensbronnen op verschillende geografische locaties. Om conflicten te voorkomen en de prestaties in een gedistribueerde omgeving te verbeteren, moeten toepassingen uiteindelijke consistentie implementeren in plaats van sterke transactionele consistentie. In het uiteindelijke consistentiemodel bestaat een typische bedrijfsbewerking uit een reeks afzonderlijke stappen. Tijdens deze stappen kan de algehele weergave van de systeemstatus inconsistent zijn. Maar het systeem moet weer consistent worden wanneer alle stappen zijn voltooid.

Het afhandelen van stapfouten vormt een belangrijke uitdaging in het uiteindelijke consistentiemodel. Na een fout moet u mogelijk werk ongedaan maken vanuit de voltooide bewerkingsstappen. U kunt de gegevens echter niet altijd terugdraaien omdat andere gelijktijdige toepassingsexemplaren de gegevens kunnen wijzigen. Zelfs wanneer gelijktijdige exemplaren de gegevens niet wijzigen, kan het complexer zijn om een stap ongedaan te maken dan de oorspronkelijke status te herstellen. Mogelijk moet u bedrijfsspecifieke regels toepassen. Zie het voorbeeld van de reiswebsite voor een voorbeeld.

Wanneer een bewerking die uiteindelijke consistentie implementeert meerdere gegevensarchieven omvat, moet u elke gegevensopslag openen om de wijzigingen ongedaan te maken. Om te voorkomen dat het systeem inconsistent blijft, moet u het werk in elk gegevensarchief betrouwbaar ongedaan maken.

Een bewerking die uiteindelijke consistentie implementeert, slaat de betrokken gegevens niet altijd op in een database. In een SOA-omgeving (servicegeoriënteerde architectuur) kan een bewerking bijvoorbeeld een actie in een service aanroepen en de status wijzigen waarin de service zich bevindt. Als u de bewerking ongedaan wilt maken, moet u deze statuswijziging ook ongedaan maken, wat kan betekenen dat u de service opnieuw aanroept om de effecten van de eerste actie ongedaan te maken.

Solution

Implementeer een compenserende transactie waarmee de effecten van voltooide stappen in de oorspronkelijke bewerking ongedaan worden gemaakt. U denkt misschien dat u het systeem gewoon kunt herstellen naar de oorspronkelijke staat, maar deze methode kan wijzigingen van andere gelijktijdige toepassingsexemplaren overschrijven. In plaats daarvan moet de compenserende transactie op intelligente wijze rekening houden met gelijktijdig werk. Dit proces is meestal toepassingsspecifiek en is afhankelijk van de oorspronkelijke bewerking.

U kunt een werkstroom gebruiken om een uiteindelijk consistente bewerking te implementeren waarvoor compensatie is vereist. Terwijl de oorspronkelijke bewerking wordt uitgevoerd, registreert het systeem informatie over elke stap en hoe u deze ongedaan maakt. Als de bewerking mislukt, wordt de workflow via de voltooide stappen teruggespoeld en elke stap wordt ongedaan gemaakt.

Diagram met een werkstroom met stappen vooruit en compenserende acties. Een gebruiker start een bewerking die stap 1, stap 2 en stap 3 opeenvolgend uitvoert. Als alle stappen slagen, wordt het proces voltooid. Als er na een stap een fout optreedt, worden compensatieacties in omgekeerde volgorde uitgevoerd om voltooid werk ongedaan te maken, waardoor er een gecompenseerde status ontstaat.

Hoewel elke stap een afzonderlijke actie is, vormen ze samen een uiteindelijk consistente bewerking. Het systeem moet de stappen en de bijbehorende bewerkingen voor ongedaan maken uitvoeren voor elke stap. Als de klant annuleert, kunnen deze ongedaan maken bewerkingen worden uitgevoerd als compenserende transactie.

Een fout in één stap vereist niet altijd dat u het hele systeem terugdraait met behulp van een compenserende transactie. In een scenario van een reiswebsite boekt een klant bijvoorbeeld vluchten F1, F2 en F3, maar kan geen kamer reserveren in hotel H1. Het aanbieden van een kamer in een ander hotel is de voorkeur aan het annuleren van de vluchten. De klant kan er nog steeds voor kiezen om te annuleren, waardoor de compenserende transactie wordt geactiveerd om de vluchtreserveringen ongedaan te maken. De klant moet deze beslissing echter nemen, niet het systeem. Wanneer beslissingen een hoge impact hebben of moeilijk te automatiseren zijn, neemt u een mens op in het besluitvormingsproces.

Houd rekening met deze belangrijke punten:

• Een compenserende transactie hoeft het werk mogelijk niet ongedaan te maken in de exacte omgekeerde volgorde van de oorspronkelijke bewerking.

• Mogelijk kunt u enkele stappen voor ongedaan maken parallel uitvoeren.

• Mogelijk moet u bedrijfsspecifieke regels toepassen. Als u bijvoorbeeld een vluchtreservering annuleert, heeft de klant mogelijk geen recht op een volledige terugbetaling.

Deze benadering is vergelijkbaar met het patroon van gedistribueerde Saga-transacties.

Compenserende transacties zijn uiteindelijk consistente bewerkingen en kunnen mislukken. Het systeem moet de voortgang vastleggen, zodat de compenserende transactie kan worden hervat vanaf het foutpunt. Een stap kan meerdere keren worden uitgevoerd wanneer het opnieuw wordt geprobeerd, dus ontwerp elke stap als een idempotente opdracht.

Soms is handmatige interventie de enige manier om te herstellen van een mislukte stap. In deze situaties moet het systeem een waarschuwing genereren met gedetailleerde informatie over de reden van de fout.

Problemen en overwegingen

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

• Het is mogelijk niet eenvoudig om te bepalen wanneer een stap in een bewerking die uiteindelijke consistentie implementeert, mislukt. Een stap mislukt mogelijk niet onmiddellijk, maar wordt in plaats daarvan geblokkeerd. Mogelijk moet u een time-outmechanisme implementeren.

• Het is niet eenvoudig om compensatielogica te generaliseren. Een compenserende transactie is toepassingsspecifiek. Het is afhankelijk van de toepassing met voldoende informatie om de effecten van elke stap in een mislukte bewerking ongedaan te maken.

• Compenserende transacties werken niet altijd. Definieer de stappen in een compenserende transactie als idempotente opdrachten, zodat u deze kunt herhalen als de compenserende transactie zelf mislukt.

• De infrastructuur die de stappen afhandelt, moet voldoen aan de volgende criteria:

  • Het is veerkrachtig in zowel de oorspronkelijke operatie als de compenserende transactie.

  • De informatie die nodig is om een mislukte stap te compenseren, gaat niet verloren.

  • Het bewaakt op betrouwbare wijze de voortgang van compensatielogica. Compenserende transacties worden uitgevoerd nadat de oorspronkelijke bewerkingen zijn doorgevoerd en andere transacties kunnen tussenliggende statussen wijzigen. Zorg er daarom voor dat u zowel de oorspronkelijke bewerking als de compensatie end-to-end kunt correleren en controleren.

• Een compenserende transactie brengt de systeemgegevens niet noodzakelijkerwijs terug naar de staat aan het begin van de oorspronkelijke bewerking. In plaats daarvan compenseert de transactie het werk dat door de bewerking werd voltooid voordat deze faalde.

• De compenserende transactiestappen keren de oorspronkelijke bewerking niet altijd om in de exacte tegenovergestelde volgorde. Als een gegevensarchief bijvoorbeeld gevoeliger is voor inconsistenties dan een andere, moet u eerst wijzigingen in dat archief ongedaan maken.

• Sommige metingen kunnen u helpen de slagingspercentages te verbeteren. U kunt een kortlopende vergrendeling met een time-out plaatsen voor elke resource die nodig is om een bewerking te voltooien. U kunt deze resources van tevoren verkrijgen en vervolgens pas werk uitvoeren nadat u alle resources hebt verkregen. Voltooi alle acties voordat de vergrendelingen verlopen.

• Logica voor opnieuw proberen die meer fouten behandelt als tijdelijk, kan helpen bij het minimaliseren van fouten die een compenserende transactie activeren. Wanneer een stap in een bewerking die uiteindelijke consistentie implementeert, mislukt, verwerkt u deze als een tijdelijke uitzondering en voert u de stap opnieuw uit. Stop de bewerking alleen en activeer compensatie als de stap herhaaldelijk mislukt of als je deze niet kunt herstellen. Zie Tijdelijke foutafhandeling voor meer informatie over strategieën voor opnieuw proberen.

• Wanneer u een compenserende transactie implementeert, ondervindt u veel uitdagingen die vergelijkbaar zijn met het implementeren van uiteindelijke consistentie. Zie Coördinatie minimaliseren voor meer informatie.

• Definieer duidelijke punten zonder retour - en onherstelbare stappen. In complexe werkstromen kunt u bepaalde bewerkingen niet veilig of zinvol ongedaan maken, zoals externe neveneffecten of juridisch bindende acties. Compensable versus onherroepelijke stappen identificeren. Ontwerp de werkstroom zo dat onomkeerbare stappen pas plaatsvinden nadat alle kritieke validaties zijn geslaagd.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer:

• Een bedrijfsbewerking omvat meerdere stappen, services of gegevensarchieven en moet ongedaan worden gemaakt als een latere stap mislukt. Dit scenario treedt vaak op in langlopende werkstromen die een uiteindelijke consistentiemodel volgen en kunnen niet afhankelijk zijn van atomische transacties.

• Het herstel na een fout vereist vaak de domeinspecifieke logica in plaats van een eenvoudig gegevensherstel. Als u compenserende acties gebruikt bij het ongedaan maken van werk, moet u bedrijfsregels toepassen, zoals het annuleren van reserveringen of het uitgeven van gedeeltelijke restituties.

Dit patroon is mogelijk niet geschikt wanneer:

• Bewerkingen kunnen veilig opnieuw worden geprobeerd en de meeste fouten zijn tijdelijk. Logica voor opnieuw proberen is vaak voldoende in deze gevallen en compenserende transacties zorgen voor onnodige complexiteit.

• Het systeem kan tijdelijke inconsistentie niet tolereren of compensatie kan een geldige status niet betrouwbaar herstellen. Gebruik in plaats daarvan sterke consistentiemechanismen of atomische transacties in alle stappen.

Werklastontwerp

Evalueer hoe u de compenserende transactie kunt gebruiken in het ontwerp van een workload om de doelstellingen en principes aan te pakken die worden behandeld in de pijlers van het Azure Well-Architected Framework. De volgende tabel bevat richtlijnen over hoe dit patroon de doelstellingen van elke pijler ondersteunt.

Pilaar	Hoe dit patroon ondersteuning biedt voor pijlerdoelen
betrouwbaarheid ontwerpbeslissingen helpen uw workload tolerant te worden defect te raken en ervoor te zorgen dat deze herstelt naar een volledig functionerende status nadat er een storing is opgetreden.	Compensatieacties hebben betrekking op storingen in kritieke workloadpaden met behulp van processen zoals het rechtstreeks terugdraaien van gegevenswijzigingen, het verbreken van transactievergrendelingen of zelfs het uitvoeren van systeemeigen systeemgedrag om het effect te omkeren. - RE:02 Kritieke stromen - RE:09 Herstel na noodgevallen

Als dit patroon compromissen binnen een pijler introduceert, moet u deze tegen de doelstellingen van de andere pijlers overwegen.

Voorbeeld

In het volgende diagram ziet u een praktische Azure implementatie van het patroon Compenserende transactie. Andere implementaties werken mogelijk ook voor uw workloadvereisten. Een orchestrator die wordt uitgevoerd in Azure Container Apps coördineert elke stap van een langlopende werkstroom door opdrachten te verzenden via Azure Service Bus. Wanneer elke volgende stap slaagt, registreert de orchestrator zowel de uitvoeringsstatus als de bijbehorende compenserende actie in Azure Cosmos DB, zodat de werkstroom kan worden hervat, gecorreleerd en gecontroleerd.

Diagram met een werkstroom in een Azure Container Apps-omgeving. Een client verzendt een aanvraag naar een orchestratorcontainer, die Service A en Service B coördineert en operaties opneemt. Stap 1- en stap 2-berichten worden via de Service Bus verzonden. Als een stap mislukt, worden compenserende acties uitgevoerd in omgekeerde volgorde. Mislukte berichten worden verplaatst naar een dode-letter wachtrij. De omgeving kan worden geïntegreerd met Microsoft Entra ID voor identiteit en Application Insights en Azure Monitor voor waarneembaarheid.

In dit model worden nieuwe pogingen eerst gebruikt om voorwaartse voortgang te verzekeren. Als een stap mislukt, past de orchestrator logica voor nieuwe pogingen toe op tijdelijke fouten en probeert de oorspronkelijke bewerking voort te zetten. Compensatie wordt alleen aangeroepen wanneer vooruitgang onmogelijk wordt, bijvoorbeeld wanneer nieuwe pogingen zijn uitgeput of als de fout als niet-transient wordt geclassificeerd.

Bedrijfsspecifieke regels kunnen ook de voorkeur geven aan vooruitlopende voortgang ten opzichte van onmiddellijke compensatie. Als een stap mislukt, kan de orchestrator een alternatief pad selecteren, zoals het vervangen van een equivalente service of fallbackoptie, in plaats van de werkstroom terug te draaien. Voor impactvolle of dubbelzinnige gevallen kunt u de werkstroom onderbreken voor menselijke beoordeling voordat u besluit of u wilt doorgaan met een alternatief pad of compensatie te activeren. Deze aanpak behandelt compensatie als laatste redmiddel en stelt domeinregels in staat om herstelbeslissingen te nemen.

In een typische volgorde verzendt de orchestrator stapberichten via Service Bus (stap 1 en 2), ontvangt succesvolle resultaten en slaat de metagegevens voor forward en compensatie op in Azure Cosmos DB.

U kunt compensatie op twee manieren activeren:

• Wanneer een latere stap in dezelfde workload mislukt en u eerder geslaagde stappen ongedaan moet maken. Deze compensatie kan onmiddellijk optreden wanneer een stap een bedrijfsfout retourneert, zoals een regelvalidatiefout, of nadat technische herhaalpogingen zijn uitgeput en het bericht wordt verplaatst naar de dead-letter queue.

• Wanneer een volgende client expliciet aanvraagt om een voltooide bewerking te annuleren.

In beide gevallen leest de orchestrator de opgeslagen compensatierecords en verzendt hij compensatieopdrachten naar de bijbehorende service. Als een compensatiestap tijdelijk mislukt, kan Service Bus deze opnieuw proberen te voltooien zonder het incident te escaleren.

Als herhaalde nieuwe pogingen nog steeds mislukken, verplaatst Service Bus het bericht naar een dead-letter queue en worden de foutdetails behouden. De orchestrator, of een gespecialiseerde dead-letter processor, genereert een waarschuwing en stuurt gestructureerde telemetrie, inclusief foutredenen en correlatie-ID's, naar Azure Monitor en Log Analytics, waarmee de gegevens in Application Insights kunnen worden weergegeven. Dit operationele pad helpt teams bij het diagnosticeren van fouten, het bepalen van de noodzaak van handmatige interventie en het onderhouden van traceerbaarheid in zowel de oorspronkelijke als compenserende stromen.

De werkstroom kan automatisch compensatie starten voor duidelijke, lage risicovoorwaarden of onderbreken voor menselijke beoordeling wanneer de situatie dubbelzinnig, hoog effect heeft of een handmatige beslissing vereist.

Gebruik beheerde identiteiten en Microsoft Entra ID-gebaseerde autorisatie tussen onderdelen om gedeelde geheimen te voorkomen en toegang met minimale bevoegdheden af te dwingen. Wanneer u een vereenvoudigd referentiediagram maakt, behandelt u deze identiteits- en autorisatiebesturingselementen als basislijn implementatieproblemen in plaats van expliciete stroomstappen. Houd het diagram gericht op indeling, opnieuw proberen, compensatie en foutafhandeling.

Gerelateerde bronnen

• Overwegingen voor gegevens voor microservices: ontdek waarom uiteindelijke consistentie en gedeeltelijke fouten inherent zijn aan gedistribueerde systemen. Het patroon Compenserende transactie biedt een concreet mechanisme voor het afhandelen van deze fouten wanneer bewerkingen meerdere services omvatten.

• Transactionele Outbox-patroon met Azure Cosmos DB: Gebruik dit patroon wanneer compenserende transacties betrouwbaar evenementen of commando's moeten publiceren. Het helpt ervoor te zorgen dat statuswijzigingen en berichten atomisch worden vastgelegd, waardoor het verlies van berichten wordt voorkomen.

• Ontwerp voor zelfherstel: Gebruik compenserende transacties als onderdeel van een zelfherstelmethode voor uw toepassingen.

• Scheduler Agent Supervisor-patroon: gebruik dit patroon om tolerante systemen te implementeren die bedrijfsactiviteiten uitvoeren in gedistribueerde services en resources. Deze systemen hebben soms compenserende transacties nodig om werk ongedaan te maken.

• Patroon voor opnieuw proberen: gebruik dit patroon om tijdelijke fouten af te handelen en de noodzaak voor compenserende transacties te minimaliseren.

• Saga distributed transactions pattern: Gebruik dit patroon om de gegevensconsistentie over microservices in gedistribueerde transacties te beheren. Saga maakt gebruik van compenserende transacties voor foutherstel.

• Patroon Pijpen en filters: gebruik dit patroon met het patroon Compenserende transactie als alternatief voor gedistribueerde transacties wanneer u complexe taken opdeelt in herbruikbare stappen.