Specifikace XA
XA je specifikace rozhraní (tj. rozhraní funkce) mezi transakčním middleware a databází definovanou X/Open DTP, kterou transakční middleware používá k informování databáze o zahájení, koncu, potvrzení, návratu atd. transakcí. Funkce rozhraní XA poskytují výrobci databází. Dohoda o podřízení druhého řádu a dohoda o podřízení třetího řádu byly odvozeny z této myšlenky. Lze říci, že dvoustupňové commity jsou ve skutečnosti klíčem k implementaci XA distribuovaných transakcí (přesněji: dvoustupňové commity hlavně zajišťují atomicitu distribuovaných transakcí: tedy všechny uzly buď dělají vše, nebo nic)
2PC
Dvoufázový commit označuje algoritmus navržený tak, aby udržoval konzistenci transakčních commitů pro všechny uzly založený na architektuře distribuovaného systému v oblasti počítačových sítí a databází. Často se dvoustupňový commit také označuje jako protokol. V distribuovaném systému může každý uzel znát úspěch nebo neúspěch své vlastní operace, ale nemůže znát úspěch nebo neúspěch operací ostatních uzlů. Když transakce zasahuje do více uzlů, je nutné zavést komponentu, která funguje jako koordinátor, která řídí výsledky všech uzlů (tzv. účastníků) a nakonec tyto uzly instruuje, aby výsledky skutečně odesílaly (například zápisem aktualizovaných dat na disk atd.). Myšlenku algoritmu dvoufázového podání lze tedy shrnout takto: účastníci informují koordinátora o úspěchu nebo neúspěchu operace a koordinátor pak na základě zpětné vazby všech účastníků rozhodne, zda operaci odevzde, nebo ji zruší. Takzvané dvě fáze jsou: první fáze: fáze přípravy (fáze hlasování) a druhá fáze: fáze podání (fáze realizace).
Přípravná fáze
Koordinátor transakcí (správce transakcí) pošle každému účastníkovi (správci zdrojů) zprávu Připravit, a každý účastník buď přímo vrátí selhání (například neúspěšné ověření oprávnění), nebo transakci provede lokálně, zapíše lokální záznamy o opakování a vrácení zpět, ale neprovede závazek a dosáhne stavu "vše je připraveno, dluží se pouze východní vítr".
Přípravná fáze se dále rozděluje do následujících tří kroků:
1) Koordinační uzel se zeptá všech účastníků, zda mohou provést hlasování, a začne čekat na odpověď od každého účastníka.
2) Účastník provádí všechny transakční operace až do zahájení dotazu a zapisuje informace Undo a Redo do logu. (Poznámka: Pokud je úspěšný, každý účastník již provedl transakční operaci)
3) Každý účastník reaguje na dotaz zahájený koordinačním uzlem. Pokud je transakční operace účastníka uzlu skutečně úspěšně provedena, vrátí zprávu "Souhlasím"; Pokud transakční operace účastníka uzlu skutečně selže, vrátí se zpráva "zrušeno".
Fáze podání Pokud koordinátor obdrží zprávu o selhání nebo timeoutu od účastníka, pošle zprávu o vrácení zpět přímo každému účastníkovi. Jinak pošlete Commit zprávu; Účastníci provádějí operace commit nebo rollback podle pokynů koordinátora, aby uvolnili všechny zámkové zdroje použité v transakčním procesu. (Poznámka: Zámkové zdroje musí být uvolněny v závěrečné fázi)
Dále je samostatně diskutován proces podání ve dvou případech.
Když odpovídající zpráva přijatá koordinačním uzlem od všech zúčastněných uzlů je Souhlas:
Fáze podání Pokud koordinátor obdrží zprávu o selhání nebo timeoutu od účastníka, pošle zprávu o vrácení zpět přímo každému účastníkovi. Jinak pošlete Commit zprávu; Účastníci provádějí operace commit nebo rollback podle pokynů koordinátora, aby uvolnili všechny zámkové zdroje použité v transakčním procesu. (Poznámka: Zámkové zdroje musí být uvolněny v závěrečné fázi)
Dále je samostatně diskutován proces podání ve dvou případech.
Když odpovídající zpráva přijatá koordinačním uzlem od všech zúčastněných uzlů je Souhlas:
1) Koordinační uzel vydá požadavek "commit" všem účastníkům.
2) Účastník oficiálně dokončí operaci a uvolní zdroje obsazené během celého období transakce.
3) Účastník odešle koordinačnímu uzlu zprávu "Hotovo".
4) Koordinační uzel dokončí transakci po obdržení zpětné vazby "Hotovo" od všech zúčastněných uzlů. Pokud některý z účastníků vrátí odpověď "Přerušeno" v první fázi, nebo pokud koordinační uzel nedokáže získat odpověď pro všechny účastníky před vypršením dotazu v první fázi:
1) Koordinační uzel vysílá požadavek "rollback" všem účastníkům.
2) Účastník využívá dříve napsané informace Undo k provedení rollbacku a uvolnění zdrojů obsazených během transakčního období.
3) Účastník odešle koordinačnímu uzlu vzkaz "rollback complete".
4) Koordinační uzel zruší transakci po obdržení zpětné vazby "Rollback Complete" od všech zúčastněných uzlů. Bez ohledu na konečný výsledek druhá fáze ukončuje současnou transakci. Commity fáze 2 se zdají poskytovat atomové operace, ale bohužel commity fáze 2 mají stále několik nevýhod:
1. Problém synchronního blokování. Během provádění všechny zúčastněné uzly blokují transakce. Když účastník obsadí veřejný zdroj, musí být ostatní třetí strany blokovány v přístupu k veřejnému zdroji.
2. Jediný bod selhání. Kvůli důležitosti koordinátora, jakmile koordinátor selže. Účastníci budou pokračovat v blokování blokace. Zvláště ve druhé fázi, pokud koordinátor selže, jsou všichni účastníci stále ve stavu uzamčení transakčních zdrojů a nemohou pokračovat v dokončení transakčních operací. (Pokud koordinátor zavěsí, můžete koordinátora znovu zvolit, ale to nevyřeší problém, že je účastník zablokován kvůli nefunkčnímu koordinátorovi)
3. Nekonzistence dat. Ve druhé fázi druhé fáze commitu, když koordinátor odešle požadavek na commit účastníkovi, dojde k výjimce v lokální síti nebo koordinátor selže během procesu commit request, což způsobí, že požadavek commit přijmou pouze někteří účastníci. Po obdržení požadavku na commit tito účastníci provedou operaci commit. Jiné stroje, které nepřijmou požadavek na commit, však nemohou commit transakce provést. V důsledku toho dochází ke konzistenci datového oddělení v celém distribuovaném systému.
4. Problémy, které nelze vyřešit ve druhé fázi: Koordinátor padne po odeslání commit zprávy a jediný účastník, který tuto zprávu obdrží, je také dole. Takže i když facilitátor zvolí nového facilitátora prostřednictvím volební dohody, stav transakce je nejistý a nikdo neví, zda byla realizována. Kvůli nedostatkům druhé fáze podání, jako je synchronní blokování, problém s jedním bodem a rozštěpení mozku, výzkumníci provedli zlepšení na základě druhé fáze podání a navrhli třífázové podání.
3PC
Třífázový commit, známý také jako protokol třífázového commitu, je vylepšenou verzí dvoufázového commitu (2PC).
Na rozdíl od dvoustupňových commitů existují u třístupňových commitů dvě změny.
1. Zavést mechanismus timeoutu. Současně je zaveden mechanismus timeoutu jak u facilitátora, tak u účastníků. 2. Vložit přípravnou fázi do první a druhé fáze. To zajišťuje, že stav všech zúčastněných uzlů je konzistentní až do finální fáze potvrzení. Jinými slovy, kromě zavedení mechanismu timeoutu 3PC opět rozděluje přípravnou fázi 2PC na dvě části, takže ve třech fázích commit jsou tři fáze CanCommit, PreCommit a DoCommit.
Fáze CanCommit
Fáze CanCommit ve 3PC je ve skutečnosti velmi podobná přípravné fázi 2PC. Koordinátor odešle účastníkovi žádost o commit, který odpoví ano, pokud může commitovat, nebo Ne. 1. Dotaz na transakci Facilitátor odesílá účastníkovi požadavek CanCommit. Zeptejte se, jestli můžete provést operaci potvrzení transakce. Pak začněte čekat na reakci od účastníků. 2. Zpětná vazba k odpovědi Po obdržení požadavku CanCommit účastník vrátí odpověď ano a vstoupí do stavu připravenosti, pokud si myslí, že transakce může být provedena hladce. Jinak zpětná vazba. Ne.
Fáze PreCommit
Facilitátor rozhoduje, zda si zapamatuje operaci PreCommit transakce na základě reakce účastníka. V závislosti na odpovědi existují dvě možnosti. Pokud je zpětná vazba, kterou facilitátor obdrží od všech účastníků, odpovídá ano, pak je provedeno předběžné provedení transace.
1. Odeslat požadavek na předběžný závazek Facilitátor odesílá požadavek účastníkovi a pokračuje do fáze přípravy.
2. Předběžné potvrzení transakce Po obdržení požadavku na předběžný závazek účastník provede transakční operaci a zaznamená informace o vrácení a opakování do logu transakcí.
3. Zpětná vazba od odpovědi Pokud účastník úspěšně provede transakční operaci, je vrácena odpověď ACK při zahájení čekání na finální instrukci. Pokud některý účastník odešle koordinátorovi odpověď Ne, nebo počká na časový limit, a koordinátor od účastníka nedostane odpověď, transakce je přerušena.
1. Odeslat požadavek na přerušení Facilitátor odešle žádost o přerušení všem účastníkům.
2. Přerušení transakce Poté, co účastník obdrží požadavek ABORT od koordinátora (nebo po uplynutí timeoutu, pokud žádost od koordinátora nebyla přijata), je přerušení transakce provedeno. fáze doCommit
Tato fáze skutečného transakčního závazku může být také rozdělena do následujících dvou situací.
Proveďte commit
1. Odeslat požadavek na commit Koordinace přijme ACK odpověď zaslanou účastníkem, poté přejde ze stavu předcommit do stavu commit. a poslat doCommit požadavek všem účastníkům.
2. Odeslání transakce Po obdržení požadavku doCommit účastník provede formální transakční commit. a po dokončení transakčního potvrzení uvolnit všechny transakční zdroje.
3. Reagujte na zpětnou vazbu Po odeslání transakce pošlete koordinátorovi odpověď Ack.
4. Dokončení transakce Po obdržení odpovědi ACK od všech účastníků je transakce dokončena. Přerušovací transakce
Pokud koordinátor neobdrží od účastníka odpověď ACK (nemusí to být odpověď ACK od příjemce, nebo může být odpověď časově vypršela), pak je přerušovací transakce vykonána.
1. Odeslat požadavek na přerušení Facilitátor odesílá žádost o přerušení všem účastníkům
2. Vrácení zpět transakce Po obdržení požadavku ABORT účastník použije informace o vrácení vrácení zaznamenáné ve fázi 2 k provedení operace vrácení transakce a po dokončení vrácení zpět uvolní všechny transakční zdroje.
3. Výsledky zpětné vazby Po dokončení návratu transakce účastníkem odešlete koordinátorovi zprávu ACK
4. Přerušit transakci Poté, co koordinátor obdrží zprávu ACK od účastníka, je transakce přerušena. Ve fázi doCommit, pokud účastník nemůže včas obdržet žádost o doCommit nebo rebort od koordinátora, transakce bude pokračovat v odesílání i po uplynutí timeoutu. (Ve skutečnosti by to mělo být určeno na základě pravděpodobnosti, že při vstupu do třetí fáze to znamená, že účastník obdržel požadavek na PreCommit ve druhé fázi, takže předpokladem pro generování požadavku na PreCommit pro koordinátora je, že obdrží odpověď Yes CanCommit od všech účastníků před začátkem druhé fáze.) (Jakmile účastník obdrží PreCommit, znamená to, že ví, že všichni skutečně souhlasí s úpravou.) Takže jednoduše řečeno, při vstupu do třetí fáze, kvůli timeoutům sítě a dalším důvodům, i když účastník neobdržel odpověď commit nebo abort, má důvod se domnívat, že pravděpodobnost úspěšného commitu je velmi vysoká. )
Rozdíl mezi 2PC a 3PC
Ve srovnání s 2PC se 3PC hlavně řeší problém jediného bodu selhání a snižuje blokování, protože jakmile účastník nestihne včas obdržet zprávu od koordinátora, automaticky provede commit. Místo toho, abyste neustále drželi transakční zdroje a byli v blokujícím stavu. Tento mechanismus však také způsobuje problémy s konzistencí dat, protože odpověď na přerušení odeslaná koordinátorem není účastníkem včas přijata kvůli síťovým důvodům, a poté účastník provede operaci potvrzení po čekání na časový limit. To vytváří nesrovnalosti dat s ostatními účastníky, kteří obdrží příkaz k přerušení a provedou rollback.
|