Vzor návrhu Saga pomáhá udržovat konzistenci dat v distribuovaných systémech tím, že koordinuje transakce napříč více službami. Saga je posloupnost místních transakcí, kde každá služba provádí svou operaci a iniciuje další krok prostřednictvím událostí nebo zpráv. Pokud krok v sekvenci selže, saga provede kompenzační transakce a vrátí dokončené kroky zpět. Tento přístup pomáhá udržovat konzistenci dat.
Kontext a problém
transakce představuje jednotku práce, která může zahrnovat více operací. V rámci transakce událost odkazuje na změnu stavu, která ovlivňuje entitu. Příkaz zapouzdřuje všechny informace potřebné k provedení akce nebo aktivaci následné události.
Transakce musí dodržovat zásady atomicity, konzistence, izolace a stálosti (ACID).
- Atomicity: Všechny operace jsou úspěšné nebo žádné operace nebudou úspěšné.
- Konzistence: Přechody dat z jednoho platného stavu do jiného platného stavu.
- izolace : Souběžné transakce poskytují stejné výsledky jako sekvenční transakce.
- stálost: změny po jejich potvrzení zachovají, i když dojde k selháním.
V jedné službě se transakce řídí principy ACID, protože pracují v rámci jedné databáze. Může ale být složitější dosáhnout dodržování předpisů ACID napříč několika službami.
Problémy s architekturami mikroslužeb
Architektury mikroslužeb obvykle přiřazují vyhrazenou databázi ke každé mikroslužbě. Tento přístup nabízí několik výhod:
- Každá služba zapouzdřuje svá vlastní data.
- Každá služba může používat nejvhodnější databázovou technologii a schéma pro své konkrétní potřeby.
- Databáze pro každou službu je možné škálovat nezávisle.
- Selhání v jedné službě jsou izolovaná od ostatních služeb.
Navzdory těmto výhodám tato architektura komplikuje konzistenci dat mezi službami. Tradiční databázové záruky, jako je ACID, se přímo nevztahují na více nezávisle spravovaných úložišť dat. Vzhledem k těmto omezením jsou architektury, které spoléhají na komunikaci mezi procesy nebo tradiční modely transakcí, jako je dvoufázový protokol potvrzení, často vhodnější pro model Saga.
Řešení
Model Saga spravuje transakce rozdělením do posloupnosti místních transakcí.
Každá místní transakce:
- Dokončí svou práci atomicky v rámci jedné služby.
- Aktualizuje databázi služby.
- Inicializuje další transakci prostřednictvím události nebo zprávy.
Pokud místní transakce selže, saga provede řadu kompenzačních transakcí obrátit změny provedené předchozími místními transakcemi.
Klíčové koncepty v modelu Saga
Compensable transakce lze vrátit zpět nebo kompenzovat jinými transakcemi s opačným účinkem. Pokud krok v sáze selže, kompenzační transakce vrátí zpět změny, které byly provedeny compensable transakce.
kontingenční transakce slouží jako bod bez návratu v ságě. Po úspěšném provedení kontingenční transakce už nejsou komponovatelné transakce relevantní. Aby systém dosáhl konzistentního konečného stavu, musí být dokončeny všechny následné akce. Pivot transakce může předpokládat různé role v závislosti na toku saga:
nevratné nebo nekompatibilní transakce nelze vrátit zpět ani opakovat.
Hranice mezi reverzibilním a potvrzeným znamená, že kontingenční transakce může být poslední zpětná nebo kompensovatelná transakce. Nebo to může být první opakovatelná operace v ságě.
opakovatelné transakce se řídí kontingenční transakcí. Opakovatelné transakce jsou idempotentní a pomáhají zajistit, aby saga dosáhla konečného stavu, i když dojde k dočasným selháním. Pomáhají ságě nakonec dosáhnout konzistentního stavu.
Přístupy k implementaci Saga
Dva typické přístupy k implementaci ság jsou a orchestrace. Každý přístup má svou vlastní sadu výzev a technologií ke koordinaci pracovního postupu.
Choreografie
V přístupu k hierarchii vyměňují služby události bez centralizovaného kontroleru. S hierarchií každá místní transakce publikuje doménové události, které aktivují místní transakce v jiných službách.
| Výhody telemetrie | Nevýhody režie |
|---|---|
| Vhodné pro jednoduché pracovní postupy, které mají málo služeb a nepotřebují koordinaci logiky. | Při přidávání nových kroků může být pracovní postup matoucí. Je obtížné sledovat, na které příkazy každý účastník ságy reaguje. |
| Pro koordinaci není nutná žádná jiná služba. | Existuje riziko cyklické závislosti mezi účastníky ságy, protože musí navzájem využívat příkazy. |
| Nezavádí jediný bod selhání, protože povinnosti jsou rozděleny mezi účastníky ságy. | Testování integrace je obtížné, protože všechny služby musí běžet pro simulaci transakce. |
Orchestrace
V orchestraci, centralizovaný kontroler nebo orchestrátor, zpracovává všechny transakce a informuje účastníky, které operace 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í.
| Výhody orchestrace | Nevýhody orchestrace |
|---|---|
| Vhodnější pro složité pracovní postupy nebo při přidávání nových služeb. | Jiná složitost návrhu vyžaduje implementaci koordinační logiky. |
| Vyhne se cyklickým závislostem, protože orchestrátor spravuje tok. | Představuje bod selhání, protože orchestrátor spravuje celý pracovní postup. |
| Jasné oddělení zodpovědností zjednodušuje logiku služby. |
Problémy a důležité informace
Při rozhodování o implementaci tohoto modelu zvažte následující body:
Posun v návrhovém myšlení: Přijetí vzoru Saga vyžaduje jiné myšlení. Vyžaduje, abyste se zaměřili na koordinaci transakcí a konzistenci dat napříč několika mikroslužbami.
složitost ladění sagas: ladicí ságy mohou být složité, konkrétně s rostoucím počtem zúčastněných služeb.
nevratné změny místní databáze: Data nelze vrátit zpět, protože účastníci saga potvrdí změny do příslušných databází.
Zpracování přechodných selhání a idempotenci: Systém musí efektivně zpracovávat přechodná selhání a zajistit idempotenci, když opakování stejné operace nezmění výsledek. Další informace naleznete v tématu idempotentní zpracování zpráv.
Potřeba monitorování a sledování ság: Monitorování a sledování pracovního postupu ságy jsou zásadními úkoly pro zachování provozního dohledu.
Omezení kompenzačních transakcí: kompenzační transakce nemusí být vždy úspěšné, což může systém ponechat v nekonzistentním stavu.
Potenciální datové anomálie v ságách
Datové anomálie jsou nekonzistence, ke kterým může dojít, když ságy pracují napříč více službami. Vzhledem k tomu, že každá služba spravuje svá vlastní data, označovaná jako data účastníků, neexistuje žádná integrovaná izolace napříč službami. Toto nastavení může vést k nekonzistence dat nebo problémům s stálostí, jako jsou částečně použité aktualizace nebo konflikty mezi službami. Mezi typické problémy patří:
Ztracené aktualizace: Když jedna saga upraví data bez zvážení změn provedených jinou ságou, bude výsledkem přepsání nebo chybějící aktualizace.
Dirty reads: Když saga nebo transakce čte data, která změnila jiná saga, ale úpravy nejsou dokončeny.
Fuzzy nebo nonrepeatable, přečte: Pokud různé kroky v ságě čtou nekonzistentní data, protože mezi čteními dochází k aktualizacím.
Strategie řešení datových anomálií
Pokud chcete omezit nebo zabránit těmto anomáliím, zvažte následující protiopatření:
sémantický zámek: Použít zámky na úrovni aplikace, pokud saga compensable transakce používá semaphore k označení, že aktualizace probíhá.
commutativní aktualizace: aktualizace návrhu, aby je bylo možné použít v libovolném pořadí a současně vytvořit stejný výsledek. Tento přístup pomáhá snižovat konflikty mezi ságami.
pesimistické zobrazení: Změnit pořadí posloupnosti ságy tak, aby aktualizace dat probíhaly v opakovaných transakcích, aby se eliminovaly špinavé čtení. Jinak by jedna sága mohla číst špinavá data nebo nepotvrzené změny, zatímco jiná saga současně provádí compensable transakce vrátit zpět své aktualizace.
hodnoty znovu číst: Před aktualizací potvrďte, že data zůstávají beze změny. Pokud se data změní, zastavte aktuální krok a podle potřeby restartujte ságu.
soubory verzí: Udržovat protokol všech operací provedených na záznamu a zajistit, aby se prováděly ve správném pořadí, aby se zabránilo konfliktům.
souběžnosti na základě rizik na základě hodnoty: dynamicky zvolit vhodný mechanismus souběžnosti na základě potenciálního obchodního rizika. Například použijte sagas pro aktualizace s nízkým rizikem a distribuované transakce pro vysoce rizikové aktualizace.
Kdy použít tento vzor
Tento vzor použijte v těchto případech:
- Potřebujete zajistit konzistenci dat v distribuovaném systému bez těsného párování.
- Pokud jedna z operací v sekvenci selže, musíte se vrátit zpět nebo ji zkompenzovat.
Tento vzor nemusí být vhodný v těchto případech:
- Transakce jsou úzce svázané.
- U dřívějších účastníků dochází k kompenzačním transakcím.
- Existují cyklické závislosti.
Další krok
Související prostředky
Při implementaci tohoto modelu můžou být relevantní následující vzory:
Model telemetrie má každou komponentu systému účast v rozhodovacím procesu týkajícím se pracovního postupu obchodní transakce, a nemusíte se spoléhat na centrální bod řízení.
Model kompenzační transakce vrátí zpět práci provedenou řadou kroků a nakonec definuje 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.
Vzor 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. Tento model může zlepšit stabilitu aplikace.
Model jističe zpracovává chyby, které při připojování ke vzdálené službě nebo prostředku zabírají proměnlivou dobu obnovení. Tento model může zlepšit stabilitu a odolnost aplikace.
Model 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. Tento model vám může pomoct ověřit, že aplikace a služby fungují správně.