Specyfikacja XA
XA to specyfikacja interfejsu (czyli funkcja interfejsu) pomiędzy oprogramowaniem pośredniczącym transakcyjnym a bazą danych zdefiniowaną przez X/Open DTP, która jest wykorzystywana przez oprogramowanie pośrednicze transakcyjnego do powiadamiania bazy danych o rozpoczęciu, zakończeniu, zatwierdzeniu, cofnięciu itp. transakcji. Funkcje interfejsu XA są dostarczane przez dostawców baz danych.
Z tej idei wywodzi się porozumienie o podporządkowaniu drugiego rzędu oraz porozumienie o podporządkowaniu trzeciego rzędu. Można powiedzieć, że dwuetapowe commity są faktycznie kluczem do implementacji rozproszonych transakcji XA (dokładniej: dwuetapowe commity głównie zapewniają atomowość transakcji rozproszonych: to znaczy, wszystkie węzły wykonują albo wszystko, albo nic)
2PC
Zatwierdzenie dwufazowe odnosi się do algorytmu zaprojektowanego w celu utrzymania spójności w zatwierdzaniu transakcji dla wszystkich węzłów, opierając się na architekturze systemu rozproszonego w dziedzinie sieci komputerowych i baz danych. Często dwustopniowy commit nazywany jest również protokołem. W systemie rozproszonym każdy węzeł może znać sukces lub porażkę własnej operacji, ale nie może wiedzieć sukcesu lub porażki operacji innych węzłów. Gdy transakcja obejmuje wiele węzłów, aby utrzymać charakterystykę ACID, należy wprowadzić komponent pełniący rolę koordynatora, który kontroluje wyniki wszystkich węzłów (zwanych uczestnikami) i ostatecznie poleci tym węzłom faktyczne przesłanie wyników (np. zapisywanie zaktualizowanych danych na dysku itp.). Dlatego koncepcję algorytmu dwuetapowego zgłoszenia można podsumować następująco: uczestnicy powiadomią koordynatora o sukcesie lub porażce operacji, a następnie koordynator zdecyduje, czy zgłosić operację, czy ją przerwać na podstawie informacji zwrotnych wszystkich uczestników.
Tak zwane dwa etapy to: pierwszy etap: etap przygotowań (etap głosowania) oraz drugi etap: etap zgłoszenia (etap realizacji).
Etap przygotowań
Koordynator transakcji (menedżer transakcji) wysyła komunikat Prepare do każdego uczestnika (menedżera zasobów), a każdy uczestnik albo zwraca niepowodzenie bezpośrednio (np. nieudaną weryfikację uprawnień), albo wykonuje transakcję lokalnie, zapisuje lokalne logi redo i cofa, ale nie zatwierdza i osiąga stan "wszystko jest gotowe, tylko wiatr wschodni jest winien".
Etap przygotowań można dalej podzielić na następujące trzy etapy:
1) Węzeł koordynatora wszystkie węzły uczestników, czy mogą przeprowadzić głosowanie i zaczyna czekać na odpowiedź od każdego węzła uczestniczącego.
2) Węzeł uczestniczący wykonuje wszystkie operacje transakcyjne aż do momentu inicjacji zapytania i zapisuje informacje o Cofnięciu oraz Powtórzeniu do loga. (Uwaga: Jeśli się powiedzie, każdy uczestnik już wykonał operację transakcji)
3) Każdy węzeł uczestnika odpowiada na zapytanie zainicjowane przez węzeł koordynatora. Jeśli operacja transakcji węzła uczestniczącego faktycznie zostanie wykonana pomyślnie, zwraca wiadomość "Zgoda"; Jeśli operacja transakcji węzła uczestniczącego faktycznie się nie powiedzie, zwraca wiadomość "przerwana".
Etap poddania się
Jeśli koordynator otrzyma wiadomość o awarii lub przerwę od uczestnika, wysyła komunikat o cofaniu bezpośrednio do każdego uczestnika. W innym przypadku wyślij wiadomość Commit; Uczestnicy wykonują operacje zatwierdzania lub cofania zgodnie z instrukcjami koordynatora, aby zwolnić wszystkie zasoby blokady używane w procesie transakcji. (Uwaga: Zasoby Lock muszą zostać zwolnione na ostatnim etapie)
Następnie omówiono osobno proces etapu zgłoszenia w dwóch przypadkach.
Gdy odpowiadająca wiadomość odebraną przez węzeł koordynatora od wszystkich węzłów uczestników to Zgoda:
Etap poddania się
Jeśli koordynator otrzyma wiadomość o awarii lub przerwę od uczestnika, wysyła komunikat o cofaniu bezpośrednio do każdego uczestnika. W innym przypadku wyślij wiadomość Commit; Uczestnicy wykonują operacje zatwierdzania lub cofania zgodnie z instrukcjami koordynatora, aby zwolnić wszystkie zasoby blokady używane w procesie transakcji. (Uwaga: Zasoby Lock muszą zostać zwolnione na ostatnim etapie)
Następnie omówiono osobno proces etapu zgłoszenia w dwóch przypadkach.
Gdy odpowiadająca wiadomość odebraną przez węzeł koordynatora od wszystkich węzłów uczestników to Zgoda:
1) Węzeł koordynator wysyła żądanie "commit" do wszystkich węzłów uczestników.
2) Węzeł uczestniczący oficjalnie kończy operację i uwalnia zasoby zajęte przez cały okres transakcji.
3) Węzeł uczestniczący wysyła wiadomość "Wykonano" do węzła koordynatora.
4) Węzeł koordynatora kończy transakcję po otrzymaniu informacji zwrotnej "Wykonano" od wszystkich węzłów uczestniczących.
1) Węzeł koordynatora wysyła żądanie "cofnięcia" do wszystkich węzłów uczestniczących.
2) Węzeł uczestnika wykorzystuje wcześniej zapisane informacje Undo do cofnięcia i zwolnienia zasobów zajętych przez cały okres transakcji.
3) Węzeł uczestniczący wysyła wiadomość "rollback complete" do węzła koordynatora.
4) Węzeł koordynatora anuluje transakcję po otrzymaniu informacji zwrotnej "Rollback Complete" od wszystkich węzłów uczestników.
Commity fazy 2 rzeczywiście wydają się zapewniać operacje atomowe, ale niestety commity etapu 2 mają też kilka wad:
1. Problem blokowania synchronicznego. Podczas wykonywania wszystkie uczestniczące węzły blokują transakcje. Gdy uczestnik zajmuje publiczne zasoby, inne węzły zewnętrzne muszą być zablokowane przed dostępem do tego zasobu.
2. Pojedynczy punkt awarii. Ze względu na znaczenie koordynatora, gdy koordynator zawodzi. Uczestnicy będą nadal blokować blokadę. Szczególnie na drugim etapie, jeśli koordynator zawiodnie, wszyscy uczestnicy nadal są w stanie blokady zasobów transakcyjnych i nie mogą kontynuować realizacji operacji transakcyjnych. (Jeśli koordynator się rozłączy, możesz go ponownie wybrać, ale nie rozwiąże to problemu, że uczestnik jest zablokowany przez jego nieobecność)
3. Niespójność danych. W drugim etapie drugiego etapu zatwierdzania, gdy koordynator wysyła żądanie zatwierdzenia uczestnikowi, pojawia się wyjątek sieci lokalnej lub koordynator zawodzi podczas procesu żądania zatwierdzenia, co powoduje, że tylko część uczestników akceptuje żądanie zatwierdzenia. Po otrzymaniu żądania zatwierdzenia, ci uczestnicy wykonają operację zatwierdzenia. Jednak inne maszyny, które nie otrzymają żądania zatwierdzenia, nie mogą wykonać zatwierdzenia transakcji. W rezultacie spójność działu danych występuje w całym systemie rozproszonym.
4. Problemy, których nie da się rozwiązać na drugim etapie: Koordynator pada po wysłaniu wiadomości commit, a jedyny uczestnik, który ją otrzymuje, również nie działa. Nawet jeśli facylitator wybierze nowego facylitatora na mocy umowy wyborczej, status transakcji jest niepewny i nikt nie wie, czy transakcja została złożona.
3PC
Trzyfazowy zatwierdzenie, znany również jako protokół zatwierdzenia trójfazowego, jest ulepszoną wersją dwufazowego zatwierdzenia (2PC).
W przeciwieństwie do zatwierdzeń dwuetapowych, istnieją dwie zmiany w zatwierdzaniach trzyetapowych.
1. Wprowadź mechanizm timeoutu. Jednocześnie wprowadzany jest mechanizm time-outu zarówno u facylitatora, jak i uczestników.
2. Wstaw etap przygotowawczy do pierwszego i drugiego etapu. Zapewnia to, że stan wszystkich uczestniczących węzłów jest spójny aż do końcowego etapu zatwierdzenia.
Innymi słowy, oprócz wprowadzenia mechanizmu timeout, 3PC ponownie dzieli etap przygotowań 2PC na dwa, tak że w trzech etapach zatwierdzania występują trzy etapy: CanCommit, PreCommit i DoCommit.
Etap CanCommit
Etap CanCommit w 3PC jest w rzeczywistości bardzo podobny do etapu przygotowań w 2PC. Koordynator wysyła żądanie zatwierdzenia do uczestnika, który odpowiada Tak, jeśli może się zobowiązać, lub Nie.
1. Zapytanie o transakcję Facilitator wysyła żądanie CanCommit do uczestnika. Zapytaj, czy możesz wykonać operację zatwierdzania transakcji. Następnie zacznij czekać na odpowiedź od uczestników.
2. Feedback odpowiedzi Po otrzymaniu żądania CanCommit uczestnik zwraca odpowiedź "Tak" i wchodzi w stan gotowości, jeśli uzna, że transakcja może zostać przeprowadzona płynnie. W przeciwnym razie opinia Nie
Faza PreCommit
Facylitator decyduje, czy zapamiętać operację PreCommit transakcji na podstawie odpowiedzi uczestnika. W zależności od odpowiedzi są dwie możliwości.
Jeśli informacja zwrotna od wszystkich uczestników jest odpowiedzią Tak, to wstępne wykonanie transakcji jest wykonywane.
1. Wyślij prośbę o wstępne zatwierdzenie Facylitator wysyła żądanie wstępnego zatwierdzenia uczestnikowi i przechodzi do etapu przygotowania.
2. Wstępne zatwierdzenie transakcji Po otrzymaniu żądania PreCommit uczestnik wykonuje operację transakcyjną i rejestruje informacje o cofnięciu i ponownym zrobieniu w dzienniku transakcji.
3. Informacja zwrotna odpowiedzi Jeśli uczestnik pomyślnie wykona operację transakcji, odpowiedź ACK jest zwracana podczas oczekiwania na ostatnią instrukcję.
1. Wyślij żądanie przerwania Moderator wysyła żądanie przerwania wszystkim uczestnikom.
2. Przerwanie transakcji Po otrzymaniu przez uczestnika żądania ABORT od koordynatora (lub po upływie przerwy, gdy żądanie od koordynatora nie zostało odebrane), przerwanie transakcji zostaje wykonane.
Ten etap rzeczywistego zobowiązania transakcyjnego można również podzielić na następujące dwie sytuacje.
Wykonaj commit
1. Wyślij żądanie zatwierdzenia. Koordynujący przyjmuje odpowiedź ACK wysłaną przez uczestnika, a następnie przechodzi ze stanu wstępnego do stanu zatwierdzania. oraz wysłać żądanie doCommit do wszystkich uczestników.
2. Złożenie transakcji Po otrzymaniu żądania doCommit, uczestnik wykonuje formalne zatwierdzenie transakcji. oraz zwolnić wszystkie zasoby transakcyjne po zakończeniu zatwierdzenia transakcji.
3. Odpowiedz na opinie Po złożeniu transakcji wyślij odpowiedź Ack do koordynatora.
4. Zakończ transakcję Po otrzymaniu przez koordynatora odpowiedzi ACK od wszystkich uczestników transakcja zostaje zakończona.
Jeśli koordynator nie otrzyma odpowiedzi ACK od uczestnika (może to nie być odpowiedź ACK od odbiorcy lub odpowiedź może się skończyć), wtedy transakcja przerwania jest wykonywana.
1. Wyślij żądanie przerwania Facylitator wysyła żądanie przerwania do wszystkich uczestników
2. Cofnięcie transakcji Po otrzymaniu żądania ABORT uczestnik wykorzystuje informacje cofnięte zarejestrowane w Fazie 2 do wykonania operacji cofnięcia transakcji i po jej zakończeniu uwalnia wszystkie zasoby transakcyjne.
3. Wyniki informacji zwrotnej Po zakończeniu cofnięcia transakcji przez uczestnika należy wysłać komunikat ACK do koordynatora
4. Przerwanie transakcji Po otrzymaniu przez koordynatora wiadomości ACK od uczestnika, transakcja zostaje przerwana.
Różnica między 2PC a 3PC
W porównaniu do 2PC, 3PC głównie rozwiązuje problem pojedynczego punktu awarii i ogranicza blokowanie, ponieważ gdy uczestnik nie otrzyma wiadomości od koordynatora na czas, domyślnie wykonuje zatwierdzenie. Zamiast ciągle trzymać zasoby transakcyjne i być w stanie blokującym. Jednak ten mechanizm powoduje także problemy z spójnością danych, ponieważ odpowiedź przerwania wysyłana przez koordynatora nie jest odbierana przez uczestnika na czas z powodów sieciowych, a następnie uczestnik wykonuje operację zatwierdzenia po oczekiwaniu na czas. Powoduje to niespójności danych z innymi uczestnikami, którzy otrzymują polecenie przerwania i wykonują cofnięcie.
|
Opublikowano 17.03.2021 10:15:10
|
|
|
