Transakcja rozproszona

Transakcja rozproszona obejmuje operacje na więcej niż jednym serwerze, koordynowane przez menedżera transakcji.

Zakres i cel transakcji rozproszonej

Transakcja rozproszona to logicznie spójny zestaw operacji wykonywanych w więcej niż jednym zasobie przetwarzającym, na przykład w kilku bazach danych, usługach albo węzłach systemu. Jej celem jest zachowanie jednej decyzji dotyczącej całości operacji: wszystkie uczestniczące zasoby mają zatwierdzić swoje zmiany albo wszystkie mają je wycofać. Dzięki temu nie powstaje stan, w którym tylko część wymaganych zapisów została utrwalona.

W typowym modelu każdy uczestnik transakcji zarządza własnymi lokalnymi operacjami, natomiast koordynator, nazywany także menedżerem transakcji, prowadzi uzgodnienie wyniku. Uczestnikiem może być między innymi konkretny serwer bazy danych lub inny zasób obsługujący transakcyjny protokół. Koordynator musi znać listę uczestników, przekazać im żądanie rozpoczęcia pracy, zebrać informacje o możliwości zatwierdzenia oraz doprowadzić do wspólnego zakończenia.

Przebieg protokołu zatwierdzania dwóch faz

Najczęściej opisywanym mechanizmem koordynacji jest two-phase commit, czyli protokół zatwierdzania w dwóch fazach. W pierwszej fazie koordynator wysyła uczestnikom żądanie przygotowania. Każdy uczestnik wykonuje swoje operacje, sprawdza warunki lokalne i zabezpiecza informacje potrzebne do późniejszego zatwierdzenia. Jeżeli może zakończyć operację pomyślnie, odpowiada „prepared” albo równoważnym komunikatem gotowości. Odpowiedź negatywna oznacza, że wspólne zatwierdzenie nie może nastąpić.

W drugiej fazie koordynator analizuje wszystkie odpowiedzi. Gdy każdy uczestnik potwierdzi gotowość, koordynator rozsyła decyzję commit. Uczestnicy utrwalają zmiany i zwalniają lokalne zasoby. Jeżeli choć jeden uczestnik zgłosi błąd, przekroczenie limitu czasu lub brak możliwości przygotowania, koordynator wysyła decyzję rollback albo abort. Uczestnicy wycofują swoje lokalne zmiany. Istotną cechą tego protokołu jest rozdzielenie momentu przygotowania od momentu ostatecznego zatwierdzenia.

Awaria, blokowanie i ślady diagnostyczne

Transakcja rozproszona wymaga obsługi awarii komunikacji, niedostępności uczestnika oraz ponowienia wiadomości. W protokole two-phase commit uczestnik, który osiągnął stan prepared, może czekać na decyzję koordynatora. Jeżeli połączenie z koordynatorem zostanie przerwane, sam uczestnik nie zawsze może bezpiecznie zdecydować, czy zatwierdzić, czy wycofać operację. Taki stan może utrzymywać blokady i inne zasoby lokalne, dopóki decyzja nie zostanie odzyskana z logu koordynatora albo przekazana ponownie.

Podczas analizy problemu należy rozdzielić błąd wykonania operacji od błędu koordynacji. Ważne są czasy rozpoczęcia i zakończenia, identyfikator transakcji, lista uczestników, odpowiedzi prepare, decyzja końcowa oraz przyczyna przerwania. Sam komunikat o nieudanym zapisie nie dowodzi jeszcze niespójności, ponieważ uczestnicy mogą później otrzymać decyzję rollback. Z kolei rozbieżne decyzje commit i rollback dla tego samego identyfikatora wskazują na poważne uszkodzenie mechanizmu koordynacji lub odtworzenia stanu.

Praktycznym zagrożeniem są także opóźnienia i częściowa utrata komunikatów. Ponowienie żądania nie powinno tworzyć drugiej, niezależnej operacji. Uczestnik powinien rozpoznawać identyfikator transakcji i traktować powtórzoną wiadomość zgodnie z aktualnym stanem protokołu. Rejestrowanie decyzji w trwałym dzienniku pozwala odtworzyć przebieg po restarcie procesu. Diagnostyka powinna obejmować również zegary systemowe, ponieważ niespójne znaczniki czasu utrudniają ustalenie kolejności zdarzeń.

Granice stosowania i konsekwencje projektowe

Transakcja rozproszona nie jest prostym zamiennikiem pojedynczej transakcji lokalnej. Uczestnicy muszą obsługiwać wspólny protokół, trwałe stany pośrednie, ponawianie komunikatów i odtwarzanie decyzji po awarii. Koszt obejmuje dodatkową wymianę komunikatów, dłuższe przetrzymywanie blokad oraz zależność od dostępności koordynatora. Im większa liczba uczestników i im bardziej zawodna sieć, tym większe znaczenie mają limity czasu, procedury odzyskiwania oraz poprawne zamykanie transakcji.

W systemach, w których nie można użyć wspólnego protokołu zatwierdzania, spójność bywa osiągana przez osobne operacje, zdarzenia kompensujące i jednoznaczne identyfikatory prób. Takie podejście nie daje automatycznie identycznych właściwości jak atomowe zatwierdzenie, dlatego wymaga precyzyjnego opisu stanów pośrednich i obsługi ponowień. Podczas diagnostyki trzeba ustalić, czy problem dotyczy lokalnej bazy, komunikacji, koordynatora, czy błędnego założenia, że każda operacja została wykonana atomowo na wszystkich serwerach.