Pokud použijete nakonec konzistentní operaci, která se skládá z řady kroků, může být užitečný model kompenzační transakce. Konkrétně, pokud jeden nebo více kroků selžou, můžete pomocí modelu kompenzační transakce vrátit zpět práci, kterou kroky provedly. Obvykle zjistíte operace, které následují podle modelu konečné konzistence v aplikacích hostovaných v cloudu, které implementují složité obchodní procesy a pracovní postupy.
Kontext a problém
Aplikace, které běží v cloudu, často upravují data. Tato data se někdy šíří mezi různými zdroji dat v různých geografických umístěních. Pokud chcete zabránit kolizím a zlepšit výkon v distribuovaném prostředí, neměla by se aplikace pokoušet o poskytování silné konzistence transakcí. Místo toho by aplikace měla implementovat konečnou konzistenci. V modelu konečné konzistence se typická obchodní operace skládá z řady samostatných kroků. I když operace provádí tyto kroky, celkové zobrazení stavu systému může být nekonzistentní. Jakmile se ale operace dokončí a všechny kroky se spustí, měl by se systém znovu shodovat.
Úvod do konzistence dat poskytuje informace o tom, proč se distribuované transakce dobře škálují. Tento prostředek také uvádí principy modelu konečné konzistence.
Problémem v modelu konečné konzistence je zpracování kroku, který selže. Po selhání může být potřeba vrátit zpět veškerou práci, kterou předchozí kroky v operaci dokončily. Nemůžete ale vždy vrátit zpět data, protože jiné souběžné instance aplikace ho mohly změnit. I v případech, kdy souběžné instance nezměnily data, může být vrácení kroku složitější než obnovení původního stavu. Může být nutné použít různá obchodní pravidla. Například se podívejte na cestovní web, který část Příklad popisuje dále v tomto článku.
Pokud operace, která implementuje konečnou konzistenci, zahrnuje několik heterogenních úložišť dat, vrácení kroků v operaci zpět vyžaduje, aby bylo možné navštívit každé úložiště dat. Chcete-li zabránit tomu, aby systém zůstal nekonzistentní, musíte spolehlivě vrátit zpět práci, kterou jste provedli v každém úložišti dat.
Data ovlivněná operací, která implementuje konečnou konzistenci, se vždy neuchovává v databázi. Představte si například prostředí architektury orientované na služby (SOA). Operace SOA může vyvolat akci ve službě a způsobit změnu stavu, který tato služba uchovává. Pokud chcete operaci vrátit zpět, musíte tuto změnu stavu vrátit zpět. Tento proces může zahrnovat opětovné vyvolání služby a provedení další akce, která obrátí účinky první.
Řešení
Řešením je implementace kompenzační transakce. Kroky v kompenzační transakci vrátí zpět účinky kroků v původní operaci. Intuitivním přístupem je nahradit aktuální stav stavem, ve který byl systém na začátku operace. Kompenzační transakce ale nemůže tento přístup vždy přijmout, protože může přepsat změny, které provedly jiné souběžné instance aplikace. Místo toho musí být kompenzační transakce inteligentním procesem, který bere v úvahu veškerou práci, kterou provádí souběžné instance. Tento proces je obvykle specifický pro aplikaci, který vychází z povahy práce, kterou původní operace provádí.
Běžným přístupem je použití pracovního postupu pro implementaci operace s konečnou konzistencí, která vyžaduje kompenzaci. Vzhledem k tomu, že původní operace pokračuje, systém zaznamenává informace o jednotlivých krocích, včetně toho, jak vrátit zpět práci, kterou krok provede. Pokud se operace v libovolném okamžiku nezdaří, pracovní postup se vrátí zpět pomocí kroků, které dokončil. V každém kroku pracovní postup provádí práci, která tento krok obrátí.
Mezi důležité body patří:
- Kompenzační transakce nemusí muset vrátit zpět práci v přesném obráceném pořadí původní operace.
- Některé kroky pro vrácení zpět je možné provést paralelně.
Tento přístup je podobný strategii Sagas, která je popsána v blogu Clemens Vasters.
Kompenzační transakce je nakonec konzistentní operace sama, takže může také selhat. Systém by měl být schopen obnovit kompenzační transakci v bodě selhání a pokračovat. Může být nutné zopakovat krok, který selže, takže byste měli definovat kroky v kompenzační transakci jako idempotentní příkazy. Další informace najdete v tématu Idempotency Patterns na blogu Jonathana Olivera.
V některých případech může být ruční zásah jediným způsobem, jak se zotavit z kroku, který selhal. V těchto situacích by systém měl vyvolat výstrahu a poskytnout co nejvíce informací o příčině selhání.
Problémy a důležité informace
Při rozhodování o implementaci tohoto modelu zvažte následující body:
Nemusí být snadné určit, kdy krok v operaci, která implementuje konečnou konzistenci, selže. Krok nemusí okamžitě selhat. Místo toho se může zablokovat. Možná budete muset implementovat mechanismus vypršení časového limitu.
Logiku kompenzace není snadné generalizovat. Kompenzační transakce je specifická pro aplikaci. Spoléhá na to, že aplikace má dostatek informací, aby bylo možné účinky jednotlivých kroků v nezdařené operaci vrátit zpět.
Kroky v kompenzační transakci byste měli definovat jako idempotentní příkazy. Pokud to uděláte, je možné kroky opakovat, pokud kompenzační transakce selže.
Infrastruktura, která zpracovává kroky, musí splňovat následující kritéria:
- Je odolný v původní operaci a v kompenzační transakci.
- Nepřijde o informace potřebné ke kompenzaci neúspěšného kroku.
- Spolehlivě monitoruje průběh logiky kompenzace.
Kompenzační transakce nemusí nutně vracet systémová data do stavu na začátku původní operace. Místo toho transakce kompenzuje práci, kterou operace úspěšně dokončila před selháním.
Pořadí kroků v kompenzační transakci nemusí nutně být přesným opakem kroků v původní operaci. Jedno úložiště dat může být například citlivější na nekonzistence než jiné. Nejprve by měly proběhnout kroky v kompenzační transakci, které vrátí zpět změny v tomto úložišti.
Určitá opatření můžou pomoct zvýšit pravděpodobnost, že celková aktivita bude úspěšná. Konkrétně můžete u každého prostředku, který je nutný k dokončení operace, umístit krátkodobý zámek založený na časovém limitu. Tyto prostředky můžete získat také předem. Pak proveďte práci až po získání všech prostředků. Dokončete všechny akce před vypršením platnosti zámků.
Logika opakování, která je více odpustit než obvykle, může pomoct minimalizovat selhání, která aktivují kompenzační transakci. Pokud krok v operaci, která implementuje konečnou konzistenci, selže, zkuste chybu zpracovat jako přechodnou výjimku a opakujte krok. Zastavte operaci a zahajte kompenzační transakci jenom v případě, že se krok opakovaně nezdaří nebo nejde obnovit.
Při implementaci kompenzační transakce čelíte mnoha stejným výzvám, kterým čelíte při implementaci konečné konzistence. Další informace najdete v části "Důležité informace o implementaci konečné konzistence" v úvodu do konzistence dat.
Kdy se má tento model použít
Tento model používejte jenom pro operace, které je nutné při jejich selhání vrátit zpět. Pokud je to možné, navrhujte řešení, která nebudou vyžadovat složité kompenzační transakce.
Návrh úloh
Architekt by měl vyhodnotit způsob použití modelu kompenzační transakce v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:
| Pilíř | Jak tento model podporuje cíle pilíře |
|---|---|
| Rozhodnutí o návrhu spolehlivosti pomáhají vaší úloze stát se odolnou proti selhání a zajistit, aby se po selhání obnovila do plně funkčního stavu. | Akce kompenzace řeší poruchy kritických cest úloh pomocí procesů, jako jsou přímé vrácení změn dat, rozbíjející zámky transakcí nebo dokonce provádění chování nativního systému k obrácení účinku. - RE:02 Kritické toky - RE:09 Zotavení po havárii |
Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.
Příklad
Zákazníci používají cestovní web k rezervaci itinerářů. Jeden itinerář se může skládat z řady letů a hotelů. Zákazník, který cestuje ze Seattlu do Londýna a pak do Paříže, může při vytváření itineráře provést následující kroky:
- Rezervace letenky na let F1 ze Seattlu do Londýna
- Rezervace letenky na let F2 z Londýna do Paříže
- Rezervace letenky na let F3 z Paříže do Seattlu
- Rezervace pokoje v hotelu H1 v Londýně
- Rezervace pokoje v hotelu H2 v Paříži
Každý krok je sice samostatnou akcí, ale tyto kroky tvoří operaci s konečnou konzistencí. Kromě provedení těchto kroků musí systém také zaznamenávat operace čítače pro vrácení jednotlivých kroků zpět. Tyto informace jsou potřeba v případě, že zákazník zruší itinerář. Kroky potřebné k provedení operací čítače se pak můžou spustit jako kompenzační transakce.
Kroky v kompenzační transakci nemusí být přesným opakem původních kroků. Logika v každém kroku kompenzační transakce také musí brát v úvahu obchodní pravidla. Zrušení rezervace letu například nemusí zákazníka opravovat k úplné refundaci.
Následující obrázek znázorňuje kroky v dlouhotrvající transakci pro rezervaci cestovního itineráře. Zobrazí se také kroky kompenzační transakce, které transakci vrátí zpět.
Poznámka:
V závislosti na způsobu návrhu kompenzační logiky pro jednotlivé kroky můžete být schopni provádět kroky v kompenzační transakci paralelně.
V mnoha obchodních řešeních selhání jednoho kroku nemusí vždy vyžadovat vrácení systému zpět pomocí kompenzační transakce. Představte si například scénář cestovního webu. Předpokládejme, že zákazník rezervuje lety F1, F2 a F3, ale nemůže si rezervovat pokoj v hotelu H1. Místo zrušení letů je vhodnější nabídnout zákazníkovi pokoj v jiném hotelu ve stejném městě. Zákazník se stále může rozhodnout zrušit. V takovém případě se kompenzační transakce spustí a vrátí rezervace pro lety F1, F2 a F3. Zákazník by ale měl toto rozhodnutí učinit, ne systém.
Další kroky
- Úvod do konzistence dat. Model kompenzační transakce se často používá ke zrušení operací, které implementují model konečné konzistence. Tento úvod poskytuje informace o výhodách a kompromisech konečné konzistence.
- Vzory idempotence. V kompenzační transakci je nejlepší použít idempotentní příkazy. Tento blogový příspěvek popisuje faktory, které je potřeba zvážit při implementaci idempotence.
Související prostředky
- Model Scheduler Agent Supervisor Tento článek popisuje, jak implementovat odolné systémy, které provádějí obchodní operace, které používají distribuované služby a prostředky. V těchtosystémechch
- Model opakování. Kompenzační transakce mohou být výpočetně náročné. Můžete se pokusit minimalizovat jejich použití pomocí vzoru Opakování a implementovat efektivní zásady opakování neúspěšných operací.
- Model distribuovaných transakcí Saga Tento článek vysvětluje, jak pomocí vzoru Saga spravovat konzistenci dat napříč mikroslužbami ve scénářích distribuovaných transakcí. Model Saga zpracovává zotavení po selhání s kompenzačními transakcemi.
- Vzorky kanálů a filtrů Tento článek popisuje model Kanály a filtry, který můžete použít k dekompilování úlohy komplexního zpracování do řady opakovaně použitelných prvků. Model Kanály a filtry můžete použít s modelem kompenzační transakce jako alternativu k implementaci distribuovaných transakcí.
- Vytvořte návrh pro samoopravení. Tato příručka vysvětluje, jak navrhovat samoopravené aplikace. Kompenzační transakce můžete použít jako součást samoopraveného přístupu.