1 X/OpenDTP模型
X/Open是一個組織機構,定義了一套分佈式事務標準,定義了規範的API接口。DTP模型就是這套分佈式事務的架構模型，分爲AP，TM，RM三個組件，其含義如下：
AP(Application Program)：也就是應用程序，可以理解爲使用DTP的程序
RM(Resource Manager)：資源管理器，這裏可以理解爲一個DBMS系統，或者消息服務器管理系統，應用程序通過資源管理器對資源進行控制。資源必須實現XA定義的接口
TM(Transaction Manager)：事務管理器，負責協調和管理事務，提供給AP應用程序編程接口以及管理資源管理器
其中，AP 可以和TM 以及 RM 通信，TM 和 RM 互相之間可以通信，DTP模型裏面定義了XA接口，TM 和 RM 通過XA接口進行雙向通信，例如:TM通知RM提交事務或者回滾事務，RM把提交結果通知給TM。AP和RM之間則通過RM提供的Native API 進行資源控制，這個沒有進行約API和規範，各個廠商自己實現自己的資源控制，比如Oracle自己的數據庫驅動程序。
其中在DTP定了以下幾個概念：
事務：一個事務是一個完整的工作單元，由多個獨立的計算任務組成，這多個任務在邏輯上是原子的。
全局事務：對於一次性操作多個資源管理器的事務，就是全局事務
分支事務：在全局事務中，某一個資源管理器有自己獨立的任務，這些任務的集合作爲這個資源管理器的分支任務
控制線程：用來表示一個工作線程，主要是關聯AP,TM,RM三者的一個線程，也就是事務上下文環境。簡單的說，就是需要標識一個全局事務以及分支事務的關係。其中包含了兩個協議分別如下：
TX協議：應用或應用服務器與事務管理器的接口
XA協議：全局事務管理器與資源管理器的接口
簡單來說就是應用程序要發起一個分佈式事務通過TX協議與事務管理器進行交互，而與這個全局事務相關聯的分支事務是由對應的資源管理器來控制，事務管理器通過XA協議來控制各個資源管理器的協調運行，從而達到解決分佈式事務的目的。
2 兩階段提交(2PC)
基於上述DTP模型出現了許多的方案，其中比較出名就是兩階段提交，也稱爲2PC。它分爲兩個執行階段，如下：
（1）準備階段
事務協調者，向所有事務參與者發送事務內容，詢問是否可以提交事務，並等待參與者回覆。事務參與者收到事務內容，開始執行事務操作，將 undo 和 redo 信息記入事務日誌中（但此時並不提交事務）。如果參與者執行成功，給協調者回復yes,表示可以進行事務提交。如果執行失敗，給協調者回復no,表示不可提交。
（2）提交階段
如果協調者收到了參與者的失敗信息或超時信息，直接給所有參與者發送回滾（rollback）信息進行事務回滾，否則，發送提交（commit）信息。參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源。(注意：必須在最後階段釋放鎖資源) 接下來分兩種情況分別討論提交階段的過程。
原理圖如下：
3.兩階段提交的缺點
（1）同步阻塞 所有事務參與者在等待其它參與者響應的時候都處於同步阻塞狀態，無法進行其它操作。
（2）單點問題 協調者在 2PC 中起到非常大的作用，發生故障將會造成很大影響。特別是在階段二發生故障，所有參與者會一直等待狀態，無法完成其它操作。
（3）數據不一致 在階段二，如果協調者只發送了部分 Commit 消息，此時網絡發生異常，那麼只有部分參與者接收到 Commit 消息，也就是說只有部分參與者提交了事務，使得系統數據不一致。
（4）太過保守 任意一個節點失敗就會導致整個事務失敗，沒有完善的容錯機制。
參考鏈接：
https://www.cnblogs.com/aigongsi/archive/2012/10/11/2718313.html
https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html
https://www.cnblogs.com/monkeyblog/p/10449363.html
https://www.cnblogs.com/szlbm/p/5588543.html