XA-specifikation
XA er grænseflade-specifikationen (dvs. grænsefladefunktionen) mellem transaktionsmiddleware og databasen defineret af X/Open DTP, som transaktionsmiddleware bruger til at underrette databasen om start, slutning, commit, rollback osv. af transaktioner. XA-grænsefladefunktioner leveres af databaseleverandører.
Andenordens indsendelsesaftale og tredjeordres indsendelsesaftale blev afledt af denne idé. Man kan sige, at to-trins commits faktisk er nøglen til at implementere XA-distribuerede transaktioner (for at være præcis: to-trins commits sikrer primært atomiciteten af distribuerede transaktioner: det vil sige, at alle noder enten gør alt eller intet)
2PC
To-fase Commit refererer til en algoritme designet til at opretholde konsistens i transaktionscommits for alle noder baseret på distribueret systemarkitektur inden for computernetværk og databaser. Ofte omtales en to-trins commit også som en protokol. I et distribueret system kan hver node kende succesen eller fiaskoen for sin egen operation, men den kan ikke kende succesen eller fiaskoen for andre noders operationer. Når en transaktion spænder over flere noder, skal der for at opretholde transaktionens ACID-karakteristika introduceres en komponent, der fungerer som koordinator, for at kontrollere resultaterne af alle noder (kaldet deltagere) og i sidste ende instruere disse noder til faktisk at indsende resultaterne (såsom at skrive opdaterede data til disk osv.). Derfor kan algoritmeidéen bag to-trins indsendelse opsummeres således: deltagerne vil underrette koordinatoren om operationens succes eller fiasko, og derefter vil koordinatoren beslutte, om operationen skal indsendes eller afbrydes baseret på feedbackinformationen fra alle deltagere.
De såkaldte to faser er: første fase: forberedelsesfasen (afstemningsfasen) og anden fase: indsendelsesfasen (udførelsesfasen).
Forberedelsesfase
Transaktionskoordinatoren (transaktionsmanageren) sender en Prepared-besked til hver deltager (ressourcemanager), og hver deltager returnerer enten en fejl direkte (såsom en fejl i tilladelsesverifikation), eller udfører transaktionen lokalt, skriver lokale logs om og om igen, men committer ikke, og når en tilstand af "alt er klar, kun østenvinden skyldes".
Forberedelsesfasen kan yderligere opdeles i følgende tre trin:
1) Koordinatornoden spørger alle deltagernoder, om de kan foretage en afstemning, og begynder at vente på svar fra hver deltagernode.
2) Deltagernoden udfører alle transaktionsoperationer, indtil forespørgslen igangsættes, og skriver Fortryd-informationen og Redo-informationen til loggen. (Bemærk: Hvis det lykkes, har hver deltager allerede udført transaktionsoperationen)
3) Hver deltagernode svarer på forespørgslen, som koordinatornoden initierer. Hvis transaktionsoperationen for deltagernoden faktisk udføres med succes, returnerer den en "Accept"-besked; Hvis transaktionsoperationen for deltagernoden faktisk fejler, returnerer den en "afbrudt" besked.
Indsendelsesfasen
Hvis koordinatoren modtager en fejlmeddelelse eller timeout fra en deltager, vil den sende en rollback-besked direkte til hver deltager. Ellers send en Commit-besked; Deltagerne udfører commit- eller rollback-operationer i henhold til koordinatorens instruktioner for at frigive alle låseressourcer, der bruges i transaktionsprocessen. (Bemærk: Låseressourcer skal frigives i den sidste fase)
Dernæst diskuteres processen for indsendelsesfasen separat i to tilfælde.
Når den tilsvarende besked, som koordinatornoden modtager fra alle deltagernoder, er Agree:
Indsendelsesfasen
Hvis koordinatoren modtager en fejlmeddelelse eller timeout fra en deltager, vil den sende en rollback-besked direkte til hver deltager. Ellers send en Commit-besked; Deltagerne udfører commit- eller rollback-operationer i henhold til koordinatorens instruktioner for at frigive alle låseressourcer, der bruges i transaktionsprocessen. (Bemærk: Låseressourcer skal frigives i den sidste fase)
Dernæst diskuteres processen for indsendelsesfasen separat i to tilfælde.
Når den tilsvarende besked, som koordinatornoden modtager fra alle deltagernoder, er Agree:
1) Koordinatornoden udsender en "commit"-anmodning til alle deltagernoder.
2) Deltagernoden fuldfører officielt operationen og frigiver de ressourcer, der er optaget gennem hele transaktionsperioden.
3) Deltagernoden sender en "Færdig"-besked til koordinatornoden.
4) Koordinatornoden fuldfører transaktionen efter at have modtaget "Færdig"-beskeden feedback fra alle deltagernoder.
1) Koordinatornoden udsender en "rollback"-anmodning til alle deltagernoder.
2) Deltagernoden bruger de tidligere skrevne Fortrydningsoplysninger til at udføre en rollback og frigive ressourcer, der er optaget gennem hele transaktionsperioden.
3) Deltagernoden sender en "rollback complete"-besked til koordinatornoden.
4) Koordinatornoden annullerer transaktionen efter at have modtaget "Rollback Complete"-beskeden fra alle deltagernoder.
Fase 2-commits ser ud til at give atomare operationer, men desværre har step 2-commits stadig nogle ulemper:
1. Synkron blokeringsproblem. Under udførelsen blokerer alle deltagende noder transaktioner. Når en deltager besætter en offentlig ressource, skal andre tredjepartsnoder blokeres fra at få adgang til den offentlige ressource.
2. Enkelt fejlpunkt. På grund af koordinatorens betydning, når koordinatoren fejler. Deltagerne vil fortsætte med at blokere blokeringen. Især i anden fase, hvis koordinatoren fejler, er alle deltagere stadig i en tilstand af at låse transaktionsressourcer og kan ikke fortsætte med at gennemføre transaktionsoperationer. (Hvis koordinatoren lægger på, kan du genvælge en koordinator, men det kan ikke løse problemet med, at deltageren er blokeret på grund af koordinatorens nede)
3. Datainkonsistens. I anden fase af anden commit-fase, når koordinatoren sender en commit-anmodning til deltageren, opstår der en lokal netværksundtagelse, eller koordinatoren fejler under commit-anmodningsprocessen, hvilket får kun nogle deltagere til at acceptere commit-anmodningen. Efter at have modtaget commit-anmodningen, vil disse deltagere udføre commit-operationen. Dog kan andre maskiner, der ikke modtager en commit-anmodning, ikke udføre transaktionscommit'en. Som følge heraf opstår dataafdelingens konsistens i hele det distribuerede system.
4. Problemer, der ikke kan løses i anden fase: Koordinatoren går ned efter at have sendt en commit-besked, og den eneste deltager, der modtager denne besked, er også nede. Så selv hvis facilitatoren vælger en ny facilitator gennem valgaftalen, er transaktionens status usikker, og ingen ved, om transaktionen er indsendt.
3PC
Trefase-commit, også kendt som tre-fase commit-protokollen, er en forbedret version af to-fase commit-protokollen (2PC).
I modsætning til to-trins commits er der to ændringer til tre-trins commits.
1. Indfør en timeout-mekanisme. Samtidig indføres en timeout-mekanisme både hos facilitatoren og deltagerne.
2. Indsæt en forberedende fase i første og anden fase. Dette sikrer, at tilstanden for alle deltagende noder er konsistent indtil den sidste commit-fase.
Med andre ord, ud over at introducere en timeout-mekanisme, deler 3PC igen forberedelsesfasen i 2PC i to, så der er tre stadier af CanCommit, PreCommit og DoCommit i de tre stadier af commit.
CanCommit-stadiet
CanCommit-fasen i 3PC ligner faktisk meget forberedelsesfasen i 2PC. Koordinatoren sender en committ-anmodning til deltageren, som returnerer et Ja-svar, hvis de kan commit'e, eller et Nej-svar.
1. Transaktionsforespørgsel Facilitatoren sender en CanCommit-anmodning til deltageren. Spørg, om du kan udføre en transaktionscommitt-operation. Begynd derefter at vente på svar fra deltagerne.
2. Responsfeedback Efter at have modtaget CanCommit-anmodningen, vil deltageren returnere et Ja-svar og gå ind i klar-tilstanden, hvis den mener, at transaktionen kan udføres gnidningsfrit. Ellers feedback nej
PreCommit-fasen
Facilitatoren beslutter, om han vil memorere PreCommit-operationen i transaktionen baseret på deltagerens svar. Afhængigt af reaktionen er der to muligheder.
Hvis den feedback, facilitatoren får fra alle deltagere, er et Ja-svar, udføres forudførelsen af transaktionen.
1. Send en PreCommit-anmodning: Facilitatoren sender en PreCommit-anmodning til deltageren og går videre til Prepare-fasen.
2. Transaktion Pre-Commit Efter at deltageren modtager PreCommit-anmodningen, udfører den transaktionsoperationen og registrerer fortrydelse og gentag-information i transaktionsloggen.
3. Responsfeedback Hvis deltageren udfører transaktionsoperationen med succes, returneres et ACK-svar, mens man begynder at vente på den endelige instruktion.
1. Send en afbrydelsesanmodning Facilitatoren sender en afbrydelsesanmodning til alle deltagere.
2. Afbryd transaktionen Efter deltageren modtager ABORT-anmodningen fra koordinatoren (eller efter timeouten, anmodningen fra koordinatoren er ikke modtaget), udføres afbrydelsen af transaktionen.
Denne fase af reel transaktionsforpligtelse kan også opdeles i følgende to situationer.
Udfør et commit
1. Send en commit-anmodning Koordinering modtager ACK-svaret sendt af deltageren, hvorefter han går fra pre-commit-tilstanden til committ-tilstanden. og send en doCommit-anmodning til alle deltagere.
2. Transaktionsindsendelse Efter modtagelse af doCommit-anmodningen udfører deltageren den formelle transaktionscommit. og frigive alle transaktionsressourcer efter at have gennemført transaktionscommiten.
3. Svar på feedback Efter transaktionen er indsendt, send et Ack-svar til koordinatoren.
4. Fuldfør transaktionen Efter at koordinatoren har modtaget ACK-svaret fra alle deltagere, er transaktionen afsluttet.
Hvis koordinatoren ikke modtager et ACK-svar fra deltageren (det kan være et ACK-svar fra modtageren, eller svaret kan være udløbet), udføres afbrydelsestransaktionen.
1. Send en afbrydelsesanmodning Facilitatoren sender en afbrydelsesanmodning til alle deltagere
2. Transaktionstilbagerulning Efter modtagelsen af ABORT-anmodningen bruger deltageren de fortrydelsesoplysninger, der blev registreret i fase 2, til at udføre transaktionsrullback-operationen og frigiver alle transaktionsressourcer efter at have gennemført tilbagerullingen.
3. Feedbackresultater Efter at deltageren har gennemført transaktionsrollbacken, sendes en ACK-besked til koordinatoren
4. Afbryd transaktionen Efter at koordinatoren har modtaget ACK-beskeden fra deltageren, afbrydes transaktionen.
Forskellen mellem 2PC og 3PC
Sammenlignet med 2PC løser 3PC hovedsageligt problemet med enkeltpunktet og reducerer blokering, fordi deltageren, når han ikke modtager en besked fra koordinatoren i tide, udfører commit'en som standard. I stedet for at holde transaktionsressourcer hele tiden og være i en blokerende tilstand. Men denne mekanisme forårsager også problemer med datakonsistens, fordi det afbrydelsessvar, som koordinatoren sender, ikke modtages af deltageren i tide på grund af netværksårsager, hvorefter deltageren udfører commit-operationen efter at have ventet på timeout. Dette skaber datainkonsistenser med andre deltagere, der modtager afbrudskommandoen og udfører en rollback.
|
Opslået på 17/03/2021 10.15.10
|
|
|
