詳見：http://blog.yemou.net/article/query/info/tytfjhfascvhzxcyt369

這一幾天一直在回顧事務(wù)相關(guān)的知識(shí)，也準(zhǔn)備把以前了解皮毛的知識(shí)進(jìn)行一些深入總結(jié)，雖然這一些知識(shí)并沒有用到，但是了解其實(shí)現(xiàn)原理還是很有必要的，因?yàn)橹懒嗽恚阋材馨阉鼘?shí)現(xiàn)出來。

在上一節(jié)事務(wù)的編程模型里面，主要說明了三種編程模型，一般情況下，我們都接觸的是單一資源的事務(wù)，也就是單獨(dú)對(duì)一個(gè)數(shù)據(jù)庫進(jìn)行操作。如果需要跨多個(gè)資源保證事務(wù)一致性

舉個(gè)例子：在ATM機(jī)取錢的時(shí)候，需要對(duì)用戶的賬戶進(jìn)行扣款處理，然后發(fā)送一條消息給消息服務(wù)器（假設(shè)消息服務(wù)器是用JMS實(shí)現(xiàn)的），由消息服務(wù)器異步通過短信通知用戶。如果用戶取款失敗，那么消息服務(wù)器不應(yīng)該發(fā)送短信給用戶。如何保證 用戶帳務(wù)扣款 和 消息服務(wù)器的消息保持一致性，也就是說 取款成功，消息服務(wù)器就持久化消息，然后發(fā)送短信給用戶，取款失敗，消息服務(wù)器就回滾消息，啥都不做。

在上面這種情況下，就需要使用分布式事務(wù)，也就是跨越多個(gè)資源的保證數(shù)據(jù)一致性。

X/Open DTP(X/OpenDistributed Transaction Processing Reference Model) 是X/Open 這個(gè)組織定義的一套分布式事務(wù)的標(biāo)準(zhǔn)，也就是了定義了規(guī)范和API接口，由這個(gè)廠商進(jìn)行具體的實(shí)現(xiàn)。這個(gè)思想在java 平臺(tái)里面到處都是。

X/Open DTP 定義了三個(gè)組件： AP，TM，RM

AP(Application Program)：也就是應(yīng)用程序，可以理解為使用DTP的程序

RM(Resource Manager)：資源管理器，這里可以理解為一個(gè)DBMS系統(tǒng)，或者消息服務(wù)器管理系統(tǒng)，應(yīng)用程序通過資源管理器對(duì)資源進(jìn)行控制。資源必須實(shí)現(xiàn)XA定義的接口

TM(Transaction Manager)：事務(wù)管理器，負(fù)責(zé)協(xié)調(diào)和管理事務(wù)，提供給AP應(yīng)用程序編程接口以及管理資源管理器

其中，AP 可以和TM 以及 RM 通信，TM 和 RM 互相之間可以通信，DTP模型里面定義了XA接口，TM 和 RM 通過XA接口進(jìn)行雙向通信，例如:TM通知RM提交事務(wù)或者回滾事務(wù)，RM把提交結(jié)果通知給TM。AP和RM之間則通過RM提供的Native API 進(jìn)行資源控制，這個(gè)沒有進(jìn)行約API和規(guī)范，各個(gè)廠商自己實(shí)現(xiàn)自己的資源控制，比如Oracle自己的數(shù)據(jù)庫驅(qū)動(dòng)程序。

下面一幅圖說明了三者的關(guān)系：

其中在DTP定了以下幾個(gè)概念：

事務(wù)：一個(gè)事務(wù)是一個(gè)完整的工作單元，由多個(gè)獨(dú)立的計(jì)算任務(wù)組成，這多個(gè)任務(wù)在邏輯上是原子的。

全局事務(wù)：對(duì)于一次性操作多個(gè)資源管理器的事務(wù)，就是全局事務(wù)

分支事務(wù)：在全局事務(wù)中，某一個(gè)資源管理器有自己獨(dú)立的任務(wù)，這些任務(wù)的集合作為這個(gè)資源管理器的分支任務(wù)

控制線程：用來表示一個(gè)工作線程，主要是關(guān)聯(lián)AP,TM,RM三者的一個(gè)線程，也就是事務(wù)上下文環(huán)境。簡(jiǎn)單的說，就是需要標(biāo)識(shí)一個(gè)全局事務(wù)以及分支事務(wù)的關(guān)系。

兩階段提交協(xié)議：如果一個(gè)事務(wù)管理器管理著多個(gè)資源管理器，如果控制全局事務(wù)和分支事務(wù)，在DTP里面說明兩階段提交的協(xié)議

第一階段：準(zhǔn)備階段

事務(wù)管理器通知資源管理器準(zhǔn)備分支事務(wù)，資源管理器告之事務(wù)管理器準(zhǔn)備結(jié)果

第二階段：提交階段

事務(wù)管理器通知資源管理器提交分支事務(wù)，資源管理器告之事務(wù)管理器結(jié)果

下面一幅圖演示了正常情況下的兩階段提交，

如果第一階段某一個(gè)資源預(yù)提交失敗，第二階段就回滾第一階段已經(jīng)預(yù)提交成功的資源

以上是比較正常的情況，但是由于RM有權(quán)利自己根據(jù)情況提交或者回滾自己的分支事務(wù)（官方說法是：Heuristic Decision）那三么就可能出現(xiàn)以下種情況：

1 在TM通知RM提交事務(wù)之前，RM分支事務(wù)已經(jīng)提交

2 在TM通知RM提交事務(wù)之前，RM分支事務(wù)全部回滾

3 在TM通知RM提交事務(wù)之前，RM分支事務(wù)部分回滾

對(duì)于Heuristic Decision標(biāo)記的分支事務(wù)，在沒有TM通知RM forget 它之前，RM都必須保存分支事務(wù)的信息，等到TM從失敗中恢復(fù)事務(wù)之后，通知RM forget 分支事務(wù)，這個(gè)時(shí)候RM才真正的完成事務(wù)。

對(duì)于前面兩種情況來說，TM會(huì)比較好處理，做事務(wù)恢復(fù)的時(shí)候，要么標(biāo)記全局事務(wù)成功，要么標(biāo)記全局事務(wù)回滾，通知RM可以完成分支事務(wù)了。對(duì)于第三種情況，可能就需要進(jìn)行決策了，這個(gè)具體怎么處理，貌似DTP并沒有說明細(xì)節(jié)，可以交給應(yīng)用自己去判斷。

DTP編程模型

雖然DTP內(nèi)部的實(shí)現(xiàn)比較復(fù)雜，但是對(duì)于DTP編程模型就比較簡(jiǎn)單了

1 AP通過TM獲取事務(wù)

2 AP申明需要哪些RM，TM注冊(cè)RM

3 AP使用RM完成分支事務(wù)

4 AP通過TM提交事務(wù)

5 TM通知RM提交事務(wù)

而DTP的服務(wù)的實(shí)現(xiàn)就需要考慮以下幾個(gè)問題：

如何獲取TM?

如何啟動(dòng)和結(jié)束一個(gè)事務(wù)

如何標(biāo)識(shí)一個(gè)事務(wù)

如何保存和傳遞事務(wù)上下文

應(yīng)用如何通過資源管理器操作共享資源

資源管理器如何實(shí)現(xiàn)準(zhǔn)備階段以及與提交階段的邏輯

如何實(shí)現(xiàn)兩階段提交協(xié)議

如何實(shí)現(xiàn)在異常情況下進(jìn)行事務(wù)恢復(fù)

其實(shí)如果把這幾個(gè)問題了解清楚了，就可以自己實(shí)現(xiàn)一個(gè)兩階段提交的分布式事務(wù)模型了。

總結(jié)

以上是生活随笔為你收集整理的分布式事务（两阶段提交）模型详解的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。