H. Garcia-Molina i K. Salem. 1987. Sagi . W Proceedings of 1987 ACM SIGMOD międzynarodowej konferencji na temat zarządzania danymi (SIGMOD '87). Association for Computing Machinery, Nowy Jork, NY, USA, 249–259.

Słowa kluczowe: długotrwałe procesy, sagi, transakcje, rekompensata, łagodzenie awarii, tolerancja awarii, przejrzystość awarii

Chociaż oryginalny artykuł na temat Sag został napisany 35 lat temu, problem jest nadal tak samo aktualny. W tym poście omówiono pochodzenie koncepcji sag, długotrwałych procesów obejmujących wiele transakcji bazodanowych.

Wstęp

W swoim artykule Sagas, Hector Garcia-Molina i Kenneth Salem wprowadzają koncepcję sag do realizacji „długotrwałych” operacji.

Molina i Salem odnoszą się do procesów, które składają się z jednego etapu, jako „krótkotrwałe” lub „krótkotrwałe”, a procesy, które składają się z wielu etapów, jako „długotrwałe” lub „długotrwałe”. Dlatego też krótkie lub długie przebiegi nie są stwierdzeniem dotyczącym czasu fizycznego, ale stwierdzeniem dotyczącym czasu logicznego, w którym każdy krok jest tykaniem zegara (Rysunek 1).

Problem

W ekosystemie, który w dużej mierze odrzuca ideę transakcji rozproszonych lub utrzymywania blokad przez dłuższy czas, żaden długotrwały proces nie może być po prostu zmapowany na długotrwałą, rozproszoną transakcję. Zamiast tego potrzebujemy innego mechanizmu do komponowania długotrwałych procesów z krótkoterminowych, nierozproszonych transakcji.

Artykuł definiuje proces P jako sekwencję kroków a, b itd., gdzie każdy krok jest transakcją bazy danych. Używając bardziej znanych terminów, możesz myśleć o procesie jako o funkcji, a sekwencję kroków jako o sekwencji wywołań API do bazy danych.

Odwołujemy się do sekwencji kroków a, b itd. jako śladu:

trace(P) = a • b • …

Innymi słowy: Sekwencja dwóch transakcji nie jest transakcją!

Trywialnie, jeśli proces składa się z pojedynczej transakcji, proces wykazuje gwarancje niepodzielności transakcji (Rysunek 3).

Jeśli jednak proces składa się z wielu transakcji, proces nie wykazuje gwarancji niepodzielności transakcji: proces może zostać wykonany częściowo (Rysunek 4).

Jednak w przeciwieństwie do innych transakcji, transakcje procesu są ze sobą powiązane i powinny być wykonywane jako całość, wszelkie częściowe wykonania procesu są niepożądane.

Artykuł omawia aplikację do rezerwacji podróży, w której podróż składa się z wielu lotów potencjalnie różnymi liniami lotniczymi. W tym przypadku rezerwacja wycieczki obejmuje wiele transakcji, po jednej na etap podróży. Jako podróżujący chcemy, aby wszystkie transakcje były realizowane jako całość: albo chcemy zarezerwować wszystkie loty, albo nie rezerwować żadnych lotów, rezerwacja niektórych lotów jest niedopuszczalna.

Rozwiązanie

Artykuł przedstawia Sagas, protokół implementacji długotrwałych procesów. Protokół Saga zapewnia, że ​​proces jest atomowy, to znaczy proces jest wykonywany w zauważalny sposób równoważny całkowicie lub wcale.

Aby złagodzić częściowe wykonanie, proces może wdrożyć odtwarzanie do przodu lub do tyłu [2]:

Odzyskiwanie do przodu

Odzyskiwanie po awarii w przód odnosi się do strategii łagodzenia skutków awarii, które przenoszą system ze stanu pośredniego do stanu równoważnego ze stanem końcowym (przesuwając proces do przodu).

Odzyskiwanie wsteczne

Odzyskiwanie wsteczne po awarii odnosi się do strategii łagodzenia skutków awarii, które przenoszą system ze stanu pośredniego do stanu równoważnego ze stanem początkowym (cofanie procesu).

Odzyskiwanie wsteczne i odszkodowanie

Aby umożliwić odtwarzanie wsteczne, każdy proces powinien zarejestrować krok kompensacyjny dla każdego kroku (Rysunek 6).

Krok kompensujący cofa — z semantycznego punktu widzenia — krok, ale niekoniecznie przywraca bazę danych do stanu, który istniał w momencie rozpoczęcia kroku. Rekompensata przywróci świat do stanu, który jest akceptowalnym przybliżeniem stanu, jaki miał przed rozpoczęciem transakcji.

Na przykład, wracając do wniosku o rezerwację podróży, jeśli podróż składa się z dwóch lotów i rezerwacja pierwszego lotu powiodła się, ale rezerwacja drugiego lotu nie powiodła się, saga musi anulować pierwszą rezerwację, aby przywrócić bazę danych do akceptowalnego przybliżenia do stanu miał przed rozpoczęciem rezerwacji podróży.

Wykonanie

Tak więc w przypadku braku awarii proces P wytwarza pożądany ślad

trace(P) = s₁ • s₂ • … sₙ • ✔️

trace(P) = s₁ • s₂ • … sᵢ • × • cᵢ … • c₂ • c₁ • ✔️

Kiedy awaria przerywa Sagę, Saga musi być w stanie odzyskać swój obecny stan i przeprowadzić odtwarzanie do przodu lub do tyłu. Dlatego Saga musi być w stanie rejestrować początek Sagi, zakończenie Sagi oraz rejestrować punkty kontrolne i rekompensaty.

Jeśli jesteś właścicielem bazy danych, możesz rejestrować punkty kontrolne i rekompensaty transakcyjne na każdym kroku. Jeśli nie możesz rejestrować punktów kontrolnych i kompensacji transakcyjnie na każdym kroku, musisz opracować mechanizm niezawodnego rejestrowania kompensacji punktów kontrolnych.

Dyskusja

Chociaż artykuł został napisany ponad 35 lat temu, problem i Sagi jako proponowane rozwiązanie są nadal aktualne. Jednak uwaga została przesunięta z tworzenia transakcji bazy danych na tworzenie wywołań usług.

Należy pamiętać, że usługi nie wykazują właściwości transakcyjnych: usługi mogą nie być atomowe po wywołaniu usługi, a jeśli usługa ulegnie awarii, możesz nie wiedzieć, czy usługa zaczęła działać, czy nie.

Dlatego przed wywołaniem usługi należy zarejestrować akcję kompensacyjną i zaprojektować logikę kompensacji, aby była poprawna niezależnie od tego, czy usługa została uwzględniona, czy nie.

Wniosek

Sagi pozostają aktualne, pomimo znacznych postępów w teorii i praktyce od czasu publikacji artykułu. Podstawowa koncepcja Sagi jako protokołu do implementacji atomowości w środowisku rozproszonym w ramach transakcji lub usług, techniki opisane w artykule są nadal szeroko stosowane.

Bibliografia

• [1] Semantyka śladu dla długotrwałych transakcji, M. Butler, CAR Hoare & C. Ferreira, 2005
• [2] Radzenie sobie z niepowodzeniami od pierwszych zasad , Dominik Tornow, 2022