XA specifikáció
Az XA az interfész specifikáció (azaz interfészfunkció) a tranzakciós közmű és az X/Open DTP által meghatározott adatbázis között, amelyet a tranzakciós közmű használ arra, hogy értesítse az adatbázist a tranzakciók kezdetéről, végéről, elköteleződéséről, visszalépéséről stb. Az XA interfész funkcióit adatbázis-gyártók biztosítják. A másodrendű és a harmadrendű benyújtási megállapodás ebből az ötletből származott. Elmondható, hogy a kétfázisú commit-ek valójában a kulcsfontosságúak az XA elosztott tranzakciók megvalósításához (pontosabban: a kétfázisú commit-ek főként biztosítják az elosztott tranzakciók atomiságát: vagyis minden csomópont vagy mindent csinál, vagy semmit)
2PC
A kétfázisú Commit egy olyan algoritmust jelent, amely arra szolgál, hogy fenntartsa a tranzakciós commit-ek konzisztenciáját minden csomópont számára, elosztott rendszerarchitektúrán alapulva a számítógépes hálózatok és adatbázisok területén. Gyakran a kétszakaszos commitációt protokollnak is nevezik. Egy elosztott rendszerben minden csomópont tudja a saját működésének sikerét vagy kudarcát, de nem tudja más csomópontok működésének sikerét vagy kudarcát. Ha egy tranzakció több csomóponton is átterjed, a tranzakció ACID jellemzőinek megőrzése érdekében be kell vezetni egy koordinátorként működő komponenst, amely minden csomópont (részt vesz) eredményét irányítja, és végül utasítja ezeket a csomópontokat, hogy küldjék be az eredményeket (például frissített adatokat írjanak a lemezre stb.). Ezért a kétszakaszos beküldés algoritmusötlete a következőképpen összefoglalható: a résztvevők értesítik a koordinátort a művelet sikerességéről vagy kudarcáról, majd a koordinátor eldönti, hogy benyújtja-e a műveletet, vagy megszakítja-e a műveletet az összes résztvevő visszacsatolási információja alapján. Az úgynevezett két szakasz: az első szakasz: a felkészülési szakasz (szavazási szakasz) és a második szakasz: a beadási szakasz (kivégzős szakasz).
Előkészületi szakasz
A tranzakciókoordinátor (tranzakciókezelő) minden résztvevőnek (erőforrás-menedzser) küld egy Prepare üzenetet, és minden résztvevő vagy közvetlenül visszaadja a hibát (például sikertelen engedélyellenőrzést), vagy helyben hajtja végre a tranzakciót, helyi újracsinálás és visszavonás naplókat ír, de nem kötelez el magát, és eléri azt az állapotot, hogy "minden készen áll, csak a keleti szél tartozik".
Az előkészítési szakasz további három lépésre sorolható:
1) A koordinátor csomópont megkérdezi az összes résztvevő csomópontot, hogy szavazhatnak-e, és elkezd várni minden résztvevő csomópont válaszára.
2) A résztvevő csomópont végzi az összes tranzakciós műveletet, amíg a lekérdezés el nem indul, majd a Visszavonás és a Visszavonás adatait a naplóba írja le. (Megjegyzés: Ha sikeres, minden résztvevő már végrehajtotta a tranzakciós műveletet)
3) Minden résztvevő csomópont válaszol a koordinátor által indított lekérdezésre. Ha a résztvevő csomópont tranzakciós művelete valóban sikeresen végrehajtódik, akkor egy "Egyezik bele" üzenetet; Ha a résztvevő csomópont tranzakciós művelete valóban meghibásodik, akkor "megszakított" üzenetet küld vissza.
Feladási szakasz Ha a koordinátor hibás üzenetet vagy időkorlátot kap egy résztvevőtől, közvetlenül visszaküldi a visszajelzést minden résztvevőnek. Ellenkező esetben küldj egy Commit üzenetet; A résztvevők a koordinátor utasításai szerint végeznek commit vagy rollback műveleteket, hogy felszabadítsák az összes tranzakciós folyamatban használt zár erőforrást. (Megjegyzés: A zár erőforrásokat a végső szakaszban kell szabadítani)
Ezután a benyújtási szakasz folyamatát két esetben külön tárgyalják.
Amikor a koordinátor csomópont által minden résztvevő csomóponttól kapott megfelelő üzenet a Egyezés:
Feladási szakasz Ha a koordinátor hibás üzenetet vagy időkorlátot kap egy résztvevőtől, közvetlenül visszaküldi a visszajelzést minden résztvevőnek. Ellenkező esetben küldj egy Commit üzenetet; A résztvevők a koordinátor utasításai szerint végeznek commit vagy rollback műveleteket, hogy felszabadítsák az összes tranzakciós folyamatban használt zár erőforrást. (Megjegyzés: A zár erőforrásokat a végső szakaszban kell szabadítani)
Ezután a benyújtási szakasz folyamatát két esetben külön tárgyalják.
Amikor a koordinátor csomópont által minden résztvevő csomóponttól kapott megfelelő üzenet a Egyezés:
1) A koordinátor csomópont "commit" kérést küld ki minden résztvevő csomópontnak.
2) A résztvevő csomópont hivatalosan befejezi a műveletet, és felszabadítja a tranzakciós időszak alatt foglalt erőforrásokat.
3) A résztvevő csomópont "Kész" üzenetet küld a koordinátor csomópontnak.
4) A koordinátor csomópont befejezi a tranzakciót, miután megkapta az összes résztvevő csomóponttól a "Kész" üzenet visszajelzést. Ha bármelyik résztvevő csomópont az első fázisban "Megszakított" válaszüzenetet ad vissza, vagy ha a koordinátor csomópont nem tud minden résztvevő csomópontra válaszüzenetet kapni az első fázis lekérdezési időkorlátja előtt:
1) A koordinátor csomópont "visszafordító" kérést küld ki minden résztvevő csomópontnak.
2) A résztvevő csomópont a korábban írt Visszavonás információt használja vissza a visszavonás végrehajtására és az egész tranzakciós időszak alatt foglalt erőforrások felszabadítására.
3) A résztvevő csomópont "vissza kell fejeződnie" üzenetet küld a koordinátor csomópontnak.
4) A koordinátor csomópont lemondja a tranzakciót, miután megkapta az összes résztvevő csomóponttól a "Rollback Complete" üzenet visszajelzést. A végső eredménytől függetlenül a második szakasz véget vet a jelenlegi tranzakciónak. A 2. fázisú commit-ek látszólag atomi műveleteket biztosítanak, de sajnos a 2. szakaszú commiteknek még mindig vannak néhány hátrányuk:
1. Szinkron blokkolási probléma. Végrehajtás közben minden részt vevő csomópont tranzakciós blokkolást kap. Ha egy résztvevő egy nyilvános erőforrást foglal el, más harmadik féltől származó csomópontokat meg kell tiltani a nyilvános forráshoz való hozzáféréstől.
2. Egyetlen hibás pont. A koordinátor fontossága miatt, ha a koordinátor elhibásodik. A résztvevők továbbra is blokkolják a blokkolódást. Különösen a második szakaszban, ha a koordinátor meghibásodik, minden résztvevő továbbra is zárolt tranzakciós erőforrások állapotában van, és nem tudja folytatni a tranzakciós műveleteket. (Ha a koordinátor leteszi a telefont, újraválaszthatod a koordinátort, de ez nem oldja meg azt a problémát, hogy a résztvevő blokkolva van, mert a koordinátor leállt)
3. Adatkonzisztenciál. A második commit szakasz második szakaszában, amikor a koordinátor commit kérést küld a résztvevőnek, helyi hálózati kivétel történik, vagy a koordinátor meghibásodik a commit kérés során, így csak néhány résztvevő fogadja el a commit kérést. A commit kérés megérkezése után ezek a résztvevők végrehajtják a commit műveletet. Azonban más gépek, amelyek nem kapnak commit kérést, nem tudják végrehajtani a tranzakciós commitot. Ennek eredményeként az adatosztály konzisztenciája az egész elosztott rendszerben megtörténik.
4. A második szakaszban nem oldható problémák: a koordinátor a commit üzenet küldése után leesik, és az egyetlen résztvevő, aki ezt az üzenetet kapja, szintén leáll. Tehát még ha a közvetítő választási megállapodás alapján új facilitátort választ is, az ügylet státusza bizonytalan, és senki sem tudja, hogy benyújtották-e az ügyletet. A második beküldési szakasz hibái, mint például szinkron blokkolás, egypontos probléma és felosztott agy miatt a kutatók a második beküldési szakasz alapján fejlesztéseket hajtottak végre, és háromlépcsős beküldést javasoltak.
3PC
A háromfázisú commit, más néven háromfázisú commit protokoll, a kétfázisú commit (2PC) továbbfejlesztett változata.
A kétszakaszos commitekkel ellentétben két változtatás van a háromszakaszos commitokban.
1. Vezetj be egy időkorlátot. Ugyanakkor mind a facilitátorban, mind a résztvevőkben időtúllépési mechanizmust vezetnek be. 2. Helyezzen be egy előkészítő szakaszt az első és második szakaszba. Ez biztosítja, hogy minden résztvevő csomópont állapota következetes legyen egészen a végső comcoming-ig. Más szóval, a 3PC egy időkilépési mechanizmus bevezetése mellett ismét két részre osztja a 2PC előkészítési szakaszát, így a három szakaszban három szakasz van a CanCommit, PreCommit és DoCommit szakaszban.
CanCommit szakasz
A 3PC CanCommit szakasza valójában nagyon hasonló a 2PC-s felkészülési szakaszához. A koordinátor elküld egy comcomitási kérelmet a résztvevőnek, aki igen, ha el tud kötelezni magát, vagy Nem-választ ad. 1. Tranzakciós lekérdezés A facilitátor CanCommit kérést küld a résztvevőnek. Kérdezd meg, hogy végrehajthatsz-e tranzakciós commit műveletet. Ezután kezdj el várni a résztvevők válaszára. 2. Válaszvisszajelzés A CanCommit kérés megkapása után a résztvevő igen választ ad, és kész állapotba lép, ha úgy gondolja, hogy a tranzakció zökkenőmentesen végrehajtható. Egyébként visszajelzés Nincs
PreCommit fázis
A facilitátor dönt arról, hogy megjegyezi-e a tranzakció PreCommit műveletét a résztvevő válasza alapján. A választól függően két lehetőség van. Ha a facilitátor minden résztvevőtől kapott visszajelzés igen, akkor a tranzakció előlevezetése megtörténik.
1. Küldés előre kötelező kérést A facilitátor PreCommit kérést küld a résztvevőnek, majd továbblép az Prepare szakaszra.
2. Tranzakció elő-elköteleződés Miután a résztvevő megkapja a PreCommit kérést, végrehajtja a tranzakciós műveletet, és rögzíti a visszavonási és újrakezdési információkat a tranzakciónaplóban.
3. Válaszvisszajelzés Ha a résztvevő sikeresen végrehajtja a tranzakciós műveletet, ACK válasz érkezik, miközben elkezdi várni a végső utasítást. Ha bármelyik résztvevő nem választ küld a koordinátornak, vagy vár egy időkérésre, és a koordinátor nem kap választ a résztvevőtől, akkor a tranzakció megszakad.
1. Megszakítási kérés küldése A facilitátor minden résztvevőnek elküld egy megszakítási kérelmet.
2. A tranzakció megszakítása Miután a résztvevő megkapta az ABORT kérést a koordinátortól (vagy az időkérés után a koordinátor kérését nem kapta meg), a tranzakció megszakítása végrehajtásra kerül. doCommit fázis
Ez a valódi tranzakciós elköteleződési szakasz a következő két helyzetre is felosztható.
Végezz egy commitációt
1. Küldés kérést A Koordináció megkapja a résztvevő által küldött ACK választ, majd átlép az elő-commit állapotból a commit állapotba. és küldjön egy doCommit kérést minden résztvevőnek.
2. Tranzakció beküldése A doCommit kérés megérkezése után a résztvevő végrehajtja a hivatalos tranzakciós commit. és minden tranzakciós erőforrást szabadon fel a tranzakciós kötelezettségvállalás befejezése után.
3. Válasz a visszajelzésekre A tranzakció benyújtása után küldj Ack választ a koordinátornak.
4. A tranzakció befejezése Miután a koordinátor megkapta az ACK választ minden résztvevőtől, a tranzakció befejeződik. Megszakítási tranzakciók
Ha a koordinátor nem kap ACK választ a résztvevőtől (lehet, hogy nem ACK válasz a fogadótól, vagy a válasz időlejárt volt), akkor a megszakítás tranzakció végrehajtásra kerül.
1. Megszakítási kérés küldése A facilitátor minden résztvevőnek elküld egy megszakítási kérelmet
2. Tranzakció visszafordítása Az ABORT kérés megérkezése után a résztvevő a 2. fázisban rögzített visszavonási információt használja a tranzakció visszafordító művelet végrehajtásához, és a visszahúzás befejezése után minden tranzakciós erőforrást felszabadít.
3. Visszacsatolási eredmények Miután a résztvevő befejezte a tranzakció visszafordítását, küldjön ACK üzenetet a koordinátornak
4. A tranzakció megszakítása Miután a koordinátor megkapta az ACK üzenetet a résztvevőtől, a tranzakció megszakításra kerül. A doCommit fázisban, ha a résztvevő nem tudja időben megkapni a koordinátortól a doCommit vagy rebort kérelmét, a tranzakció továbbra is benyújtásra kerül az időkérés után. (Valójában ezt a valószínűség alapján kell meghatározni, amikor a harmadik szakaszba lépünk, az azt jelenti, hogy a résztvevő megkapta a PreCommit kérést a második szakaszban, így a koordinátor előfeltétele, hogy minden résztvevőtől Yes CanCommit választ kapjon a második szakasz kezdete előtt.) (Amint a résztvevő megkapja a Precommitot, az azt jelenti, hogy tudja, hogy mindenki valóban egyetért a módosítással) Tehát egy szóval, amikor a harmadik szakaszba lépnek, hálózati időkorlátok és egyéb okok miatt, bár a résztvevő nem kapott commit vagy megszakítási választ, okuk van feltételezni, hogy a sikeres commit valószínűsége nagyon magas. )
A különbség a 2PC és a 3PC között
A 2PC-hez képest a 3PC főként az egyetlen hibapont problémáját oldja meg, és csökkenti a blokkolást, mert ha a résztvevő nem kap időben üzenetet a koordinátortól, alapértelmezés szerint végrehajtja a commit. Ahelyett, hogy folyamatosan tartanánk tranzakciós erőforrásokat és blokkoló állapotban lennének. De ez a mechanizmus az adatok konzisztenciája problémáit is okozza, mivel a koordinátor által küldött megszakítási válasz hálózati okokból nem érkezik meg időben a résztvevőhöz, majd a résztvevő végrehajtja a commit műveletet, miután megvárja az időkérést. Ez adatellentmondásokat okoz más résztvevőkkel, akik megkapják az abort parancsot és visszafordítást hajtanak végre.
|