XA-specifikation
XA är gränssnittsspecifikationen (dvs. gränssnittsfunktionen) mellan transaktionsmiddleware och databasen definierad av X/Open DTP, som används av transaktionsmiddleware för att meddela databasen om start, slut, commit, rollback, etc. av transaktioner. XA-gränssnittsfunktioner tillhandahålls av databasleverantörer.
Andraorderns inlämningsavtal och tredje ordningens inlämningsavtal härleddes från denna idé. Man kan säga att tvåstegscommits faktiskt är nyckeln till att implementera XA-distribuerade transaktioner (för att vara exakt: tvåstegscommits säkerställer främst atomiciteten hos distribuerade transaktioner: det vill säga, alla noder gör antingen allt eller inget)
2PC
Tvåfas-commit avser en algoritm som är utformad för att upprätthålla konsistens i transaktionscommits för alla noder baserat på distribuerad systemarkitektur inom datornätverk och databaser. Ofta kallas en tvåstegscommit också för ett protokoll. I ett distribuerat system kan varje nod veta framgång eller misslyckande för sin egen operation, men den kan inte veta framgång eller misslyckande för andra noders operationer. När en transaktion sträcker sig över flera noder, för att upprätthålla transaktionens ACID-egenskaper, måste en komponent som fungerar som koordinator införas för att kontrollera resultaten från alla noder (kallade deltagare) och slutligen instruera dessa noder att faktiskt skicka in resultaten (såsom att skriva uppdaterad data till disk, etc.). Därför kan algoritmidén om tvåstegsinlämningen sammanfattas så här: deltagarna kommer att meddela koordinatorn om operationens framgång eller misslyckande, och sedan kommer koordinatorn att besluta om operationen ska skickas in eller avbrytas baserat på återkopplingsinformationen från alla deltagare.
De så kallade två stegen är: första steget: förberedelsesteget (röstningsfasen) och det andra steget: inskickningssteget (genomförandefasen).
Förberedelsesteg
Transaktionskoordinatorn (transaktionshanteraren) skickar ett Prepare-meddelande till varje deltagare (resurshanterare), och varje deltagare returnerar antingen ett fel direkt (som en misslyckad behörighetsverifiering), eller utför transaktionen lokalt, skriver lokala om- och ångra-loggar, men committar inte, och når tillståndet "allt är klart, endast östvinden är skyldig".
Förberedelsesteget kan vidare delas in i följande tre steg:
1) Koordinatornoden frågar alla deltagarnoder om de kan genomföra en röstning och börjar vänta på svar från varje deltagarnod.
2) Deltagarnoden utför alla transaktionsoperationer tills frågan initieras, och skriver Undo- och Redo-informationen till loggen. (Observera: Om det lyckas har varje deltagare redan utfört transaktionen)
3) Varje deltagarnod svarar på den förfrågan som initieras av koordinatornoden. Om transaktionsoperationen för deltagarnoden faktiskt utförs framgångsrikt, returnerar den ett "Godkänn"-meddelande; Om transaktionsoperationen för deltagarnoden faktiskt misslyckas, returnerar den ett "avbrutet" meddelande.
Submissionstadiet
Om koordinatorn får ett felmeddelande eller timeout från en deltagare, skickar den ett rollback-meddelande direkt till varje deltagare. Annars, skicka ett Commit-meddelande; Deltagarna utför commit- eller rollback-operationer enligt koordinatorns instruktioner för att frigöra alla låsresurser som används i transaktionsprocessen. (Obs: Låsresurser måste frigöras i slutfasen)
Därefter diskuteras processen för inlämningsfasen separat i två fall.
När det motsvarande meddelandet som mottagits av koordinatornoden från alla deltagarnoder är Agree ?
Submissionstadiet
Om koordinatorn får ett felmeddelande eller timeout från en deltagare, skickar den ett rollback-meddelande direkt till varje deltagare. Annars, skicka ett Commit-meddelande; Deltagarna utför commit- eller rollback-operationer enligt koordinatorns instruktioner för att frigöra alla låsresurser som används i transaktionsprocessen. (Obs: Låsresurser måste frigöras i slutfasen)
Därefter diskuteras processen för inlämningsfasen separat i två fall.
När det motsvarande meddelandet som mottagits av koordinatornoden från alla deltagarnoder är Agree ?
1) Koordinatornoden skickar en "commit"-förfrågan till alla deltagarnoder.
2) Deltagarnoden slutför officiellt operationen och frigör de resurser som varit upptagna under hela transaktionsperioden.
3) Deltagarnoden skickar ett "Klart"-meddelande till koordinatornoden.
4) Koordinatornoden slutför transaktionen efter att ha mottagit återkopplingen från "Klart"-meddelandet från alla deltagarnoder.
1) Koordinatornoden skickar en "rollback"-begäran till alla deltagarnoder.
2) Deltagarnoden använder den tidigare skrivna Ångra-informationen för att utföra en återställning och frigöra resurser som upptagits under hela transaktionsperioden.
3) Deltagarnoden skickar ett "rollback complete"-meddelande till koordinatornoden.
4) Koordinatornoden avbryter transaktionen efter att ha mottagit återkoppling från meddelandet "Rollback Complete" från alla deltagarnoder.
Fas 2-commits verkar ge atomära operationer, men tyvärr har fas 2-commits fortfarande några nackdelar:
1. Problem med synkron blockering. Under exekveringen blockerar alla deltagande noder transaktioner. När en deltagare ockuperar en offentlig resurs måste andra tredjepartsnoder blockeras från att komma åt den publika resursen.
2. Enda felpunkt. På grund av koordinatorns betydelse, när koordinatorn misslyckas. Deltagarna kommer att fortsätta blockera blockeringen. Särskilt i det andra steget, om koordinatorn misslyckas, är alla deltagare fortfarande i ett tillstånd där transaktionsresurser låss och kan inte fortsätta slutföra transaktionsoperationer. (Om koordinatorn lägger på kan du återvälja en koordinator, men det löser inte problemet att deltagaren är blockerad på grund av att koordinatorn är borta)
3. Datainkonsistens. I det andra steget av det andra steget av commit, när koordinatorn skickar en commit-förfrågan till deltagaren, uppstår ett lokalt nätverksundantag eller så misslyckas koordinatorn under commit-förfrågan, vilket gör att endast vissa deltagare accepterar commit-förfrågan. Efter att ha mottagit commit-begäran kommer dessa deltagare att utföra commit-operationen. Dock kan andra maskiner som inte tar emot en commit-förfrågan inte utföra transaktionscommiten. Som ett resultat uppstår dataavdelningens konsistens i hela det distribuerade systemet.
4. Problem som inte kan lösas i andra steget: Koordinatorn går ner efter att ha skickat ett commit-meddelande, och den enda deltagaren som tar emot detta meddelande är också nere. Så även om facilitatorn väljer en ny facilitator genom valavtalet är transaktionens status osäker, och ingen vet om transaktionen har lämnats in.
3PC
Trefas-commit, även känt som tre-fas-commit-protokollet, är en förbättrad version av tvåfas-commiten (2PC).
Till skillnad från tvåstegscommits finns det två förändringar i trestegscommits.
1. Införa en timeout-mekanism. Samtidigt införs en timeout-mekanism både hos handledaren och deltagarna.
2. Lägg till ett förberedande steg i första och andra etappen. Detta säkerställer att tillståndet för alla deltagande noder är konsekvent fram till det sista commit-steget.
Med andra ord, utöver att införa en timeout-mekanism, delar 3PC återigen förberedelsesteget i 2PC i två, så att det finns tre steg av CanCommit, PreCommit och DoCommit i de tre comit-stegen.
CanCommit-fasen
CanCommit-steget i 3PC är faktiskt väldigt likt förberedelsesteget i 2PC. Koordinatorn skickar en commit-förfrågan till deltagaren, som svarar med ett Ja om de kan commita, eller ett Nej-svar.
1. Transaktionsförfrågan Facilitatorn skickar en CanCommit-förfrågan till deltagaren. Fråga om du kan utföra en transaktionscommitt-operation. Börja sedan vänta på svar från deltagarna.
2. Responsåterkoppling Efter att ha mottagit CanCommit-begäran kommer deltagaren att returnera ett Ja-svar och gå in i redo-tillstånd om den anser att transaktionen kan genomföras smidigt. Annars återkoppling. Nej.
PreCommit-fasen
Facilitatorn avgör om den ska memorera PreCommit-operationen i transaktionen baserat på deltagarens svar. Beroende på responsen finns det två möjligheter.
Om den feedback som facilitatorn får från alla deltagare är ett Ja-svar, utförs förhandsgenomförandet av transaktionen.
1. Skicka en förförhandsförfrågan: Facilitatorn skickar en förfrågan till deltagaren och går vidare till förberedelsefasen.
2. Transaktionsförförbund Efter att deltagaren mottagit förfrågan för förförväg utför den transaktionsoperationen och registrerar ångra- och omskrivningsinformationen i transaktionsloggen.
3. Responsåterkoppling Om deltagaren framgångsrikt utför transaktionsoperationen returneras ett ACK-svar samtidigt som man börjar vänta på den slutliga instruktionen.
1. Skicka en avbrytningsförfrågan Facilitatorn skickar en avbrytningsbegäran till alla deltagare.
2. Avbryt transaktionen Efter att deltagaren mottagit ABORT-begäran från koordinatorn (eller efter timeout, begäran från koordinatorn har inte mottagits), utförs avbrottet av transaktionen.
Detta steg av verkligt transaktionsåtagande kan också delas in i följande två situationer.
Utför en commit
1. Skicka en commit-förfrågan Koordinering tar emot ACK-svaret som deltagaren skickat, sedan går han från pre-commit-tillståndet till commit-tillståndet. och skicka en doCommit-förfrågan till alla deltagare.
2. Transaktionsinlämning Efter att ha mottagit doCommit-begäran genomför deltagaren den formella transaktionscommiten. och släpper alla transaktionsresurser efter att transaktionscommit slutförts.
3. Svara på feedback Efter att transaktionen har skickats, skicka ett Ack-svar till koordinatorn.
4. Slutför transaktionen Efter att koordinatorn mottagit ACK-svaret från alla deltagare är transaktionen slutförd.
Om koordinatorn inte får ett ACK-svar från deltagaren (det kan vara ett ACK-svar från mottagaren, eller så kan svaret ha gått ut på tidsgränsen), så utförs avbrottstransaktionen.
1. Skicka en avbrottsförfrågan Facilitatorn skickar en avbrytningsbegäran till alla deltagare
2. Transaktionsrullning Efter att ha mottagit AVBRYT-begäran använder deltagaren ångrningsinformationen som registrerats i fas 2 för att utföra transaktionsrullningsoperationen och frigör alla transaktionsresurser efter att återställningen är klar.
3. Återkopplingsresultat Efter att deltagaren har slutfört transaktionsåterställningen, skicka ett ACK-meddelande till koordinatorn
4. Avbryt transaktionen Efter att koordinatorn mottagit ACK-meddelandet från deltagaren avbryts transaktionen.
Skillnaden mellan 2PC och 3PC
Jämfört med 2PC löser 3PC främst problemet med en enda felpunkt och minskar blockering, eftersom deltagaren som standard inte får ett meddelande från koordinatorn i tid, utför commit som standard. Istället för att hålla transaktionsresurser hela tiden och vara i ett blockerande tillstånd. Men denna mekanism orsakar också problem med datakonsistens, eftersom avbrottssvaret som skickas av koordinatorn inte tas emot av deltagaren i tid på grund av nätverksskäl, och deltagaren utför sedan commit-operationen efter att ha väntat på timeout. Detta skapar datainkonsekvenser med andra deltagare som får avbrytkommandot och utför en rollback.
|
Publicerad på 2021-03-17 10:15:10
|
|
|
