XA規(guī)范

X/Open?組織（即現(xiàn)在的?Open?Group?）定義了分布式事務(wù)處理模型。?X/Open?DTP?模型（?1994?）包括應(yīng)用程序（?AP?）、事務(wù)管理器（?TM?）胳螟、資源管理器（?RM?）、通信資源管理器（?CRM?）四部分。一般层宫，常見的事務(wù)管理器（?TM?）是交易中間件，常見的資源管理器（?RM?）是數(shù)據(jù)庫其监，常見的通信資源管理器（?CRM?）是消息中間件萌腿。? ??通常把一個(gè)數(shù)據(jù)庫內(nèi)部的事務(wù)處理，如對多個(gè)表的操作抖苦，作為本地事務(wù)看待毁菱。數(shù)據(jù)庫的事務(wù)處理對象是本地事務(wù)，而分布式事務(wù)處理的對象是全局事務(wù)锌历。?? 所謂全局事務(wù)贮庞，是指分布式事務(wù)處理環(huán)境中，多個(gè)數(shù)據(jù)庫可能需要共同完成一個(gè)工作辩涝，這個(gè)工作即是一個(gè)全局事務(wù)贸伐，例如，一個(gè)事務(wù)中可能更新幾個(gè)不同的數(shù)據(jù)庫怔揩。對數(shù)據(jù)庫的操作發(fā)生在系統(tǒng)的各處但必須全部被提交或回滾捉邢。此時(shí)一個(gè)數(shù)據(jù)庫對自己內(nèi)部所做操作的提交不僅依賴本身操作是否成功，還要依賴與全局事務(wù)相關(guān)的其它數(shù)據(jù)庫的操作是否成功商膊，如果任一數(shù)據(jù)庫的任一操作失敗伏伐，則參與此事務(wù)的所有數(shù)據(jù)庫所做的所有操作都必須回滾。?? ??一般情況下晕拆，某一數(shù)據(jù)庫無法知道其它數(shù)據(jù)庫在做什么藐翎，因此，在一個(gè)?DTP?環(huán)境中实幕，交易中間件是必需的吝镣，由它通知和協(xié)調(diào)相關(guān)數(shù)據(jù)庫的提交或回滾。而一個(gè)數(shù)據(jù)庫只將其自己所做的操作（可恢復(fù)）影射到全局事務(wù)中昆庇。????

XA?就是?X/Open?DTP?定義的交易中間件與數(shù)據(jù)庫之間的接口規(guī)范（即接口函數(shù)）末贾，交易中間件用它來通知數(shù)據(jù)庫事務(wù)的開始、結(jié)束以及提交整吆、回滾等拱撵。?XA?接口函數(shù)由數(shù)據(jù)庫廠商提供辉川。?

二階提交協(xié)議和三階提交協(xié)議就是根據(jù)這一思想衍生出來的∷┎猓可以說二階段提交其實(shí)就是實(shí)現(xiàn)XA分布式事務(wù)的關(guān)鍵(確切地說：兩階段提交主要保證了分布式事務(wù)的原子性：即所有結(jié)點(diǎn)要么全做要么全不做)

2PC

二階段提交(Two-phaseCommit)是指乓旗，在計(jì)算機(jī)網(wǎng)絡(luò)以及數(shù)據(jù)庫領(lǐng)域內(nèi)，為了使基于分布式系統(tǒng)架構(gòu)下的所有節(jié)點(diǎn)在進(jìn)行事務(wù)提交時(shí)保持一致性而設(shè)計(jì)的一種算法(Algorithm)集索。通常屿愚，二階段提交也被稱為是一種協(xié)議(Protocol))。在分布式系統(tǒng)中抄谐，每個(gè)節(jié)點(diǎn)雖然可以知曉自己的操作時(shí)成功或者失敗渺鹦，卻無法知道其他節(jié)點(diǎn)的操作的成功或失敗。當(dāng)一個(gè)事務(wù)跨越多個(gè)節(jié)點(diǎn)時(shí)蛹含，為了保持事務(wù)的ACID特性毅厚，需要引入一個(gè)作為協(xié)調(diào)者的組件來統(tǒng)一掌控所有節(jié)點(diǎn)(稱作參與者)的操作結(jié)果并最終指示這些節(jié)點(diǎn)是否要把操作結(jié)果進(jìn)行真正的提交(比如將更新后的數(shù)據(jù)寫入磁盤等等)。因此浦箱，二階段提交的算法思路可以概括為：參與者將操作成敗通知協(xié)調(diào)者吸耿，再由協(xié)調(diào)者根據(jù)所有參與者的反饋情報(bào)決定各參與者是否要提交操作還是中止操作。

所謂的兩個(gè)階段是指：第一階段：準(zhǔn)備階段(投票階段)和第二階段：提交階段（執(zhí)行階段）酷窥。

準(zhǔn)備階段

事務(wù)協(xié)調(diào)者(事務(wù)管理器)給每個(gè)參與者(資源管理器)發(fā)送Prepare消息咽安，每個(gè)參與者要么直接返回失敗(如權(quán)限驗(yàn)證失敗)，要么在本地執(zhí)行事務(wù)蓬推，寫本地的redo和undo日志妆棒，但不提交，到達(dá)一種“萬事俱備沸伏，只欠東風(fēng)”的狀態(tài)糕珊。

可以進(jìn)一步將準(zhǔn)備階段分為以下三個(gè)步驟：

1）協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)詢問是否可以執(zhí)行提交操作(vote)，并開始等待各參與者節(jié)點(diǎn)的響應(yīng)毅糟。

2）參與者節(jié)點(diǎn)執(zhí)行詢問發(fā)起為止的所有事務(wù)操作红选，并將Undo信息和Redo信息寫入日志。（注意：若成功這里其實(shí)每個(gè)參與者已經(jīng)執(zhí)行了事務(wù)操作）

3）各參與者節(jié)點(diǎn)響應(yīng)協(xié)調(diào)者節(jié)點(diǎn)發(fā)起的詢問姆另。如果參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行成功喇肋，則它返回一個(gè)”同意”消息；如果參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行失敗迹辐，則它返回一個(gè)”中止”消息蝶防。

提交階段

如果協(xié)調(diào)者收到了參與者的失敗消息或者超時(shí)，直接給每個(gè)參與者發(fā)送回滾(Rollback)消息明吩；否則间学，發(fā)送提交(Commit)消息；參與者根據(jù)協(xié)調(diào)者的指令執(zhí)行提交或者回滾操作贺喝，釋放所有事務(wù)處理過程中使用的鎖資源菱鸥。(注意:必須在最后階段釋放鎖資源)

接下來分兩種情況分別討論提交階段的過程。

當(dāng)協(xié)調(diào)者節(jié)點(diǎn)從所有參與者節(jié)點(diǎn)獲得的相應(yīng)消息都為”同意”時(shí):

1）協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出”正式提交(commit)”的請求躏鱼。

2）參與者節(jié)點(diǎn)正式完成操作氮采，并釋放在整個(gè)事務(wù)期間內(nèi)占用的資源。

3）參與者節(jié)點(diǎn)向協(xié)調(diào)者節(jié)點(diǎn)發(fā)送”完成”消息染苛。

4）協(xié)調(diào)者節(jié)點(diǎn)受到所有參與者節(jié)點(diǎn)反饋的”完成”消息后鹊漠，完成事務(wù)。

如果任一參與者節(jié)點(diǎn)在第一階段返回的響應(yīng)消息為”中止”茶行，或者 協(xié)調(diào)者節(jié)點(diǎn)在第一階段的詢問超時(shí)之前無法獲取所有參與者節(jié)點(diǎn)的響應(yīng)消息時(shí)：

1）協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出”回滾操作(rollback)”的請求躯概。

2）參與者節(jié)點(diǎn)利用之前寫入的Undo信息執(zhí)行回滾，并釋放在整個(gè)事務(wù)期間內(nèi)占用的資源畔师。

3）參與者節(jié)點(diǎn)向協(xié)調(diào)者節(jié)點(diǎn)發(fā)送”回滾完成”消息娶靡。

4）協(xié)調(diào)者節(jié)點(diǎn)受到所有參與者節(jié)點(diǎn)反饋的”回滾完成”消息后，取消事務(wù)看锉。

　　不管最后結(jié)果如何姿锭，第二階段都會結(jié)束當(dāng)前事務(wù)。

二階段提交看起來確實(shí)能夠提供原子性的操作伯铣，但是二階段提交還是有幾個(gè)缺點(diǎn)的：

1呻此、同步阻塞問題。執(zhí)行過程中腔寡，所有參與節(jié)點(diǎn)都是事務(wù)阻塞型的焚鲜。當(dāng)參與者占有公共資源時(shí)，其他第三方節(jié)點(diǎn)訪問公共資源不得不處于阻塞狀態(tài)放前。

2忿磅、單點(diǎn)故障。由于協(xié)調(diào)者的重要性犀斋，一旦協(xié)調(diào)者發(fā)生故障贝乎。參與者會一直阻塞下去。尤其在第二階段叽粹，協(xié)調(diào)者發(fā)生故障览效，那么所有的參與者還都處于鎖定事務(wù)資源的狀態(tài)中，而無法繼續(xù)完成事務(wù)操作虫几。（如果是協(xié)調(diào)者掛掉锤灿，可以重新選舉一個(gè)協(xié)調(diào)者，但是無法解決因?yàn)閰f(xié)調(diào)者宕機(jī)導(dǎo)致的參與者處于阻塞狀態(tài)的問題）

3辆脸、數(shù)據(jù)不一致但校。在二階段提交的階段二中，當(dāng)協(xié)調(diào)者向參與者發(fā)送commit請求之后啡氢，發(fā)生了局部網(wǎng)絡(luò)異匙创眩或者在發(fā)送commit請求過程中協(xié)調(diào)者發(fā)生了故障术裸，這回導(dǎo)致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之后就會執(zhí)行commit操作亭枷。但是其他部分未接到commit請求的機(jī)器則無法執(zhí)行事務(wù)提交袭艺。于是整個(gè)分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)不一致的現(xiàn)象。

4叨粘、二階段無法解決的問題：協(xié)調(diào)者再發(fā)出commit消息之后宕機(jī)猾编，而唯一接收到這條消息的參與者同時(shí)也宕機(jī)了。那么即使協(xié)調(diào)者通過選舉協(xié)議產(chǎn)生了新的協(xié)調(diào)者升敲，這條事務(wù)的狀態(tài)也是不確定的答倡，沒人知道事務(wù)是否被已經(jīng)提交。