Specifikacija XA
XA je specifikacija vmesnika (tj. funkcija vmesnika) med transakcijsko vmesno programsko opremo in podatkovno bazo, definirano z X/Open DTP, ki jo transakcijski vmesnik uporablja za obveščanje baze podatkov o začetku, koncu, potrditvi, razveljavitvi itd. transakcij. Funkcije vmesnika XA zagotavljajo ponudniki podatkovnih baz.
Sporazum o podreditvi drugega reda in sporazum o podreditvi tretjega reda sta izhajala iz te ideje. Lahko rečemo, da so dvostopenjske potrditve pravzaprav ključ do implementacije XA distribuiranih transakcij (natančneje: dvostopenjske potrditve predvsem zagotavljajo atomičnost porazdeljenih transakcij: to pomeni, da vsa vozlišča naredijo vse ali nič)
2PC
Dvofazni commit se nanaša na algoritem, zasnovan za ohranjanje doslednosti transakcijskih potrditev za vsa vozlišča na podlagi arhitekture distribuiranega sistema na področju računalniških omrežij in podatkovnih baz. Pogosto se dvostopenjski commit imenuje tudi protokol. V distribuiranem sistemu lahko vsako vozlišče ve uspeh ali neuspeh svoje operacije, vendar ne more vedeti uspeha ali neuspeha operacij drugih vozlišč. Ko transakcija zajema več vozlišč, je za ohranitev značilnosti ACID transakcije treba uvesti komponento, ki deluje kot koordinator, ki nadzoruje rezultate vseh vozlišč (imenovanih udeleženci) in na koncu tem vozliščem naroči, naj dejansko oddajo rezultate (na primer zapisovanje posodobljenih podatkov na disk itd.). Zato lahko idejo algoritma za dvostopenjsko oddajo povzamemo takole: udeleženci bodo koordinatorja obvestili o uspehu ali neuspehu operacije, nato pa bo koordinator na podlagi povratnih informacij vseh udeležencev odločil, ali bo operacijo oddal ali operacijo prekinil.
Tako imenovani dve fazi sta: prva faza: faza priprave (faza glasovanja) in druga faza: faza oddaje (faza izvedbe).
Pripravljalna faza
Koordinator transakcij (upravitelj transakcij) pošlje sporočilo Prepare vsakemu udeležencu (upravljavcu virov), vsak udeleženec pa bodisi neposredno vrne napako (na primer neuspešno preverjanje dovoljenja), ali pa transakcijo izvede lokalno, zapiše lokalne dnevnike ponovnega in razveljavitvenega postopka, vendar ne potrdi in doseže stanje "vse je pripravljeno, dolguje se le vzhodni veter".
Pripravljalno fazo lahko dodatno razdelimo na naslednje tri korake:
1) Koordinatorsko vozlišče vpraša vsa vozlišča udeležencev, ali lahko izvedejo glasovanje, in začne čakati na odgovor vsakega vozlišča udeležencev.
2) Vozlišče udeleženca izvaja vse transakcijske operacije, dokler poizvedba ni sprožena, nato pa v dnevnik zapiše informacije Razveljavi in Ponovi. (Opomba: Če je uspešen, je vsak udeleženec že izvedel transakcijsko operacijo)
3) Vsako vozlišče udeležencev odgovori na poizvedbo, ki jo sproži koordinatorsko vozlišče. Če je transakcijska operacija udeležencevega vozlišča dejansko uspešno izvedena, vrne sporočilo "Strinjam se"; Če transakcijska operacija udeleženskega vozlišča dejansko odpove, vrne sporočilo "prekinjeno".
Faza predaje
Če koordinator prejme sporočilo o neuspehu ali časovni omejitvi od udeleženca, pošlje sporočilo o povračilu neposredno vsakemu udeležencu. V nasprotnem primeru pošljite sporočilo Commit; Udeleženci izvajajo operacije potrditve ali razveljavitve v skladu z navodili koordinatorja, da sprostijo vse zaklepne vire, uporabljene v transakcijskem procesu. (Opomba: Zaklepni viri morajo biti sproščeni v zadnji fazi)
Nato je postopek oddaje obravnavan ločeno v dveh primerih.
Ko je ustrezno sporočilo, ki ga je koordinatorsko vozlišče prejelo od vseh udeležencev, Strinjaj se:
Faza predaje
Če koordinator prejme sporočilo o neuspehu ali časovni omejitvi od udeleženca, pošlje sporočilo o povračilu neposredno vsakemu udeležencu. V nasprotnem primeru pošljite sporočilo Commit; Udeleženci izvajajo operacije potrditve ali razveljavitve v skladu z navodili koordinatorja, da sprostijo vse zaklepne vire, uporabljene v transakcijskem procesu. (Opomba: Zaklepni viri morajo biti sproščeni v zadnji fazi)
Nato je postopek oddaje obravnavan ločeno v dveh primerih.
Ko je ustrezno sporočilo, ki ga je koordinatorsko vozlišče prejelo od vseh udeležencev, Strinjaj se:
1) Koordinatorsko vozlišče pošlje zahtevo "commit" vsem udeležencem vozliščem.
2) Udeležensko vozlišče uradno zaključi operacijo in sprosti vire, zasedene skozi celotno obdobje transakcije.
3) Udeležensko vozlišče pošlje sporočilo "Opravljeno" koordinatorskemu vozlišču.
4) Koordinatorsko vozlišče zaključi transakcijo po prejemu povratne informacije o sporočilu »Opravljeno« od vseh udeležencev.
1) Koordinatorsko vozlišče pošlje zahtevo za "povrnitev nazaj" vsem udeležencem vozliščem.
2) Vozlišče udeleženca uporabi predhodno zapisane informacije Razveljavi za izvedbo razveljavitve in sprostitve virov, ki so zasedeni skozi celotno obdobje transakcije.
3) Udeležensko vozlišče pošlje sporočilo "rollback complete" koordinatorskemu vozlišču.
4) Koordinatorsko vozlišče prekliče transakcijo po prejemu povratne informacije "Rollback Complete" od vseh udeležencev.
Potrditve faze 2 res omogočajo atomske operacije, vendar imajo žal potrditve faze 2 še vedno nekaj slabosti:
1. Problem sinhronega blokiranja. Med izvajanjem vsa sodelujoča vozlišča blokirajo transakcije. Ko udeleženec zaseda javni vir, je treba drugim vozliščem tretjih oseb blokirati dostop do javnega vira.
2. Ena sama točka odpovedi. Zaradi pomembnosti koordinatorja, ko koordinator odpove. Udeleženci bodo še naprej blokirali blokado. Še posebej v drugi fazi, če koordinator odpove, so vsi udeleženci še vedno v stanju zaklepanja transakcijskih virov in ne morejo nadaljevati z izvajanjem transakcijskih operacij. (Če koordinator odloži slušalko, lahko ponovno izberete koordinatorja, vendar to ne reši problema, da je udeleženec blokiran zaradi odpovedi)
3. Neskladje podatkov. V drugi fazi druge faze potrditve, ko koordinator pošlje zahtevo po potrditvi udeležencu, pride do izjeme lokalnega omrežja ali pa koordinator med postopkom zahteve za potrjevanje odpove, kar povzroči, da zahtevo sprejmejo le nekateri udeleženci. Po prejemu zahteve za potrjevanje ti udeleženci izvedejo operacijo potrditve. Vendar pa drugi stroji, ki ne prejmejo zahteve za potrjevanje, ne morejo izvesti potrditve transakcije. Zaradi tega se doslednost podatkovnega oddelka pojavi v celotnem distribuiranem sistemu.
4. Težave, ki jih ni mogoče rešiti v drugi fazi: Koordinator pade po pošiljanju potrditvenega sporočila, edini udeleženec, ki prejme to sporočilo, pa je prav tako dol. Tako tudi če posrednik izvoli novega posrednika preko volilnega sporazuma, je status transakcije negotov in nihče ne ve, ali je bila transakcija že oddana.
3PC
Trifazni potrditveni protokol, znan tudi kot protokol trifaznega potrjevanja, je izboljšana različica dvofaznega potrjevanja (2PC).
Za razliko od dvostopenjskih commitov obstajata dve spremembi pri tristopenjskih commitih.
1. Uvedba mehanizma za časovno omejitev. Hkrati se pri facilitatorju in udeležencih uvede mehanizem časovne pavze.
2. Vstavite pripravljalno fazo v prvo in drugo fazo. To zagotavlja, da je stanje vseh sodelujočih vozlišč dosledno do končne faze potrditve.
Z drugimi besedami, poleg uvedbe mehanizma časovne omejitve 3PC ponovno razdeli pripravljalno fazo 2PC na dva dela, tako da so v treh fazah potrditve tri faze: CanCommit, PreCommit in DoCommit.
Faza CanCommit
Faza CanCommit v 3PC je pravzaprav zelo podobna pripravljalni fazi 2PC. Koordinator pošlje zahtevo za potrditev udeležencu, ki odgovori z Da, če se lahko zavezuje, ali z Ne.
1. Poizvedba o transakciji Facilitator pošlje zahtevo CanCommit udeležencu. Vprašajte, ali lahko izvedete operacijo potrditve transakcije. Nato začnite čakati na odziv udeležencev.
2. Povratne informacije po prejemu zahteve CanCommit bo udeleženec vrnil odgovor 'Da' in vstopil v stanje pripravljenosti, če meni, da je transakcijo mogoče izvesti gladko. V nasprotnem primeru povratne informacije Ne
Faza predCommit
Facilitator se odloči, ali si bo operacijo PreCommit transakcije zapomnil na podlagi odziva udeleženca. Glede na odgovor obstajata dve možnosti.
Če je povratna informacija, ki jo facilitator prejme od vseh udeležencev, odgovor Da, se izvede predhodna izvedba transakcije.
1. Pošlji zahtevo za predhodno potrditev Facilitator pošlje zahtevo za predhodno potrditev udeležencu in nadaljuje s fazo priprave.
2. Predhodna potrditev transakcije Po prejemu zahteve za predhodno potrditev udeleženec izvede transakcijsko operacijo in zabeleži informacije o razveljavitvi in ponovitvi v dnevnik transakcij.
3. Povratne informacije odziva Če udeleženec uspešno izvede transakcijsko operacijo, se vrne odgovor ACK, medtem ko se čaka na končno navodilo.
1. Pošlji zahtevo za prekinitev Facilitator pošlje zahtevo za prekinitev vsem udeležencem.
2. Prekinitev transakcije Ko udeleženec prejme zahtevo ABORT od koordinatorja (ali po premoru, če zahteva koordinatorja ni prejeta), se prekinitev transakcije izvede.
To fazo resnične transakcijske zaveze lahko razdelimo tudi na naslednji dve situaciji.
Izvedite commit
1. Pošlji zahtevo za potrjevanje Koordinacija prejme odgovor ACK, ki ga pošlje udeleženec, nato pa preide iz stanja predhodne potrditve v stanje potrditve. in pošlji zahtevo za doCommit vsem udeležencem.
2. Oddaja transakcije Po prejemu zahteve doCommit udeleženec izvede formalno transakcijsko zavezo. in sprosti vse transakcijske vire po zaključku potrditve transakcije.
3. Odgovarjanje na povratne informacije Po oddaji transakcije pošljite Ack odgovor koordinatorju.
4. Zaključite transakcijo Ko koordinator prejme odgovor ACK od vseh udeležencev, je transakcija zaključena.
Če koordinator ne prejme ACK odgovora od udeleženca (morda to ni ACK odgovor prejemnika ali pa je odgovor potekel), se prekinitev izvede.
1. Pošlji zahtevo za prekinitev Facilitator pošlje zahtevo za prekinitev vsem udeležencem
2. Razveljavitev transakcije Po prejemu zahteve ABORT udeleženec uporabi informacije o razveljavitvi, zabeležene v fazi 2, za izvedbo operacije razveljavitve transakcije in po zaključku razveljavitve sprosti vse transakcijske vire.
3. Rezultati povratnih informacij Ko udeleženec zaključi razveljavitev transakcije, pošlje koordinatorju sporočilo ACK
4. Prekini transakcijo Ko koordinator prejme ACK sporočilo od udeleženca, se transakcija prekine.
Razlika med 2PC in 3PC
V primerjavi z 2PC 3PC predvsem rešuje problem ene točke okvare in zmanjšuje blokado, saj udeleženec po neprejmu sporočila od koordinatorja privzeto izvede commit. Namesto da ves čas zadržujemo transakcijske vire in smo v blokiranju. Vendar ta mehanizem povzroča tudi težave s konsistentnostjo podatkov, saj odziv za prekinitev, ki ga pošlje koordinator, zaradi omrežnih razlogov ni sprejet pravočasno, nato udeleženec izvede operacijo potrditve po čakanju na časovni iztek. To povzroča neskladja podatkov z drugimi udeleženci, ki prejmejo ukaz za prekinitev in izvedejo razveljavitev.
|
Objavljeno na 17. 03. 2021 10:15:10
|
|
|
