Špecifikácia XA
XA je špecifikácia rozhrania (t. j. rozhraniová funkcia) medzi transakčným middleware a databázou definovanou X/Open DTP, ktorú transakčný middleware používa na informovanie databázy o začiatku, koncom, commite, rollback a podobne transakcií. Funkcie rozhrania XA poskytujú dodávatelia databáz. Dohoda o podriadení druhého rádu a dohoda o podriadení tretieho rádu boli odvodené z tejto myšlienky. Dá sa povedať, že dvojstupňové commity sú v skutočnosti kľúčom k implementácii XA distribuovaných transakcií (presnejšie: dvojstupňové commity hlavne zabezpečujú atomicitu distribuovaných transakcií: teda všetky uzly buď robia všetko, alebo nič)
2PC
Dvojfázový commit označuje algoritmus navrhnutý na udržiavanie konzistentnosti transakčných commitov pre všetky uzly založený na architektúre distribuovaného systému v oblasti počítačových sietí a databáz. Často sa dvojstupňový commit označuje aj ako protokol. V distribuovanom systéme môže každý uzol vedieť úspech alebo neúspech svojej vlastnej operácie, ale nemôže vedieť úspech alebo neúspech operácií iných uzlov. Keď transakcia zasahuje do viacerých uzlov, aby sa zachovali charakteristiky ACID transakcie, je potrebné zaviesť komponent, ktorý funguje ako koordinátor, ktorý riadi výsledky všetkých uzlov (nazývaných účastníkov) a nakoniec tieto uzly inštruuje, aby výsledky skutočne odoslali (napríklad zápisom aktualizovaných dát na disk a pod.). Preto možno myšlienku algoritmu dvojstupňového podania zhrnúť nasledovne: účastníci informujú koordinátora o úspechu alebo neúspechu operácie a koordinátor potom rozhodne, či operáciu odovzdá alebo ju zruší na základe spätnej väzby všetkých účastníkov. Takzvané dve fázy sú: prvá fáza: fáza prípravy (fáza hlasovania) a druhá fáza: fáza podania (fáza realizácie).
Prípravná fáza
Koordinátor transakcií (manažér transakcií) posiela každému účastníkovi (správcovi zdrojov) správu Pripraviť a každý účastník buď priamo vráti zlyhanie (napríklad neúspešné overenie oprávnenia), alebo transakciu vykoná lokálne, zapíše lokálne logy redo a undo, ale nezaviaže a dosiahne stav "všetko je pripravené, dlží sa len východný vietor".
Fázu prípravy možno ďalej rozdeliť do nasledujúcich troch krokov:
1) Koordinačný uzol sa opýta všetkých účastníkov, či môžu vykonať hlasovanie, a začne čakať na odpoveď od každého účastníka.
2) Účastník vykonáva všetky transakčné operácie až do spustenia dotazu a zapisuje informácie Undo a Redo do logu. (Poznámka: Ak je úspešný, každý účastník už vykonal transakciu)
3) Každý účastník reaguje na otázku iniciovanú koordinačným uzlom. Ak je transakčná operácia účastníka uzla skutočne úspešne vykonaná, vráti správu "Súhlasím"; Ak transakčná operácia účastníka uzla skutočne zlyhá, vráti správu "prerušené".
Fáza podania Ak koordinátor dostane správu o zlyhaní alebo časový limit od účastníka, pošle správu o vrátení späť priamo každému účastníkovi. Inak pošlite správu Commit; Účastníci vykonávajú operácie commit alebo rollback podľa pokynov koordinátora, aby uvoľnili všetky zámkové zdroje použité v transakčnom procese. (Poznámka: Zámkové zdroje musia byť uvoľnené v záverečnej fáze)
Ďalej sa samostatne rozoberá proces podania v dvoch prípadoch.
Keď zodpovedajúca správa prijatá koordinačným uzlom od všetkých účastníkov je Súhlas:
Fáza podania Ak koordinátor dostane správu o zlyhaní alebo časový limit od účastníka, pošle správu o vrátení späť priamo každému účastníkovi. Inak pošlite správu Commit; Účastníci vykonávajú operácie commit alebo rollback podľa pokynov koordinátora, aby uvoľnili všetky zámkové zdroje použité v transakčnom procese. (Poznámka: Zámkové zdroje musia byť uvoľnené v záverečnej fáze)
Ďalej sa samostatne rozoberá proces podania v dvoch prípadoch.
Keď zodpovedajúca správa prijatá koordinačným uzlom od všetkých účastníkov je Súhlas:
1) Koordinačný uzol vyšle požiadavku "commit" všetkým účastníkom.
2) Účastník oficiálne dokončí operáciu a uvoľní zdroje obsadené počas celého obdobia transakcie.
3) Účastník odosiela správu "Hotovo" koordinačnému uzlu.
4) Koordinačný uzol dokončí transakciu po prijatí správy "Hotovo" od všetkých účastníkov. Ak ktorýkoľvek z účastníkov vráti odpoveďovú správu "Prerušené" v prvej fáze, alebo ak koordinačný uzol nedokáže získať odpoveďovú správu pre všetky účastníky pred časovým limitom dotazu v prvej fáze:
1) Koordinačný uzol vyšle požiadavku "rollback" všetkým účastníkom uvedomeným uzlom.
2) Uzol účastníka používa predtým zapísané informácie Undo na vrátenie a uvoľnenie zdrojov obsadených počas celého obdobia transakcie.
3) Účastník odošle správu "rollback complete" koordinačnému uzlu.
4) Koordinačný uzol zruší transakciu po prijatí správy "Rollback Complete" od všetkých účastníkov. Bez ohľadu na konečný výsledok druhá fáza ukončuje aktuálnu transakciu. Commity fázy 2 sa zdajú poskytovať atómové operácie, ale bohužiaľ, commity fázy 2 majú stále niekoľko nevýhod:
1. Problém synchronného blokovania. Počas vykonávania všetky zúčastnené uzly blokujú transakcie. Keď účastník obsadí verejný zdroj, ostatné uzly tretích strán musia byť zablokované v prístupe k verejnému zdroju.
2. Jediný bod zlyhania. Vzhľadom na dôležitosť koordinátora, keď koordinátor zlyhá. Účastníci budú naďalej blokovať blokádu. Najmä v druhej fáze, ak koordinátor zlyhá, všetci účastníci sú stále v stave uzamknutia transakčných prostriedkov a nemôžu pokračovať v dokončení transakčných operácií. (Ak koordinátor zloží, môžete koordinátora znovu zvoliť, ale to nevyrieši problém, že účastník je zablokovaný kvôli tomu, že koordinátor je dole)
3. Nekonzistentnosť dát. V druhej fáze druhej fázy commitu, keď koordinátor pošle požiadavku na commit účastníkovi, nastane výnimka v lokálnej sieti alebo koordinátor zlyhá počas procesu commit request, čo spôsobí, že požiadavku commit prijmú len niektorí účastníci. Po prijatí požiadavky na commit títo účastníci vykonajú operáciu commit. Avšak iné stroje, ktoré nedostanú požiadavku na commit, nemôžu vykonať commit transakcie. V dôsledku toho dochádza k konzistencii dátového oddelenia v celom distribuovanom systéme.
4. Problémy, ktoré nie je možné vyriešiť v druhej fáze: Koordinátor padá po odoslaní commit správy a jediný účastník, ktorý túto správu dostane, je tiež dole. Takže aj keď facilitátor zvolí nového facilitátora prostredníctvom volebnej dohody, stav transakcie je neistý a nikto nevie, či bola transakcia podaná. Kvôli nedostatkom druhej fázy podávania, ako je synchronné blokovanie, problém s jedným bodom a rozdelený mozog, výskumníci urobili zlepšenia na základe druhej fázy podania a navrhli trojstupňové podanie odovzdania.
3PC
Trojfázový commit, známy aj ako protokol trojfázového commitu, je vylepšenou verziou dvojfázového commitu (2PC).
Na rozdiel od dvojstupňových commitov existujú pri trojstupňových commitoch dve zmeny.
1. Zaviesť mechanizmus timeoutu. Zároveň je zavedený mechanizmus timeoutu u facilitátora aj účastníkov. 2. Vložiť prípravnú fázu do prvej a druhej fázy. To zabezpečuje, že stav všetkých zúčastnených uzlov je konzistentný až do finálnej fázy commitu. Inými slovami, okrem zavedenia mechanizmu timeoutu 3PC opäť rozdeľuje prípravnú fázu 2PC na dve, takže v troch fázach commit sú tri fázy: CanCommit, PreCommit a DoCommit.
Fáza CanCommit
Fáza CanCommit v 3PC je veľmi podobná prípravnej fáze 2PC. Koordinátor pošle účastníkovi žiadosť o commit, ktorý odpovie áno, ak sa mu podarí commitovať, alebo Nie. 1. Dotaz na transakciu Facilitátor odošle účastníkovi požiadavku CanCommit. Opýtajte sa, či môžete vykonať operáciu potvrdenia transakcie. Potom začnite čakať na odpoveď od účastníkov. 2. Odpoveď Spätná väzba Po prijatí požiadavky CanCommit účastník vráti odpoveď Áno a vstúpi do stavu pripravenosti, ak si myslí, že transakcia môže byť vykonaná hladko. Inak spätná väzba Nie
Fáza PreCommit
Facilitátor rozhoduje, či si zapamätá operáciu PreCommit transakcie na základe odpovede účastníka. V závislosti od odpovede existujú dve možnosti. Ak je spätná väzba, ktorú facilitátor dostane od všetkých účastníkov, odpoveď Áno, potom sa vykoná predbežné vykonanie transakcie.
1. Odoslanie požiadavky na predbežný záväzok Facilitátor odošle účastníkovi požiadavku na predbežný záväzok a pokračuje do fázy prípravy.
2. Transakcia Pre-Commit Po prijatí požiadavky na PreCommit účastník vykoná operáciu transakcie a zaznamená informácie o vrátení a opätovnom vykonaní v denníku transakcií.
3. Spätná väzba z odpovede Ak účastník úspešne vykoná transakciu, vráti sa odpoveď ACK počas čakania na poslednú inštrukciu. Ak ktorýkoľvek účastník pošle koordinátorovi odpoveď Nie, alebo čaká na časový limit, a koordinátor od účastníka nedostane odpoveď, transakcia je prerušená.
1. Odoslať požiadavku na prerušenie Facilitátor pošle žiadosť o prerušenie všetkým účastníkom.
2. Prerušenie transakcie Po prijatí požiadavky ABORT od koordinátora účastníkom (alebo po uplynutí timeoutu, keď požiadavka od koordinátora nebola prijatá), sa prerušenie transakcie vykoná. fáza doCommit
Táto fáza skutočného transakčného záväzku sa dá tiež rozdeliť na nasledujúce dve situácie.
Vykonajte commit
1. Odoslanie požiadavky na commit Koordinácia prijme ACK odpoveď zaslanú účastníkom, potom prejde zo stavu predcommit do stavu commit. a poslať žiadosť o doCommit všetkým účastníkom.
2. Odoslanie transakcie Po prijatí požiadavky doCommit účastník vykoná formálny commit transakcie. a po dokončení transakčného potvrdenia uvoľnia všetky transakčné zdroje.
3. Odpovedať na spätnú väzbu Po odoslaní transakcie pošlite koordinátorovi odpoveď Ack.
4. Dokončiť transakciu Po prijatí odpovede ACK od všetkých účastníkov je transakcia dokončená. Prerušovacie transakcie
Ak koordinátor nedostane odpoveď ACK od účastníka (nemusí to byť odpoveď ACK od prijímača, alebo odpoveď mohla vypršať), transakcia prerušenia sa vykoná.
1. Odoslanie požiadavky na prerušenie Facilitátor odošle žiadosť o prerušenie všetkým účastníkom
2. Vrátenie transakcie Po prijatí požiadavky ABORT účastník použije informácie o vrátení transakcie zaznamenané vo fáze 2 na vykonanie operácie vrátenia transakcie a po jej dokončení uvoľní všetky transakčné zdroje.
3. Výsledky spätnej väzby Po dokončení vrátenia transakcie účastníkom pošlite koordinátorovi správu ACK
4. Prerušiť transakciu Po prijatí ACK správy od účastníka je transakcia prerušená. Vo fáze doCommit, ak účastník nemôže včas prijať žiadosť o doCommit alebo rebort od koordinátora, transakcia bude pokračovať v odosielaní aj po uplynutí timeoutu. (V skutočnosti by sa to malo určiť na základe pravdepodobnosti, že pri vstupe do tretej fázy to znamená, že účastník dostal požiadavku PreCommit v druhej fáze, takže podmienkou pre koordinátora na vygenerovanie požiadavky PreCommit je, že dostane odpoveď Yes CanCommit od všetkých účastníkov pred začiatkom druhej fázy.) (Keď účastník dostane PreCommit, znamená to, že vie, že všetci skutočne súhlasia s úpravou.) Takže jednoducho povedané, pri vstupe do tretej fázy, kvôli timeoutom siete a iným dôvodom, hoci účastník nedostal odpoveď na commit alebo abort, má dôvod veriť, že pravdepodobnosť úspešného commitu je veľmi vysoká. )
Rozdiel medzi 2PC a 3PC
V porovnaní s 2PC sa 3PC hlavne rieši problém jedného bodu zlyhania a znižuje blokovanie, pretože keď účastník nestihne včas prijať správu od koordinátora, automaticky vykoná commit. Namiesto toho, aby ste neustále držali transakčné zdroje a boli v blokujúcom stave. Tento mechanizmus však spôsobuje aj problémy s konzistenciou dát, pretože odpoveď na prerušenie odoslaná koordinátorom nie je účastníkom prijatá včas kvôli sieťovým dôvodom, potom účastník vykoná operáciu commit po čakaní na časový limit. To vytvára nezrovnalosti v dátach s ostatnými účastníkmi, ktorí dostanú príkaz na prerušenie a vykonajú rollback.
|