Model distribuovaných transakcí Saga

Azure

Udržujte konzistenci dat v distribuovaných systémech tím, že koordinujete posloupnost místních transakcí napříč více službami. Každá služba provádí svou operaci a aktivuje další krok událostmi nebo zprávami. Pokud krok selže, řada kompenzačních transakcí vrátí zpět změny provedené dokončeným postupem.

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 zahrnuje všechny informace potřebné k provedení akce nebo vyvolání 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.
• Trvalost: Změny po jejich potvrzení přetrvají, i když dojde k selhání.

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:

1. Dokončí svou práci atomicky v rámci jedné služby.
2. Aktualizuje databázi služby.
3. Inicializuje další transakci prostřednictvím události nebo zprávy.

Pokud místní transakce selže, saga provede řadu kompenzačních transakcí, které zvrátí změny, jež provedly předchozí místní transakce.

Klíčové koncepty v modelu Saga

• Kompenzovatelné transakce lze vrátit nebo kompenzovat jinými transakcemi s opačným účinkem. Pokud krok v sáze selže, kompenzační transakce vrátí změny, které provedly kompenzovatelné transakce.

• Klíčové transakce představují v tomto příběhu bod, z něhož není návratu. Po úspěšném provedení pivotní transakce již kompenzovatelné transakce nejsou relevantní. Aby systém dosáhl konzistentního konečného stavu, musí být dokončeny všechny následné akce. Pivotní transakce může zastávat různé role v závislosti na průběhu sagy:

  • 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í operace, kterou lze v ságě opakovat.

• Transakce, které lze opakovat následují po pivotní transakci. Transakce, které lze opakovat, jsou idempotentní a pomáhají zajistit, aby saga dosáhla svého konečného stavu, i když dojde k dočasnému selhání. Pomáhají ságě nakonec dosáhnout konzistentního stavu.

Přístupy k implementaci Saga

Dva typické přístupy k implementaci ság jsou choreografie a orchestrace. Každý přístup má svou vlastní sadu výzev a technologií ke koordinaci pracovního postupu.

Choreografie

V choreografickém přístupu si služby vyměňují události bez centralizovaného řadiče. Při choreografii každá lokální transakce publikuje doménové události, které spouštějí lokální transakce v jiných službách.

Výhody choreografie	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 v rámci sagy, ukládá a vyhodnocuje stavy jednotlivých úloh a zajišťuje obnovu 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í ság: Ladění ság 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 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í model příjemce.

• Potřeba monitorování a sledování ság: Monitorování a sledování průběhu ságy jsou zásadní úkoly pro zajištění provozního přehledu.

• 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í anomálie dat v sagá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.

• Špinavá čtení: Když saga nebo transakce čte data, která upravila jiná saga, ale tato změna ještě není dokončena.

• Fuzzy neboli neopakovatelná čtení: Když různé kroky v ságě čtou nekonzistentní data, protože mezi jednotlivými č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žijte zámky na úrovni aplikace, pokud kompenzovatelná transakce v rámci sagy používá semafor k označení, že aktualizace právě 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ý pohled: Změňte sled kroků ságy tak, aby aktualizace dat probíhaly v opakovatelných transakcích a eliminovalo se tak špinavé čtení. Jinak by jedna sága mohla číst špinavá data nebo nepotvrzené změny, zatímco jiná sága současně provede kompenzační transakci, aby vrátila 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 spusťte ságu znovu.

• 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ěžnost založená na riziku podle hodnoty: Dynamicky zvolte 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

• cloudové datové vzory

Související prostředky

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

• Vzor choreografie zajišťuje, že se každá součást systému podílí na rozhodovacím procesu o průběhu obchodní transakce, namísto spoléhání se na centrální řídicí bod.

• 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.

• Vzor Circuit Breaker řeší selhání, jejichž zotavení při připojení ke vzdálené službě nebo prostředku trvá různě dlouho. Tento model může zlepšit stabilitu a odolnost aplikace.

• Vzor monitorování koncových bodů stavu zavádí v aplikaci funkční kontroly, ke kterým mohou externí nástroje v pravidelných intervalech přistupovat prostřednictvím zveřejněných koncových bodů. Tento model vám může pomoct ověřit, že aplikace a služby fungují správně.

Udržujte konzistenci dat v distribuovaných systémech tím, že koordinujete posloupnost místních transakcí napříč více službami. Každá služba provádí svou operaci a aktivuje další krok událostmi nebo zprávami. Pokud krok selže, řada kompenzačních transakcí vrátí zpět změny provedené dokončeným postupem.

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 zahrnuje všechny informace potřebné k provedení akce nebo vyvolání 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.
• Trvalost: Změny po jejich potvrzení přetrvají, i když dojde k selhání.

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:

1. Dokončí svou práci atomicky v rámci jedné služby.
2. Aktualizuje databázi služby.
3. Inicializuje další transakci prostřednictvím události nebo zprávy.

Pokud místní transakce selže, saga provede řadu kompenzačních transakcí, které zvrátí změny, jež provedly předchozí místní transakce.

Klíčové koncepty v modelu Saga

• Kompenzovatelné transakce lze vrátit nebo kompenzovat jinými transakcemi s opačným účinkem. Pokud krok v sáze selže, kompenzační transakce vrátí změny, které provedly kompenzovatelné transakce.

• Klíčové transakce představují v tomto příběhu bod, z něhož není návratu. Po úspěšném provedení pivotní transakce již kompenzovatelné transakce nejsou relevantní. Aby systém dosáhl konzistentního konečného stavu, musí být dokončeny všechny následné akce. Pivotní transakce může zastávat různé role v závislosti na průběhu sagy:

  • 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í operace, kterou lze v ságě opakovat.

• Transakce, které lze opakovat následují po pivotní transakci. Transakce, které lze opakovat, jsou idempotentní a pomáhají zajistit, aby saga dosáhla svého konečného stavu, i když dojde k dočasnému selhání. Pomáhají ságě nakonec dosáhnout konzistentního stavu.

Přístupy k implementaci Saga

Dva typické přístupy k implementaci ság jsou choreografie a orchestrace. Každý přístup má svou vlastní sadu výzev a technologií ke koordinaci pracovního postupu.

Choreografie

V choreografickém přístupu si služby vyměňují události bez centralizovaného řadiče. Při choreografii každá lokální transakce publikuje doménové události, které spouštějí lokální transakce v jiných službách.

Výhody choreografie	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 v rámci sagy, ukládá a vyhodnocuje stavy jednotlivých úloh a zajišťuje obnovu 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í ság: Ladění ság 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 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í model příjemce.

• Potřeba monitorování a sledování ság: Monitorování a sledování průběhu ságy jsou zásadní úkoly pro zajištění provozního přehledu.

• 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í anomálie dat v sagá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.

• Špinavá čtení: Když saga nebo transakce čte data, která upravila jiná saga, ale tato změna ještě není dokončena.

• Fuzzy neboli neopakovatelná čtení: Když různé kroky v ságě čtou nekonzistentní data, protože mezi jednotlivými č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žijte zámky na úrovni aplikace, pokud kompenzovatelná transakce v rámci sagy používá semafor k označení, že aktualizace právě 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ý pohled: Změňte sled kroků ságy tak, aby aktualizace dat probíhaly v opakovatelných transakcích a eliminovalo se tak špinavé čtení. Jinak by jedna sága mohla číst špinavá data nebo nepotvrzené změny, zatímco jiná sága současně provede kompenzační transakci, aby vrátila 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 spusťte ságu znovu.

• 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ěžnost založená na riziku podle hodnoty: Dynamicky zvolte 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

• cloudové datové vzory

Související prostředky

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

• Vzor choreografie zajišťuje, že se každá součást systému podílí na rozhodovacím procesu o průběhu obchodní transakce, namísto spoléhání se na centrální řídicí bod.

• 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.

• Vzor Circuit Breaker řeší selhání, jejichž zotavení při připojení ke vzdálené službě nebo prostředku trvá různě dlouho. Tento model může zlepšit stabilitu a odolnost aplikace.

• Vzor monitorování koncových bodů stavu zavádí v aplikaci funkční kontroly, ke kterým mohou externí nástroje v pravidelných intervalech přistupovat prostřednictvím zveřejněných koncových bodů. Tento model vám může pomoct ověřit, že aplikace a služby fungují správně.