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, sága provede kompenzační transakce, aby vrátila dokončené kroky zpět a zachovala 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 ovlivňující 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é.
- konzistence: Přechody dat z jednoho platného stavu do jiného.
- izolace: Souběžné transakce poskytují stejné výsledky jako sekvenční transakce.
- stálosti: Po potvrzení se změny zachovají i v případě selhání.
V jedné službě se transakce řídí principy ACID, protože pracují v rámci jedné databáze. Dosažení dodržování předpisů ACID napříč více službami je ale složitější.
Problémy s architekturami mikroslužeb
Architektury mikroslužeb obvykle přiřazují vyhrazenou databázi ke každémikroslužeb, která 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.
- Nezávislé škálování databází pro každou službu
- Selhání v jedné službě jsou izolovaná od ostatních.
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 (IPC) nebo tradiční modely transakcí, jako je dvoufázové potvrzení (2PC), často vhodnější pro model Saga.
Řešení
Model Saga spravuje transakce rozdělením do posloupnosti místních transakcí (viz obrázek 1).
Obrázek 1 Saga se třemi službami.
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: Transakce, které ostatní transakce mohou vrátit zpět nebo kompenzovat 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: Pivot transakce slouží jako "bod bez vrácení" v ságě. Jakmile bude transakce kontingenční tabulky úspěšná, nebudou už komponovatelné transakce (které je možné vrátit zpět) relevantní. Všechny následné akce musí být dokončeny, aby systém dosáhl konzistentního konečného stavu. Pivot transakce může spadat do různých rolí v závislosti na toku ságy:
nevratné (nekompatibilní): Nedá se vrátit zpět ani opakovat.
hranice mezi reverzibilním a potvrzeným: Může se jednat o poslední vrácení (compensable) transakce, nebo může být první opakovatelnou operací v ságě.
opakovatelné transakce: Tyto transakce následují za kontingenční transakcí. Opakovatelné transakce jsou idempotentní a zajistit, aby saga dosáhla konečného stavu, i když dojde k dočasným selháním. Zaručuje, že saga nakonec dosáhne konzistentního stavu.
Přístupy k implementaci Saga
Existují dva společné přístupy implementace saga, taneční a orchestrace. Každý přístup má svou vlastní sadu výzev a technologií ke koordinaci pracovního postupu.
Choreografie
V hierarchii vyměňují služby události bez centralizovaného kontroleru. S tanečním prostředím každá místní transakce publikuje doménové události, které aktivují místní transakce v jiných službách (viz obrázek 2).
Obrázek 2 Sága, která používá hierarchii.
| Výhody taneční | |
|---|---|
| Vhodné pro jednoduché pracovní postupy s několika službami 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, které ságy účastníci poslouchají, které příkazy. |
| 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ýt spuštěné pro simulaci transakce. |
Orchestrace
V orchestraci zpracovává centralizovaný kontroler (orchestrátor) 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í (viz obrázek 3).
Obrázek 3 Saga, která používá orchestraci.
| 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. |
| Vyhněte 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 implementaci vzoru Saga zvažte následující body:
Posun v myšlení návrhu: Přijetí vzoru Saga vyžaduje jiný názor, který se zaměřuje na koordinaci transakcí a zajištění konzistence dat napříč několika mikroslužbami.
složitost ladění sagas: Ladění sagas může být složité, zejména s rostoucím počtem zúčastněných služeb.
nevratné změny místní databáze: Data se nedají 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 idempotentních: 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 nezbytné pro zachování provozního dohledu.
Omezení kompenzačních transakcí: Kompenzační transakce nemusí být vždy úspěšné, potenciálně by systém opustil 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 při provádění ság napříč více službami. Vzhledem k tomu, že každá služba spravuje svá vlastní data (data účastníků), neexistuje žádná integrovaná izolace mezi službami. Výsledkem tohoto nastavení můžou být nekonzistence dat nebo problémy s odolností, jako jsou částečně použité aktualizace nebo konflikty mezi službami. Mezi běžné problémy patří:
Ztracené aktualizace: Když jedna saga upraví data bez zvážení změn provedených jinou ságou, vede k přepsání nebo chybějícím aktualizacím.
Dirty reads: Když saga nebo transakce čte data, která jiná saga změněna, ale ještě není dokončena.
Fuzzy (nonrepeatable) č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 tato protiopatření:
sémantický zámek: Použijte zámky na úrovni aplikace, kde saga compensable transakce používá semaphore indikuje, že aktualizace probíhá.
commutativní aktualizace: Aktualizace návrhu, aby je bylo možné použít v libovolném pořadí, zatímco stále vytváří stejný výsledek, což snižuje 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í. V opačném případě by jedna sága mohla číst špinavá data (nepotvrzené změny), zatímco jiná saga současně spouští compensable transakci pro vrácení aktualizací zpět.
Hodnoty opětovného načítání: Před aktualizací ověřte, že data zůstávají beze změny. Pokud se data změní, přerušte aktuální krok a podle potřeby restartujte saga.
soubory verzí: Udržujte protokol všech operací v záznamu a ujistěte se, že jsou spouštěny ve správném pořadí, aby se zabránilo konfliktům.
souběžnosti na základě rizika (podle hodnoty): Dynamicky zvolte vhodný mechanismus souběžnosti na základě potenciálního obchodního rizika. Například použijte ságy pro aktualizace s nízkým rizikem a distribuované transakce pro vysoce rizikové.
Kdy použít tento vzor
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.
Další kroky
- distribuované datové
- Richardson, Chrisi. 2018: vzory mikroslužeb. Manning Publications.
Související prostředky
Při implementaci tohoto modelu můžou být užitečné i následující vzory:
- hierarchii má každá komponenta systému účast v rozhodovacím procesu týkajícím se pracovního postupu obchodní transakce místo toho, aby se spoléhala na centrální bod kontroly.
- kompenzační transakce vrátit zpět práci provedenou řadou kroků a nakonec definovat 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 při pokusu o připojení 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ě.