Het Saga-ontwerppatroon helpt de consistentie van gegevens in gedistribueerde systemen te behouden door transacties over meerdere services te coördineren. Een saga is een reeks lokale transacties waarbij elke service zijn werking uitvoert en de volgende stap door gebeurtenissen of berichten initieert. Als een stap in de reeks mislukt, voert de saga compenserende transacties uit om de voltooide stappen ongedaan te maken. Deze aanpak helpt bij het behouden van gegevensconsistentie.
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:
- Voltooit het werk atomisch binnen één service.
- Hiermee wordt de database van de service bijgewerkt.
- 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
compensable transacties ongedaan kunnen worden gemaakt of gecompenseerd door andere transacties met het tegenovergestelde effect. Als een stap in de saga mislukt, maken compenserende transacties de wijzigingen ongedaan die de compenserende transacties hebben aangebracht.
draaitransacties dienen als het punt van geen terugkeer in de saga. 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 draaitransactie kan verschillende rollen aannemen, afhankelijk van de stroom van de saga:
niet-compatibele of niet-compatibele transacties niet ongedaan kunnen worden gemaakt of opnieuw kunnen worden geprobeerd.
De grens tussen omkeerbare en vastgelegde betekent dat de draaitransactie de laatste ondobare of compensable transactie kan zijn. Of het kan de eerste nieuwe poging in de saga zijn.
transacties die opnieuw kunnen worden geprobeerd de draaitransactie te volgen. Opnieuw te proberen transacties zijn idempotent en helpen ervoor te zorgen dat de saga de uiteindelijke status 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. |
| Introduceert geen single point of failure omdat de verantwoordelijkheden worden verdeeld over de saga-deelnemers. | Integratietests zijn moeilijk omdat alle services moeten worden uitgevoerd om een transactie te simuleren. |
Orkestratie
Bij indeling, een gecentraliseerde controller of orchestrator, worden alle transacties verwerkt en worden de deelnemers verteld welke bewerking moet worden uitgevoerd op basis van gebeurtenissen. De orchestrator voert saga-aanvragen uit, slaat en interpreteert de statussen van elke taak en verwerkt foutherstel met behulp van compenserende transacties.
| Voordelen van cloudindeling | Nadelen van indeling |
|---|---|
| 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:
Shift in design thinking: Adopting the Saga pattern vereist een andere mindset. 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.
kan de lokale database niet ongedaan worden gemaakt: Data kan niet worden teruggedraaid omdat saga-deelnemers wijzigingen doorvoeren 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.
Behoefte aan monitoring en tracking saga's: Monitoring and tracking the workflow of a saga zijn essentiële taken om operationeel toezicht te houden.
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 worden uitgevoerd in meerdere services. 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 niet is voltooid.
fuzzy of niet-terug te geven leesbare leesbewerkingen: Wanneer verschillende stappen in een saga inconsistente gegevens lezen omdat er updates plaatsvinden tussen de leesbewerkingen.
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 toepassingsniveau wanneer een compensable transactie van een saga een semafore 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
Gerelateerde resources
De volgende patronen zijn mogelijk relevant wanneer u dit patroon implementeert:
Het Choreograafpatroon heeft elk onderdeel van het systeem aan het besluitvormingsproces over de werkstroom van een zakelijke transactie, in plaats van te vertrouwen op een centraal controlepunt.
Het patroon Compenserende transactie het ongedaan maken van werk dat door een reeks stappen wordt uitgevoerd, ongedaan wordt gemaakt en uiteindelijk een consistente bewerking definieert als een of meer stappen mislukken. In de cloud gehoste toepassingen die complexe bedrijfsprocessen en werkstromen implementeren, volgen vaak dit uiteindelijke consistentiemodel.
Met het patroon Voor opnieuw proberen kan een toepassing tijdelijke fouten afhandelen wanneer wordt geprobeerd verbinding te maken met een service of netwerkresource door de mislukte bewerking transparant opnieuw uit te voeren. 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.