分布式事務處理

分布式事務處理（  Distributed Transaction Processing  ，  DTP  ）涉及多個分布在不同地方的資料庫，但對資料庫的操作必須全部被送出或者復原。隻要任一資料庫操作時失敗，所有參與事務的資料庫都需要復原。

Open  組織定義的分布式事務處理模型X/Open DTP  模型（1994）包括應用程式（  AP  ）、事務管理器（  TM  ）、資料總管（  RM ，即資料庫 ）、通信資料總管（  CRM  ）四部分。而 XA 是 X/Open DTP 定義的事務管理器與資料庫之間的接口規範（即接口函數），事務管理器用它來通知資料庫事務的開始、結束以及送出、復原等。

 XA  接口規範使用兩階段送出協定來完成一個全局事務，保證同一事務中所有資料庫同時成功或者復原。

兩階段送出協定假設每個資料庫點都存在一個write-ahead log，每一次的write請求都是先記log後才真正執行寫入。

第一階段為送出請求階段（Commit-request phase）：

   1. 事務管理器給所有資料庫發query to commit消息請求，然後開始等待回應；

   2. 資料庫如果可以送出屬于自己的事務分支，則将自己在該事務分支中所做的操作固定記錄下來（在undo log和redo log中各記一項）；

   3. 資料庫都回應是否同意送出的應答。

第二階段為送出階段（Commit phase）：

如果事務管理器收到的所有回應都是agreement，

   1. 事務管理器記日志并給所有資料庫發commit消息請求；

   2. 各個資料庫執行操作，釋放所有該事務相關的鎖和資源；

   3. 各個資料庫給事務管理器回複；

   4.當收到所有回複，事務管理器結束目前事務

如果事務管理器收到的任一回應是abort，

   1. 事務管理器記日志并給所有資料庫發rollback消息請求；

   2. 各個資料庫執行undo操作，釋放所有該事務相關的鎖和資源；

   3. 各個資料庫給事務管理器回複；

   4.當收到所有回複，事務管理器結束目前事務

兩階段送出協定的問題在于資料庫在送出請求階段應答後對很多資源處于鎖定狀态，要等到事務管理器收集齊所有資料庫的應答後，才能發commit或者rollback消息結束這種鎖定。鎖定時間的長度是由最慢的一個資料庫制約，如果資料庫一直沒有應答，所有其他庫也需要無休止的鎖并等待。并且，如果事務管理器出現故障，被鎖定的資源将長時間處于鎖定狀态。無論是任一資料庫或者事務管理器故障，其他資料庫都需要永久鎖定或者至少長時間鎖定。并且，分布式系統中節點越多，存在緩慢網絡或者故障節點的機率也就越大，資源被長時間鎖定的機率指數上升。

兩階段送出協定的另一個問題是隻要有任意一個資料庫不可用都會導緻事務失敗，這導緻事務更傾向于失敗。對于多個副本的備份系統，很多時候我們希望部分副本點失效時系統仍然可用，使用該協定則不能實作。并且，分布式系統中節點越多，存在故障節點的機率也就越大，系統的可用性指數下降。

另外，如果資料庫在第一階段應答後到第二階段正式送出前的某個階段網絡故障或者節點故障，該協定無法送出或復原，資料不一緻不能絕對避免。