在上一篇文章中，我們已經瞭解了分佈式事務的定義，本文我們將瞭解常用的分佈式事務解決方案。關注我的公衆號「Java面典」，每天 10：24 和你一起了解更多 Java 相關知識點。
二階段提交
二階段提交(Two-phaseCommit)是指，在計算機網絡以及數據庫領域內，爲了使基於分佈式系統架構下的所有節點在進行事務提交時保持一致性而設計的一種算法(Algorithm)。通常，二階段提交也被稱爲是一種協議(Protocol))。
在分佈式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。當一個事務跨越多個節點時，爲了保持事務的 ACID 特性，需要引入一個作爲協調者的組件來統一掌控所有節點（稱作參與者）的操作結果，並最終指示這些節點是否要把操作結果進行真正的提交（比如將更新後的數據寫入磁盤等等）。
二階段提交的算法思路可以概括爲：參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。
實現
-
準備階段：事務協調者（事務管理器）給每個參與者（資源管理器)）發送 Prepare 消息，每個參與者要麼直接返回失敗（如權限驗證失敗），要麼在本地執行事務，寫本地的 redo 和 undo 日誌，但不提交。
-
提交階段：如果協調者收到了參與者的失敗消息或者超時，直接給每個參與者發送回滾(Rollback)消息；否則，發送提交(Commit)消息；參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源（注意:必須在最後階段釋放鎖資源）。
缺點
-
同步阻塞問題：執行過程中，所有參與節點都是事務阻塞型的；
-
單點故障：由於協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去；
-
數據不一致（腦裂問題）：在二階段提交的階段二中，當協調者向參與者發送 commit 請求之後，發生了局部網絡異常或者在發送 commit 請求過程中協調者發生了故障，導致只有一部分參與者接受到了 commit 請求。於是整個分佈式系統便出現了數據部一致性的現象(腦裂現象)；
-
二階段無法解決的問題（數據狀態不確定）：協調者再發出 commit 消息之後宕機，而唯一接收到這條消息的參與者同時也宕機了。那麼即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。
三階段提交
三階段提交（ Three-phase commit ） ， 也 叫 三 階 段 提 交 協 議 （ Three-phase commit protocol），是二階段提交（2PC）的改進版本。
與兩階段提交不同的是，三階段提交有兩個改動點：
-
引入超時機制。同時在協調者和參與者中都引入超時機制；
-
在第一階段和第二階段中插入一個準備階段。保證了在最後提交階段之前各參與節點的狀態是一致的。也就是說，除了引入超時機制之外，3PC 把 2PC 的準備階段再次一分爲二，這樣三階段提交就有 CanCommit、PreCommit、DoCommit 三個階段。
實現
-
CanCommit 階段：協調者向參與者發送 commit 請求，參與者如果可以提交就返回 Yes 響應，否則返回 No 響應；
-
PreCommit 階段：協調者根據參與者的反應情況來決定是否可以繼續進行，有以下兩種可能。假如協調者從所有的參與者獲得的反饋都是 Yes 響應，那麼就會執行事務的預執行假如有任何一個參與者向協調者發送了 No 響應，或者等待超時之後，協調者都沒有接到參與者的響應，那麼就執行事務的中斷；
-
DoCommit 階段：該階段進行真正的事務提交，主要包含：
1). 協調者發送提交請求；
2). 參與者提交事務；
3). 參與者響應反饋（ 事務提交完之後，向協調者發送 Ack 響應。）
4). 協調者確定完成事務。
柔性事務
在電商領域等互聯網場景下，傳統的事務在數據庫性能和處理能力上都暴露出了瓶頸。在分佈式領域基於 CAP 理論以及 BASE 理論，有人就提出了 柔性事務 的概念。CAP（一致性、可用性、分區容忍性）理論大家都理解很多次了，這裏不再敘述。說一下 BASE 理論，它是在 CAP 理論的基礎之上的延伸。包括 基本可用（Basically Available）、柔性狀態（Soft State）、最終一致性（Eventual Consistency）。通常所說的柔性事務分爲：兩階段型、補償型、異步確保型、最大努力通知型幾種。
兩階段型
就是分佈式事務兩階段提交，對應技術上的 XA、JTA/JTS。這是分佈式環境下事務處理的典型模式。
補償型
TCC 型事務（Try/Confirm/Cancel）可以歸爲補償型。
WS-BusinessActivity 提供了一種基於補償的 long-running 的事務處理模型。服務器 A 發起事務，服務器 B 參與事務，服務器 A 的事務如果執行順利，那麼事務 A 就先行提交，如果事務 B 也執行順利，則事務 B 也提交，整個事務就算完成。但是如果事務 B 執行失敗，事務 B 本身回滾，這時事務 A 已經被提交，所以需要執行一個補償操作，將已經提交的事務 A 執行的操作作反操作，恢復到未執行前事務 A 的狀態。這樣的 SAGA 事務模型，是犧牲了一定的隔離性和一致性的，但是提高了 long-running 事務的可用性。
異步確保型
通過將一系列同步的事務操作變爲基於消息執行的異步操作, 避免了分佈式事務中的同步
阻塞操作的影響。
最大努力通知型（多次嘗試）
這是分佈式事務中要求最低的一種, 也可以通過消息中間件實現, 與前面異步確保型操作不同的一點是, 在消息由 MQ Server 投遞到消費者之後, 允許在達到最大重試次數之後正常結束事務。