Upravit

Sdílet prostřednictvím

Model distribuovaných transakcí Saga

Azure

Vzor návrhu Saga je způsob, jak spravovat konzistenci dat napříč mikroslužbami ve scénářích distribuovaných transakcí. Saga je posloupnost transakcí, které aktualizují každou službu a publikují zprávu nebo událost pro aktivaci dalšího kroku transakce. Pokud krok selže, sága provede kompenzační transakce, které brání předchozím transakcím.

Kontext a problém

Transakce je jedna jednotka logiky nebo práce, někdy tvořená několika operacemi. V rámci transakce je událost změnou stavu, která nastane u entity, a příkaz zapouzdřuje všechny informace potřebné k provedení akce nebo aktivaci pozdější události.

Transakce musí být atomické, konzistentní, izolované a odolné (ACID). Transakce v rámci jedné služby jsou ACID, ale konzistence dat mezi službami vyžaduje strategii správy transakcí napříč službami.

V architekturách s více službami:

  • Atomicita je nedělitelná a irreducibilní sada operací, ke kterým musí dojít nebo k žádné chybě.
  • Konzistence znamená, že transakce přináší data pouze z jednoho platného stavu do jiného platného stavu.
  • Izolace zaručuje, že souběžné transakce vytvářejí stejný stav dat, který by se postupně spouštěly transakce.
  • Stálost zajišťuje, že potvrzené transakce zůstanou potvrzeny i v případě selhání systému nebo výpadku napájení.

Model databáze na mikroslužby nabízí mnoho výhod pro architektury mikroslužeb. Zapouzdření dat domény umožňuje každé službě používat svůj nejlepší typ a schéma úložiště dat, škálovat podle potřeby vlastní úložiště dat a izolovat je před selháními jiných služeb. Zajištění konzistence dat napříč databázemi specifickými pro služby ale představuje výzvy.

Distribuované transakce, jako je dvoufázové potvrzení (2PC), vyžadují, aby všichni účastníci transakce potvrzení nebo vrácení zpět, než transakce může pokračovat. Některé implementace účastníků, jako jsou databáze NoSQL a zprostředkování zpráv, ale tento model nepodporují.

Dalším omezením distribuovaných transakcí je synchronita a dostupnost komunikace mezi procesy (IPC ). IPC poskytovaný operačním systémem umožňuje samostatným procesům sdílet data. Aby se distribuovaná transakce mohly potvrdit, musí být všechny zúčastněné služby dostupné, což může snížit celkovou dostupnost systému. Implementace architektury s omezeními IPC nebo transakcí jsou kandidáty na model Saga.

Řešení

Model Saga poskytuje správu transakcí pomocí posloupnosti místních transakcí. Místní transakce je atomické pracovní úsilí prováděné účastníkem ságy. Každá místní transakce aktualizuje databázi a publikuje zprávu nebo událost, aby se aktivovala další místní transakce v saga. Pokud místní transakce selže, saga provede řadu kompenzačních transakcí, které vrátí zpět změny provedené předchozími místními transakcemi.

Přehled Saga.

V vzorech Saga:

  • Komponovatelné transakce jsou transakce , které mohou být potenciálně obráceny zpracováním jiné transakce s opačným účinkem.
  • Kontingenční transakce je bod go/no-go v ságě. Pokud kontingenční transakce potvrzení, saga poběží do dokončení. Kontingenční transakce může být transakce, která není compensable ani opakovatelná, nebo může být poslední compensable transakce nebo první opakovatelná transakce v ságě.
  • Opakovatelné transakce jsou transakce , které následují za kontingenční transakcí a jsou zaručeny úspěšné.

Existují dva běžné přístupy k implementaci ság, hierarchii a orchestraci. Každý přístup má svou vlastní sadu výzev a technologií ke koordinaci pracovního postupu.

Choreografie

Telemetrie je způsob, jak koordinovat ságy, kde účastníci vyměňují události bez centralizovaného kontrolního bodu. S hierarchií každá místní transakce publikuje doménové události, které aktivují místní transakce v jiných službách.

Přehled telemetrie

Zaměstnanecké výhody

  • Vhodné pro jednoduché pracovní postupy, které vyžadují několik účastníků a nepotřebují koordinaci logiky.
  • Nevyžaduje další implementaci a údržbu služeb.
  • Nezavádí jediný bod selhání, protože povinnosti jsou rozděleny mezi účastníky ságy.

Nevýhody

  • Pracovní postup může být při přidávání nových kroků matoucí, protože je obtížné sledovat, kteří účastníci saga poslouchají, které příkazy.
  • Existuje riziko cyklické závislosti mezi účastníky ságy, protože musí navzájem využívat příkazy.
  • Testování integrace je obtížné, protože všechny služby musí být spuštěné pro simulaci transakce.

Orchestrace

Orchestrace je způsob, jak koordinovat ságy, kde centralizovaný kontroler říká účastníkům ságy, jaké místní transakce mají být provedeny. Orchestrátor saga zpracovává všechny transakce a informuje účastníky, které operace se mají provádět na základě událostí. Orchestrátor provádí požadavky na saga, ukládá a interpretuje stavy jednotlivých úloh a zpracovává zotavení po selhání pomocí kompenzačních transakcí.

Přehled orchestrace

Zaměstnanecké výhody

  • Vhodné pro složité pracovní postupy zahrnující mnoho účastníků nebo nových účastníků přidaných v průběhu času.
  • Vhodné, pokud je kontrola nad každým účastníkem procesu a kontrolu nad tokem aktivit.
  • Nezavádí cyklické závislosti, protože orchestrátor jednostranně závisí na ságách účastníků.
  • Účastníci Saga nemusí vědět o příkazech pro ostatní účastníky. Jasné oddělení obav zjednodušuje obchodní logiku.

Nevýhody

  • Další složitost návrhu vyžaduje implementaci koordinační logiky.
  • Došlo k dalšímu bodu selhání, protože orchestrátor spravuje celý pracovní postup.

Problémy a důležité informace

Při implementaci vzoru Saga zvažte následující body:

  • Model Saga může být zpočátku náročný, protože vyžaduje nový způsob myšlení o tom, jak koordinovat transakci a udržovat konzistenci dat pro obchodní proces zahrnující více mikroslužeb.
  • Model Saga je obzvláště obtížně laděný a složitost roste s rostoucím nárůstem účastníků.
  • Data nelze vrátit zpět, protože účastníci saga potvrdí změny do místních databází.
  • Implementace musí být schopná zpracovat sadu potenciálních přechodných selhání a poskytnout idempotenci pro snížení vedlejších účinků a zajištění konzistence dat. Idempoteence znamená, že stejnou operaci je možné opakovat vícekrát beze změny počátečního výsledku. Další informace najdete v pokynech k zajištění idempotenci při zpracování zpráv a společné aktualizaci stavu.
  • Nejlepší je implementovat pozorovatelnost pro monitorování a sledování pracovního postupu ságy.
  • Nedostatečná izolace dat účastníků má problémy s odolností. Implementace saga musí zahrnovat protiopatření, aby se snížily anomálie.
  • Kompenzační transakce nefungují vždy.

K následujícím anomáliím může dojít bez správných měr:

  • Ztratili jsme aktualizace, když jedna sága píše bez čtení změn provedených jinou ságou.
  • Špinavé čtení, když transakce nebo sága čte aktualizace provedené ságou, která ještě nedokončila tyto aktualizace.
  • Přibližné nebo nerepeaovatelné čtení, pokud různé kroky saga čtou různá data, protože mezi čteními dojde k aktualizaci dat.

Mezi navrhovaná protiopatření pro snížení nebo prevenci anomálií patří:

  • Sémantický zámek, zámek na úrovni aplikace, kde saga compensable transakce používá semafor označující, že aktualizace probíhá.
  • Commutativní aktualizace , které lze spustit v libovolném pořadí a vytvořit stejný výsledek.
  • Pesimistické zobrazení: Je možné, aby jedna sága četla špinavá data, zatímco jiná saga spouští compensable transakci pro vrácení operace zpět. Pesimistické zobrazení změní pořadí saga tak, aby se podkladová data aktualizovala v opakovatelné transakci, což eliminuje možnost špinavého čtení.
  • Hodnota opětovného importu ověří, že se data nezměnila, a pak záznam aktualizuje. Pokud se záznam změnil, kroky se přeruší a saga se může restartovat.
  • Soubor verze zaznamenává operace u záznamu při jejich doručení a pak je spustí ve správném pořadí.
  • Podle hodnoty používá obchodní riziko jednotlivých požadavků k dynamickému výběru mechanismu souběžnosti. Požadavky s nízkým rizikem upřednostňují ságy, zatímco vysoce rizikové požadavky upřednostňují distribuované transakce.

Kdy se má tento model použít

Vzor Saga použijte, když potřebujete:

  • Zajistěte konzistenci dat v distribuovaném systému bez těsného párování.
  • Vrácení zpět nebo kompenzace v případě selhání jedné z operací v sekvenci.

Model Saga je méně vhodný pro:

  • Úzce propojené transakce.
  • Kompenzační transakce, ke kterým dochází u předchozích účastníků.
  • Cyklické závislosti.

Příklad

Saga založená na orchestraci na bezserverové platformě je odkaz na implementaci ság pomocí přístupu orchestrace, který simuluje scénář převodu peněz s úspěšnými a neúspěšnými pracovními postupy.

Další kroky

Při implementaci tohoto modelu můžou být relevantní také následující modely:

  • Hierarchie má každou komponentu systému, která se účastní rozhodovacího procesu týkajícího se pracovního postupu obchodní transakce, namísto toho, aby se spoléhala na centrální bod kontroly.
  • Kompenzační transakce vrátí zpět práci provedenou řadou kroků a nakonec definují konzistentní operaci, pokud jeden nebo více kroků selže. Aplikace hostované v cloudu, které implementují složité obchodní procesy a pracovní postupy, se často řídí tímto modelem konečné konzistence.
  • Opakování umožňuje aplikaci zpracovávat přechodné chyby, když se pokusí připojit ke službě nebo síťovému prostředku transparentním opakováním neúspěšné operace. Opakování může zlepšit stabilitu aplikace.
  • Jistič zpracovává chyby, které při připojování ke vzdálené službě nebo prostředku zabírají proměnlivou dobu obnovení. Jistič může zlepšit stabilitu a odolnost aplikace.
  • Monitorování koncových bodů stavu implementuje funkční kontroly v aplikaci, ke které můžou externí nástroje přistupovat prostřednictvím vystavených koncových bodů v pravidelných intervalech. Monitorování koncových bodů stavu může pomoct ověřit, že aplikace a služby fungují správně.