XA-specificatie
XA is de interface-specificatie (d.w.z. interfacefunctie) tussen de transactie-middleware en de database gedefinieerd door X/Open DTP, die door de transactie-middleware wordt gebruikt om de database te informeren over het begin, einde, commit, rollback, enz. van transacties. XA-interfacefuncties worden geleverd door databaseleveranciers.
De indieningsovereenkomst voor de tweede orde en de indieningsovereenkomst voor de derde orde zijn afgeleid van dit idee. Men kan zeggen dat tweestapscommits eigenlijk de sleutel zijn tot het implementeren van XA-gedistribueerde transacties (om precies te zijn: tweestapscommits zorgen vooral voor de atomiciteit van gedistribueerde transacties: dat wil zeggen, alle knooppunten doen alles of niets)
2PC
Two-phase Commit verwijst naar een algoritme dat is ontworpen om consistentie in transactiecommits voor alle nodes te waarborgen, gebaseerd op de gedistribueerde systeemarchitectuur op het gebied van computernetwerken en databases. Vaak wordt een tweefasige commit ook wel een protocol genoemd. In een gedistribueerd systeem kan elke node het succes of falen van zijn eigen operatie kennen, maar het kan het succes of falen van de operaties van andere nodes niet weten. Wanneer een transactie meerdere knooppunten overspant, moet er om de ACID-eigenschappen van de transactie te behouden een component worden geïntroduceerd die als coördinator fungeert om de resultaten van alle knooppunten (zogenaamde deelnemers) te controleren en deze knooppunten uiteindelijk opdracht geven de resultaten daadwerkelijk aan te leveren (zoals het schrijven van bijgewerkte gegevens naar de schijf, enz.). Daarom kan het idee van het algoritme van de tweefasige indiening als volgt worden samengevat: de deelnemers zullen de coördinator op de hoogte stellen van het succes of falen van de operatie, waarna de coördinator beslist of de operatie wordt ingediend of afgebroken op basis van de feedbackinformatie van alle deelnemers.
De zogenaamde twee fasen zijn: de eerste fase: de voorbereidingsfase (stemfase) en de tweede fase: de indieningsfase (uitvoeringsfase).
Voorbereidingsfase
De transactiecoördinator (transactiemanager) stuurt een Prepare-bericht naar elke deelnemer (resource manager), en elke deelnemer stuurt ofwel direct een fout terug (zoals een mislukte toestemmingsverificatie), of voert de transactie lokaal uit, schrijft lokale logs om opnieuw en ongedaan te maken, maar committeert niet, en bereikt de toestand van "alles is klaar, alleen de oostenwind is verschuldigd".
De voorbereidingsfase kan verder worden onderverdeeld in de volgende drie stappen:
1) De coördinatorknoop vraagt alle deelnemersknooppunten of ze een stemming kunnen uitvoeren en begint te wachten op een reactie van elke deelnemerknoop.
2) De deelnemende node voert alle transactiebewerkingen uit totdat de query wordt gestart, en schrijft de Undo- en Redo-informatie naar het logboek. (Opmerking: als het lukt, heeft elke deelnemer de transactie al uitgevoerd)
3) Elke deelnemende node reageert op de vraag die door de coördinatornode wordt geïnitieerd. Als de transactiebewerking van de deelnemerknoop daadwerkelijk succesvol wordt uitgevoerd, geeft deze een "Akkoord"-melding terug; Als de transactiebewerking van de deelnemerknoop daadwerkelijk faalt, geeft het een "afgebroken" bericht terug.
Onderwerpingsfase
Als de coördinator een foutbericht of time-out van een deelnemer ontvangt, stuurt hij een rollback-bericht rechtstreeks naar elke deelnemer. Anders stuur je een Commit-bericht; Deelnemers voeren commit- of rollback-operaties uit volgens de instructies van de coördinator om alle vergrendelingsbronnen die in het transactieproces worden gebruikt vrij te geven. (Opmerking: Lock-resources moeten in de laatste fase worden vrijgegeven)
Vervolgens wordt het proces van de indieningsfase afzonderlijk besproken in twee gevallen.
Wanneer het overeenkomstige bericht dat door de coördinatorknoop van alle deelnemersknooppunten wordt ontvangen Akkoord is:
Onderwerpingsfase
Als de coördinator een foutbericht of time-out van een deelnemer ontvangt, stuurt hij een rollback-bericht rechtstreeks naar elke deelnemer. Anders stuur je een Commit-bericht; Deelnemers voeren commit- of rollback-operaties uit volgens de instructies van de coördinator om alle vergrendelingsbronnen die in het transactieproces worden gebruikt vrij te geven. (Opmerking: Lock-resources moeten in de laatste fase worden vrijgegeven)
Vervolgens wordt het proces van de indieningsfase afzonderlijk besproken in twee gevallen.
Wanneer het overeenkomstige bericht dat door de coördinatorknoop van alle deelnemersknooppunten wordt ontvangen Akkoord is:
1) De coördinatornode stuurt een "commit"-verzoek aan alle deelnemende nodes.
2) De deelnemende node voltooit officieel de operatie en geeft de middelen vrij die gedurende de transactieperiode zijn gebruikt.
3) De deelnemer-node stuurt een "Done"-bericht naar de coördinator-node.
4) De coördinatornode voltooit de transactie nadat hij de "Done"-feedback van alle deelnemende nodes heeft ontvangen.
1) De coördinatorknoop stuurt een "rollback"-verzoek aan alle deelnemende knooppunten.
2) De deelnemende node gebruikt de eerder geschreven Undo-informatie om een rollback uit te voeren en middelen vrij te geven die gedurende de transactieperiode in beslag zijn genomen.
3) De deelnemernode stuurt een "rollback complete"-bericht naar de coördinatornode.
4) De coördinatornode annuleert de transactie nadat de feedback van het bericht "Rollback Complete" van alle deelnemende nodes is ontvangen.
Phase 2 commits lijken atomaire operaties te bieden, maar helaas hebben stage 2 commits nog steeds een paar nadelen:
1. Probleem met synchrone blokkering. Tijdens de uitvoering blokkeren alle deelnemende knooppunten transacties. Wanneer een deelnemer een openbare bron bezet, moeten andere knooppunten van derden worden geblokkeerd om toegang te krijgen tot de publieke bron.
2. Enkel punt van falen. Vanwege het belang van de coördinator, zodra de coördinator faalt. De deelnemers blijven de blokkade blokkeren. Vooral in de tweede fase, als de coördinator faalt, bevinden alle deelnemers zich nog steeds in een staat van het vergrendelen van transactieresources en kunnen ze niet doorgaan met het voltooien van transactiebewerkingen. (Als de coördinator ophangt, kun je een coördinator herkiezen, maar dat lost het probleem niet op dat de deelnemer geblokkeerd is omdat de coördinator niet is uitgeschakeld)
3. Data-inconsistentie. In de tweede fase van de tweede commitfase, wanneer de coördinator een commitverzoek naar de deelnemer stuurt, treedt er een uitzondering op het lokale netwerk op of faalt de coördinator tijdens het commitverzoekproces, waardoor slechts enkele deelnemers het commitverzoek accepteren. Na ontvangst van het commit-verzoek voeren deze deelnemers de commit-operatie uit. Andere machines die echter geen commitverzoek ontvangen, kunnen de transactiecommit niet uitvoeren. Als gevolg hiervan treedt de consistentie van de dataafdeling op in het gehele gedistribueerde systeem.
4. Problemen die niet in de tweede fase kunnen worden opgelost: De coördinator gaat uit na het versturen van een commit-bericht, en de enige deelnemer die dit bericht ontvangt ligt ook uit. Dus zelfs als de facilitator via de verkiezingsovereenkomst een nieuwe facilitator kiest, is de status van de transactie onzeker en weet niemand of de transactie is ingediend.
3PC
Driefasige commit, ook bekend als het driefasen-commitprotocol, is een verbeterde versie van de tweefasencommit (2PC).
In tegenstelling tot tweetrapscomits zijn er twee wijzigingen aan drietrapscommits.
1. Introduceer een time-out mechanisme. Tegelijkertijd wordt er een time-outmechanisme geïntroduceerd bij zowel de facilitator als de deelnemers.
2. Voeg een voorbereidende fase in in de eerste en tweede fase. Dit zorgt ervoor dat de toestand van alle deelnemende knooppunten consistent is tot aan de laatste commitfase.
Met andere woorden, naast het introduceren van een time-outmechanisme, verdeelt 3PC opnieuw de voorbereidingsfase van 2PC in tweeën, zodat er drie fasen van CanCommit, PreCommit en DoCommit zijn in de drie stadia van commit.
CanCommit fase
De CanCommit-fase van 3PC lijkt eigenlijk erg op de voorbereidingsfase van 2PC. De coördinator stuurt een commit-verzoek naar de deelnemer, die een Ja-antwoord teruggeeft als hij of zij kan committen, of een Nee-antwoord.
1. Transactie-aanvraag: De facilitator stuurt een CanCommit-verzoek naar de deelnemer. Vraag of je een transaction commit-operatie kunt uitvoeren. Begin dan te wachten op een reactie van de deelnemers.
2. Responsfeedback Na ontvangst van het CanCommit-verzoek zal de deelnemer een Ja-antwoord teruggeven en in de ready-staat gaan als hij denkt dat de transactie soepel kan worden uitgevoerd. Anders feedback nee
PreCommit-fase
De facilitator beslist of hij de PreCommit-operatie van de transactie uit het hoofd leert op basis van de reactie van de deelnemer. Afhankelijk van de reactie zijn er twee mogelijkheden.
Als de feedback die de facilitator van alle deelnemers ontvangt een Ja-antwoord is, wordt de pre-uitvoering van de transactie uitgevoerd.
1. Stuur een PreCommit Request De facilitator stuurt een PreCommit request naar de deelnemer en gaat door naar de Prepare stage.
2. Transactie Pre-Commit Nadat de deelnemer het PreCommit-verzoek ontvangt, voert hij de transactiebewerking uit en registreert hij de ongedaanmaak- en redo-informatie in het transactielogboek.
3. Responsfeedback Als de deelnemer de transactiebewerking succesvol uitvoert, wordt een ACK-antwoord teruggegeven terwijl wordt gewacht op de laatste instructie.
1. Stuur een interrupt-verzoek De facilitator stuurt een afbreekverzoek naar alle deelnemers.
2. Onderbreek de transactie Nadat de deelnemer het ABORT-verzoek van de coördinator heeft ontvangen (of na de time-out is het verzoek van de coördinator niet ontvangen), wordt de onderbreking van de transactie uitgevoerd.
Deze fase van de reële transactiecommit kan ook worden onderverdeeld in de volgende twee situaties.
Voer een commit uit
1. Stuur een commit-verzoek Coördinerende ontvangt het ACK-antwoord dat door de deelnemer wordt verzonden, waarna hij van de pre-commit toestand naar de commit staat gaat. en stuur een doCommit-verzoek naar alle deelnemers.
2. Transactie-indiening Na ontvangst van het doCommit-verzoek voert de deelnemer de formele transactie-commit uit. en alle transactiebronnen vrijgeven nadat de transactiecommit is voltooid.
3. Reageer op feedback Nadat de transactie is ingediend, stuur een Ack-antwoord naar de coördinator.
4. Voltooi de transactie Nadat de coördinator het ACK-antwoord van alle deelnemers heeft ontvangen, is de transactie afgerond.
Als de coördinator geen ACK-antwoord van de deelnemer ontvangt (het kan geen ACK-antwoord van de ontvanger zijn, of het antwoord kan zijn afgelopen), wordt de interrupt-transactie uitgevoerd.
1. Stuur een interrupt-verzoek De facilitator stuurt een abort-verzoek naar alle deelnemers
2. Transaction Rollback Na ontvangst van het ABORT-verzoek gebruikt de deelnemer de ongedaan maken-informatie uit Fase 2 om de transactie-rollback uit te voeren, en geeft alle transactieresources vrij na voltooiing van de rollback.
3. Feedbackresultaten Nadat de deelnemer de transactie-rollback heeft voltooid, stuurt u een ACK-bericht naar de coördinator
4. Onderbreek de transactie Nadat de coördinator het ACK-bericht van de deelnemer heeft ontvangen, wordt de transactie onderbroken.
Het verschil tussen 2PC en 3PC
In vergelijking met 2PC lost 3PC vooral het single point of fail-probleem op en vermindert het blokkeren, omdat zodra de deelnemer een bericht van de coördinator niet op tijd ontvangt, hij standaard de commit uitvoert. In plaats van altijd transactieresources vast te houden en in een blokkerende toestand te zitten. Maar dit mechanisme veroorzaakt ook problemen met dataconsistentie, omdat de abortrespons van de coördinator niet op tijd door de deelnemer wordt ontvangen vanwege netwerkredenen, waarna de deelnemer de commit-operatie uitvoert na het wachten op de timeout. Dit veroorzaakt data-inconsistenties met andere deelnemers die het abort-commando ontvangen en een rollback uitvoeren.
|
Geplaatst op 17-03-2021 10:15:10
|
|
|
