XA-määrittely
XA on rajapintamäärittely (eli rajapintatoiminto) transaktioväliohjelman ja X/Open DTP:n määrittelemän tietokannan välillä, jota transaktioväliohjelmisto käyttää ilmoittaakseen tietokannalle transaktioiden aloituksesta, päättymisestä, sitoutumisesta, palautuksesta jne. XA-rajapintatoiminnot tarjoavat tietokantatoimittajat.
Toisen asteen luovutussopimus ja kolmannen asteen luovutussopimus pohjautuivat tähän ajatukseen. Voidaan sanoa, että kaksivaiheiset commitit ovat itse asiassa avain XA-hajautettujen transaktioiden toteuttamiseen (tarkemmin sanottuna: kaksivaiheiset commitit varmistavat pääasiassa hajautettujen transaktioiden atomisuuden: eli kaikki solmut joko tekevät kaiken tai eivät mitään)
2PC
Kaksivaiheinen Commit tarkoittaa algoritmia, joka on suunniteltu ylläpitämään johdonmukaisuutta transaktiocommit-tilanteissa kaikille solmuille hajautetun järjestelmäarkkitehtuurin pohjalta tietoverkkojen ja tietokantojen alalla. Usein kaksivaiheista sitoutumista kutsutaan myös protokollaksi. Hajautetussa järjestelmässä jokainen solmu voi tietää oman toimintansa onnistumisen tai epäonnistumisen, mutta se ei voi tietää muiden solmujen operaatioiden onnistumista tai epäonnistumista. Kun transaktio kattaa useita solmuja, transaktion ACID-ominaisuudet säilyvät, on otettava käyttöön koordinaattorina toimiva komponentti, joka hallitsee kaikkien solmujen (osallistujien) tuloksia ja lopulta ohjaa näitä solmuja lähettämään tulokset (kuten päivitetyn datan kirjoittaminen levylle jne.). Näin ollen kaksivaiheisen lähetyksen algoritmiidea voidaan tiivistää seuraavasti: osallistujat ilmoittavat koordinaattorille operaation onnistumisesta tai epäonnistumisesta, ja koordinaattori päättää, lähettääkö operaation vai keskeytetäänkö operaation kaikkien osallistujien palautteen perusteella.
Niin sanotut kaksi vaihetta ovat: ensimmäinen vaihe: valmisteluvaihe (äänestysvaihe) ja toinen vaihe: luovutusvaihe (toteutusvaihe).
Valmisteluvaihe
Transaktioiden koordinaattori (transaction manager) lähettää Valmista-viestin jokaiselle osallistujalle (resource manager), ja jokainen osallistuja joko palauttaa virheen suoraan (esim. epäonnistuneen käyttöoikeuden vahvistuksen), tai suorittaa transaktion paikallisesti, kirjoittaa paikalliset uusinta- ja peruutuslokit, mutta ei tee sitoutumista, ja saavuttaa tilan, jossa "kaikki on valmista, vain itätuuli on velkaa".
Valmistautumisvaihe voidaan jakaa edelleen seuraaviin kolmeen vaiheeseen:
1) Koordinaattorisolmu kysyy kaikilta osallistujasolmuilta, voivatko he äänestää, ja alkaa odottaa vastausta jokaiselta osallistujasolmulta.
2) Osallistujasolmu suorittaa kaikki transaktiotoiminnot, kunnes kysely käynnistetään, ja kirjoittaa Peruutus- ja Redo-tiedot lokiin. (Huomautus: Jos onnistuu, jokainen osallistuja on jo suorittanut transaktiotoiminnon)
3) Jokainen osallistujasolmu vastaa koordinaattorisolmun aloittamaan kyselyyn. Jos osallistujasolmun transaktiooperaatio suoritetaan onnistuneesti, se palauttaa "Hyväksy"-viestin; Jos osallistujasolmun transaktiotoiminto epäonnistuu, se palauttaa "keskeytetty" -viestin.
Luovutusvaihe
Jos koordinaattori saa epäonnistumisviestin tai aikalisän osallistujalta, se lähettää palautusviestin suoraan jokaiselle osallistujalle. Muussa tapauksessa lähetä Commit-viesti; Osallistujat suorittavat commit- tai rollback-operaatioita koordinaattorin ohjeiden mukaisesti vapauttaakseen kaikki transaktioprosessissa käytetyt lukitusresurssit. (Huomautus: Lukitusresurssit on vapautettava viimeisessä vaiheessa)
Seuraavaksi käsittelyvaiheen prosessia käsitellään erikseen kahdessa tapauksessa.
Kun vastaava viesti, jonka koordinaattorisolmu vastaanottaa kaikilta osallistujasolmuilta, on Agree:
Luovutusvaihe
Jos koordinaattori saa epäonnistumisviestin tai aikalisän osallistujalta, se lähettää palautusviestin suoraan jokaiselle osallistujalle. Muussa tapauksessa lähetä Commit-viesti; Osallistujat suorittavat commit- tai rollback-operaatioita koordinaattorin ohjeiden mukaisesti vapauttaakseen kaikki transaktioprosessissa käytetyt lukitusresurssit. (Huomautus: Lukitusresurssit on vapautettava viimeisessä vaiheessa)
Seuraavaksi käsittelyvaiheen prosessia käsitellään erikseen kahdessa tapauksessa.
Kun vastaava viesti, jonka koordinaattorisolmu vastaanottaa kaikilta osallistujasolmuilta, on Agree:
1) Koordinaattorisolmu lähettää "commit"-pyynnön kaikille osallistujasolmuille.
2) Osallistujasolmu suorittaa operaation virallisesti loppuun ja vapauttaa resurssit, jotka ovat käytössä koko tapahtumajakson ajan.
3) Osallistujasolmu lähettää koordinaattorisolmulle "Valmis"-viestin.
4) Koordinaattorisolmu suorittaa transaktion saatuaan "Valmis"-viestipalautteen kaikilta osallistujasolmuilta.
1) Koordinaattorisolmu lähettää "rollback"-pyynnön kaikille osallistujasolmuille.
2) Osallistujasolmu käyttää aiemmin kirjoitettuja Peruutustietoja suorittaakseen palautuksen ja vapauttaakseen resurssit, jotka ovat käytössä koko tapahtumajakson ajan.
3) Osallistujasolmu lähettää koordinaattorisolmulle viestin "rollback complete".
4) Koordinaattorisolmu peruuttaa tapahtuman saatuaan "Rollback Complete" -viestipalautteen kaikilta osallistuvilta solmuilta.
Vaiheen 2 commitit näyttävät tarjoavan atomioperaatioita, mutta valitettavasti vaiheen 2 commitit sisältävät silti muutamia haittoja:
1. Synkroninen esto-ongelma. Suorituksen aikana kaikki osallistuvat solmut estävät transaktioita. Kun osallistuja käyttää julkista resurssia, muut kolmannen osapuolen solmut on estettävä pääsemästä julkiseen resurssiin.
2. Yksittäinen epäonnistumispiste. Koordinaattorin tärkeyden vuoksi, kun koordinaattori epäonnistuu. Osallistujat jatkavat tukoksen estämistä. Erityisesti toisessa vaiheessa, jos koordinaattori epäonnistuu, kaikki osallistujat ovat edelleen tilassa, jossa transaktioresurssit lukitaan eivätkä voi jatkaa transaktiotoimintojen suorittamista. (Jos koordinaattori lopettaa puhelun, voit valita koordinaattorin uudelleen, mutta se ei ratkaise ongelmaa, että osallistuja on estetty koordinaattorin takia)
3. Tietojen epäjohdonmukaisuus. Toisen commit-vaiheen toisessa vaiheessa, kun koordinaattori lähettää osallistujalle commit-pyynnön, syntyy paikallinen verkkopoikkeus tai koordinaattori epäonnistuu commit-pyynnön aikana, jolloin vain osa osallistujista hyväksyy commit-pyynnön. Saatuaan commit-pyynnön nämä osallistujat suorittavat commit-operaation. Kuitenkin muut koneet, jotka eivät saa commit-pyyntöä, eivät voi suorittaa transaktio-commitia. Tämän seurauksena dataosaston johdonmukaisuus tapahtuu koko hajautetussa järjestelmässä.
4. Ongelmat, joita ei voida ratkaista toisessa vaiheessa: Koordinaattori kaatuu commit-viestin lähettämisen jälkeen, ja ainoa osallistuja, joka saa tämän viestin, on myös maassa. Joten vaikka välittäjä valitsisi uuden välittäjän vaalisopimuksen kautta, tapahtuman tila on epävarma, eikä kukaan tiedä, onko kauppa toimitettu.
3PC
Kolmivaiheinen commit, joka tunnetaan myös nimellä kolmivaiheinen commit-protokolla, on parannettu versio kaksivaiheisesta commitista (2PC).
Toisin kuin kaksivaiheisissa commiteissa, kolmivaiheisiin on tehty kaksi muutosta.
1. Ota käyttöön aikalisämekanismi. Samaan aikaan otetaan käyttöön aikakatkaisumekanismi sekä fasilitaattorissa että osallistujissa.
2. Aseta valmisteluvaihe ensimmäiseen ja toiseen vaiheeseen. Tämä varmistaa, että kaikkien osallistuvien solmujen tila on johdonmukainen aina lopulliseen sitoutumisvaiheeseen asti.
Toisin sanoen, aikakatkaisumekanismin lisäksi 3PC jakaa jälleen 2PC:n valmisteluvaiheen kahteen osaan, jolloin CanCommit-, PreCommit- ja DoCommit-vaiheissa on kolme vaihetta.
CanCommit-vaihe
3PC:n CanCommit-vaihe on itse asiassa hyvin samanlainen kuin 2PC:n valmisteluvaihe. Koordinaattori lähettää sitoutumispyynnön osallistujalle, joka vastaa kyllä-vastaukseksi, jos voi sitoutua, tai ei-vastauksen.
1. Transaktiokysely Fasilitaattori lähettää osallistujalle CanCommit-pyynnön. Kysy, voitko suorittaa transaction commit -operaation. Sitten ala odottaa osallistujien vastausta.
2. Vastauspalaute CanCommit-pyynnön saatuaan osallistuja palauttaa kyllä-vastauksen ja siirtyy valmiustilaan, jos uskoo, että tapahtuma voidaan suorittaa sujuvasti. Muuten palaute Ei
PreCommit-vaihe
Fasilitaattori päättää, muistaako tapahtuman PreCommit-toiminnon osallistujan vastauksen perusteella. Vastauksesta riippuen on kaksi vaihtoehtoa.
Jos fasilitaattorin saama palaute kaikilta osallistujilta on kyllä-vastaus, tapahtuu tapahtuman esisuoritus.
1. Lähetä PreCommit-pyyntö Fasilitaattori lähettää PreCommit-pyynnön osallistujalle ja siirtyy Prepare -vaiheeseen.
2. Transaktion esisitoutuminen Kun osallistuja on vastaanottanut PreCommit-pyynnön, se suorittaa transaktiotoiminnon ja tallentaa peruutus- ja uudelleentekotiedot tapahtumalokiin.
3. Vastauspalaute Jos osallistuja suorittaa transaktiooperaation onnistuneesti, ACK-vastaus palautetaan samalla kun aloitetaan odottaa viimeistä käskyä.
1. Lähetä keskeytyspyyntö Fasilitaattori lähettää keskeytyspyynnön kaikille osallistujille.
2. Keskeytä tapahtuma Kun osallistuja on saanut ABORT-pyynnön koordinaattorilta (tai aikakatkaisun jälkeen, koordinaattorin pyyntöä ei ole vastaanotettu), tapahtuman keskeytys toteutetaan.
Tämä reaalitapahtuman sitoutumisen vaihe voidaan jakaa myös seuraaviin kahteen tilanteeseen.
Suorita sitoutuminen
1. Lähetä commit-pyyntö Koordinointi vastaanottaa osallistujan lähettämän ACK-vastauksen, jonka jälkeen hän siirtyy esisitoutumistilasta commit-tilaan. ja lähetä doCommit-pyyntö kaikille osallistujille.
2. Transaktioiden lähettäminen DoCommit-pyynnön saatuaan osallistuja suorittaa virallisen transaktio-commitin. ja vapauttaa kaikki transaktioresurssit transaktiositoumuksen suorittamisen jälkeen.
3. Vastaa palautteeseen Kun tapahtuma on lähetetty, lähetä koordinaattorille Ack-vastaus.
4. Suorita transaktio Kun koordinaattori on saanut ACK-vastauksen kaikilta osallistujilta, tapahtuma on suoritettu.
Jos koordinaattori ei saa osallistujalta ACK-vastausta (se ei välttämättä ole vastaanottajan ACK-vastaus, tai vastaus on saattanut olla aikakatkaistu), keskeytystransaktio suoritetaan.
1. Lähetä keskeytyspyyntö Fasilitaattori lähettää keskeytyspyynnön kaikille osallistujille
2. Transaktion palautus ABORT-pyynnön saatuaan osallistuja käyttää vaiheessa 2 tallennettua peruutustietoa suorittaakseen tapahtuman palautusoperaation ja vapauttaa kaikki transaktioresurssit palautuksen jälkeen.
3. Palautetulokset Kun osallistuja on suorittanut tapahtuman palauttamisen, lähetä koordinaattorille ACK-viesti
4. Keskeytä tapahtuma Kun koordinaattori saa osallistujalta ACK-viestin, tapahtuma keskeytetään.
Ero 2PC:n ja 3PC:n välillä
Verrattuna 2PC:hen 3PC ratkaisee pääasiassa yksittäisen epäonnistumispisteen ongelman ja vähentää estoa, koska kun osallistuja ei saa koordinaattorilta viestiä ajoissa, hän suorittaa commingin oletuksena. Sen sijaan, että pitäisit transaktioresursseja koko ajan ja olisivat estotilassa. Mutta tämä mekanismi aiheuttaa myös datan yhdenmukaisuusongelmia, koska koordinaattorin lähettämää keskeytysvastausta ei saa osallistuja ajoissa verkkosyiden vuoksi, minkä jälkeen osallistuja suorittaa commit-operaation odotettuaan aikakatkaisua. Tämä aiheuttaa dataristiriitoja muiden osallistujien kanssa, jotka saavat keskeytyskäskyn ja suorittavat peruutuksen.
|
Julkaistu 17.3.2021 10.15.10
|
|
|
