XA-spesifikasjon
XA er grensesnittspesifikasjonen (dvs. grensesnittfunksjonen) mellom transaksjonsmellomvaren og databasen definert av X/Open DTP, som brukes av transaksjonsmellomvaren for å varsle databasen om start, slutt, commit, tilbakerulling osv. av transaksjoner. XA-grensesnittfunksjoner leveres av databaseleverandører.
Avtalen om innsending av andre ordre og avtalen om innsending av tredje ordre ble hentet fra denne ideen. Det kan sies at to-trinns commits faktisk er nøkkelen til å implementere XA-distribuerte transaksjoner (for å være presis: to-trinns commits sikrer hovedsakelig atomiciteten til distribuerte transaksjoner: det vil si at alle noder enten gjør alt eller ingenting)
2PC
To-fase Commit refererer til en algoritme designet for å opprettholde konsistens i transaksjonscommits for alle noder basert på distribuert systemarkitektur innen datanettverk og databaser. Ofte omtales en to-trinns commit også som en protokoll. I et distribuert system kan hver node vite suksess eller fiasko for sin egen operasjon, men den kan ikke vite suksess eller fiasko for andre noders operasjoner. Når en transaksjon strekker seg over flere noder, må en komponent som fungerer som koordinator for å opprettholde ACID-egenskapene til transaksjonen introduseres for å kontrollere resultatene til alle noder (kalt deltakere) og til slutt instruere disse nodene til faktisk å sende resultatene (for eksempel å skrive oppdaterte data til disk, osv.). Derfor kan algoritmeideen bak to-trinns innsending oppsummeres slik: deltakerne vil varsle koordinatoren om operasjonens suksess eller fiasko, og deretter vil koordinatoren avgjøre om operasjonen skal sendes inn eller avbrytes basert på tilbakemeldingsinformasjonen fra alle deltakerne.
De såkalte to fasene er: første fase: forberedelsesfasen (avstemningsfasen) og andre fasen: innsendingsfasen (gjennomføringsfasen).
Forberedelsesfase
Transaksjonskoordinatoren (transaksjonsbehandleren) sender en Forbered-melding til hver deltaker (ressursforvalter), og hver deltaker returnerer enten en feil direkte (for eksempel en mislykket tillatelsesverifisering), eller utfører transaksjonen lokalt, skriver lokale logger for å gjøre om og angre, men committer ikke, og når en tilstand der «alt er klart, bare østvinden har krav på».
Forberedelsesfasen kan videre deles inn i følgende tre trinn:
1) Koordinatornoden spør alle deltakernoder om de kan gjennomføre en avstemning og begynner å vente på svar fra hver deltakernode.
2) Deltakernoden utfører alle transaksjonsoperasjoner inntil spørringen startes, og skriver Undo- og Redo-informasjonen til loggen. (Merk: Hvis det lykkes, har hver deltaker allerede utført transaksjonsoperasjonen)
3) Hver deltakernode svarer på forespørselen initiert av koordinatornoden. Hvis transaksjonsoperasjonen til deltakernoden faktisk utføres vellykket, returnerer den en "Agree"-melding; Hvis transaksjonsoperasjonen til deltakernoden faktisk feiler, returnerer den en "avbrutt" melding.
Submission-fasen
Hvis koordinatoren mottar en feilmelding eller timeout fra en deltaker, vil den sende en tilbakerullingsmelding direkte til hver deltaker. Ellers, send en commit-melding; Deltakerne utfører commit- eller rollback-operasjoner i henhold til koordinatorens instruksjoner for å frigi alle låseressurser som brukes i transaksjonsprosessen. (Merk: Låseressurser må frigjøres i siste fase)
Deretter diskuteres prosessen for innsendingsfasen separat i to tilfeller.
Når den tilsvarende meldingen mottatt av koordinatornoden fra alle deltakernoder er Agree:
Submission-fasen
Hvis koordinatoren mottar en feilmelding eller timeout fra en deltaker, vil den sende en tilbakerullingsmelding direkte til hver deltaker. Ellers, send en commit-melding; Deltakerne utfører commit- eller rollback-operasjoner i henhold til koordinatorens instruksjoner for å frigi alle låseressurser som brukes i transaksjonsprosessen. (Merk: Låseressurser må frigjøres i siste fase)
Deretter diskuteres prosessen for innsendingsfasen separat i to tilfeller.
Når den tilsvarende meldingen mottatt av koordinatornoden fra alle deltakernoder er Agree:
1) Koordinatornoden sender en "commit"-forespørsel til alle deltakernoder.
2) Deltakernoden fullfører offisielt operasjonen og frigjør ressursene som er opptatt gjennom transaksjonsperioden.
3) Deltakernoden sender en "Ferdig"-melding til koordinatornoden.
4) Koordinatornoden fullfører transaksjonen etter å ha mottatt tilbakemelding fra «Ferdig»-meldingen fra alle deltakernoder.
1) Koordinatornoden sender en "rollback"-forespørsel til alle deltakernoder.
2) Deltakernoden bruker den tidligere skrevne Undo-informasjonen til å utføre en tilbakerulling og frigjøre ressurser som er opptatt gjennom hele transaksjonsperioden.
3) Deltakernoden sender en "rollback complete"-melding til koordinatornoden.
4) Koordinatornoden kansellerer transaksjonen etter å ha mottatt tilbakemelding fra "Rollback Complete" fra alle deltakernoder.
Fase 2-commits ser ut til å gi atomoperasjoner, men dessverre har stage 2-commits fortsatt noen ulemper:
1. Synkron blokkeringsproblem. Under utførelsen blokkerer alle deltakende noder transaksjoner. Når en deltaker okkuperer en offentlig ressurs, må andre tredjepartsnoder blokkeres fra å få tilgang til den offentlige ressursen.
2. Enkelt feilpunkt. På grunn av viktigheten av koordinatoren, når koordinatoren feiler. Deltakerne vil fortsette å blokkere blokkeringen. Spesielt i andre fase, hvis koordinatoren feiler, er alle deltakere fortsatt i en tilstand av å låse transaksjonsressurser og kan ikke fortsette å fullføre transaksjonsoperasjoner. (Hvis koordinatoren legger på, kan du gjenvelge en koordinator, men det løser ikke problemet med at deltakeren er blokkert fordi koordinatoren er nede)
3. Datainkonsistens. I andre fase av andre fase av commit, når koordinatoren sender en commit-forespørsel til deltakeren, oppstår et lokalt nettverksunntak eller koordinatoren feiler under commit-forespørselsprosessen, noe som gjør at bare noen deltakere aksepterer commit-forespørselen. Etter å ha mottatt commit-forespørselen, vil disse deltakerne utføre commit-operasjonen. Andre maskiner som ikke mottar en commit-forespørsel kan imidlertid ikke utføre transaksjonscommiten. Som et resultat oppstår dataavdelingens konsistens i hele det distribuerte systemet.
4. Problemer som ikke kan løses i andre fase: Koordinatoren går ned etter å ha sendt en commit-melding, og den eneste deltakeren som mottar denne meldingen er også nede. Så selv om tilretteleggeren velger en ny tilrettelegger gjennom valgavtalen, er statusen til transaksjonen usikker, og ingen vet om transaksjonen er sendt inn.
3PC
Trefase-commit, også kjent som tre-fase commit-protokollen, er en forbedret versjon av to-fase commit (2PC).
I motsetning til to-trinns commits, er det to endringer i tre-trinns commits.
1. Innfør en timeout-mekanisme. Samtidig innføres en timeout-mekanisme både hos fasilitatoren og deltakerne.
2. Sett inn et forberedende trinn i første og andre fase. Dette sikrer at tilstanden til alle deltakende noder er konsistent frem til siste commit-fasen.
Med andre ord, i tillegg til å introdusere en timeout-mekanisme, deler 3PC igjen forberedelsesfasen i 2PC i to, slik at det er tre stadier CanCommit, PreCommit og DoCommit i de tre stadiene av commit.
CanCommit-fasen
CanCommit-fasen i 3PC ligner faktisk veldig på forberedelsesfasen i 2PC. Koordinatoren sender en commit-forespørsel til deltakeren, som returnerer et Ja-svar hvis de kan committe, eller et Nei-svar.
1. Transaksjonsforespørsel: Fasilitatoren sender en CanCommit-forespørsel til deltakeren. Spør om du kan utføre en transaksjonsforpliktelsesoperasjon. Begynn deretter å vente på svar fra deltakerne.
2. Responstilbakemelding Etter å ha mottatt CanCommit-forespørselen, vil deltakeren returnere et Ja-svar og gå inn i klar-tilstanden hvis de mener at transaksjonen kan gjennomføres smidig. Ellers tilbakemelding nei
PreCommit-fasen
Fasilitatoren avgjør om den skal memorere PreCommit-operasjonen i transaksjonen basert på deltakerens respons. Avhengig av responsen finnes det to muligheter.
Hvis tilbakemeldingen fasilitatoren får fra alle deltakerne er et Ja-svar, utføres forutførelsen av transaksjonen.
1. Send en PreCommit-forespørsel Fasilitatoren sender en PreCommit-forespørsel til deltakeren og går videre til Prepare-fasen.
2. Transaksjon Pre-Commit Etter at deltakeren mottar PreCommit-forespørselen, utfører den transaksjonsoperasjonen og registrerer angre- og redo-informasjonen i transaksjonsloggen.
3. Responstilbakemelding Hvis deltakeren utfører transaksjonen vellykket, returneres et ACK-svar mens man begynner å vente på den endelige instruksjonen.
1. Send en avbrytelsesforespørsel Fasilitatoren sender en avbrytelsesforespørsel til alle deltakerne.
2. Avbryt transaksjonen Etter at deltakeren mottar ABORT-forespørselen fra koordinatoren (eller etter tidsavbruddet er forespørselen fra koordinatoren ikke mottatt), utføres avbrytelsen av transaksjonen.
Dette stadiet av reell transaksjonsforpliktelse kan også deles inn i følgende to situasjoner.
Utfør en commit
1. Send en commit-forespørsel Koordinering mottar ACK-svaret sendt av deltakeren, deretter går han fra pre-commit-tilstanden til commit-tilstanden. og send en doCommit-forespørsel til alle deltakere.
2. Transaksjonsinnsending Etter å ha mottatt doCommit-forespørselen, utfører deltakeren den formelle transaksjonscommiten. og frigi alle transaksjonsressurser etter at transaksjonscommit er fullført.
3. Svar på tilbakemelding Etter at transaksjonen er sendt, send et Ack-svar til koordinatoren.
4. Fullfør transaksjonen Etter at koordinatoren mottar ACK-svaret fra alle deltakerne, er transaksjonen fullført.
Hvis koordinatoren ikke mottar et ACK-svar fra deltakeren (det kan hende det ikke er et ACK-svar fra mottakeren, eller svaret kan ha gått ut av tid), utføres avbruddstransaksjonen.
1. Send en avbrytelsesforespørsel Fasilitatoren sender en avbrytelsesforespørsel til alle deltakere
2. Transaksjonstilbakerulling Etter å ha mottatt AVBRYT-forespørselen, bruker deltakeren angre-informasjonen registrert i fase 2 for å utføre tilbakerullingsoperasjonen, og frigjør alle transaksjonsressurser etter fullført tilbakeføring.
3. Tilbakemeldingsresultater Etter at deltakeren har fullført transaksjonsrullingen, send en ACK-melding til koordinatoren
4. Avbryt transaksjonen Etter at koordinatoren mottar ACK-meldingen fra deltakeren, blir transaksjonen avbrutt.
Forskjellen mellom 2PC og 3PC
Sammenlignet med 2PC løser 3PC hovedsakelig single point of fail-problemet og reduserer blokkering, fordi når deltakeren ikke mottar en melding fra koordinatoren i tide, utfører han commiten som standard. I stedet for å holde transaksjonsressurser hele tiden og være i en blokkerende tilstand. Men denne mekanismen forårsaker også problemer med datakonsistens, fordi avbruddsvaret sendt av koordinatoren ikke mottas av deltakeren i tide på grunn av nettverksårsaker, og deretter utfører deltakeren commit-operasjonen etter å ha ventet på timeout. Dette skaper datainkonsistenser med andre deltakere som mottar avbrytingskommandoen og utfører en tilbakerulling.
|
Publisert på 17.03.2021 10:15:10
|
|
|
