本文**：
分布式事務的一致性分為兩種，實時一致性和最終一致性，實時一致性要求的客戶可接受的時間內完成資料操作，最終一致性要求在較長的時間內保證資料一致即可。
實時一致性的解決方案有二階段提交協議、三階段提交協議和paxos演算法等。
1.2兩階段提交協議（2pc）
二階段提交(two-phasecommit)是指，在計算機網路以及資料庫領域內，為了使基於分布式系統架構下的所有節點在進行事務提交時保持一致性而設計的一種演算法(algorithm)。通常，二階段提交也被稱為是一種協議(protocol))。在分布式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。當乙個事務跨越多個節點時，為了保持事務的acid特性，需要引入乙個作為協調者的元件來統一掌控所有節點(稱作參與者)的操作結果並最終指示這些節點是否要把操作結果進行真正的提交(比如將更新後的資料寫入磁碟等等)。因此，二階段提交的演算法思路可以概括為：參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。
所謂的兩個階段是指：第一階段：準備階段(投票階段)和第二階段：提交階段（執行階段）。
1.2.1準備階段：
事務協調者(事務管理器)給每個參與者(資源管理器)傳送prepare訊息，每個參與者要麼直接返回失敗(如許可權驗證失敗)，要麼在本地執行事務，寫本地的redo和undo日誌，但不提交，到達一種「萬事俱備，只欠東風」的狀態。
可以進一步將準備階段分為以下三個步驟：
1）協調者節點向所有參與者節點詢問是否可以執行提交操作(vote)，並開始等待各參與者節點的響應。
2）參與者節點執行詢問發起為止的所有事務操作，並將undo資訊和redo資訊寫入日誌。（注意：若成功這裡其實每個參與者已經執行了事務操作）
3）各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功，則它返回乙個」同意」訊息；如果參與者節點的事務操作實際執行失敗，則它返回乙個」中止」訊息。
1.2.2提交階段
如果協調者收到了參與者的失敗訊息或者超時，直接給每個參與者傳送回滾(rollback)訊息；否則，傳送提交(commit)訊息；參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源。(注意:必須在最後階段釋放鎖資源)
接下來分兩種情況分別討論提交階段的過程。
當協調者節點從所有參與者節點獲得的相應訊息都為」同意」時:
1）協調者節點向所有參與者節點發出」正式提交(commit)」的請求。
2）參與者節點正式完成操作，並釋放在整個事務期間內占用的資源。
3）參與者節點向協調者節點傳送」完成」訊息。
4）協調者節點受到所有參與者節點反饋的」完成」訊息後，完成事務。
如果任一參與者節點在第一階段返回的響應訊息為」中止」，或者 協調者節點在第一階段的詢問超時之前無法獲取所有參與者節點的響應訊息時：
1）協調者節點向所有參與者節點發出」回滾操作(rollback)」的請求。
2）參與者節點利用之前寫入的undo資訊執行回滾，並釋放在整個事務期間內占用的資源。
3）參與者節點向協調者節點傳送」回滾完成」訊息。
4）協調者節點受到所有參與者節點反饋的」回滾完成」訊息後，取消事務。
不管最後結果如何，第二階段都會結束當前事務。
二階段提交看起來確實能夠提供原子性的操作，但是不幸的事，二階段提交還是有幾個缺點的：
1、同步阻塞問題。執行過程中，所有參與節點都是事務阻塞型的。當參與者占有公共資源時，其他第三方節點訪問公共資源不得不處於阻塞狀態。
2、單點故障。由於協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤其在第二階段，協調者發生故障，那麼所有的參與者還都處於鎖定事務資源的狀態中，而無法繼續完成事務操作。（如果是協調者掛掉，可以重新選舉乙個協調者，但是無法解決因為協調者宕機導致的參與者處於阻塞狀態的問題）
3、資料不一致。在二階段提交的階段二中，當協調者向參與者傳送commit請求之後，發生了區域性網路異常或者在傳送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之後就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。於是整個分布式系統便出現了資料部一致性的現象。
4、二階段無法解決的問題：協調者再發出commit訊息之後宕機，而唯一接收到這條訊息的參與者同時也宕機了。那麼即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。
由於二階段提交存在著諸如同步阻塞、單點問題、腦裂等缺陷，所以，研究者們在二階段提交的基礎上做了改進，提出了三階段提交。
1.2.3三階段提交協議
三階段提交（three-phasecommit），也叫三階段提交協議（three-phase commit protocol），是二階段提交（2pc）的改進版本。
與兩階段提交不同的是，三階段提交有兩個改動點。
1、引入超時機制。同時在協調者和參與者中都引入超時機制。
2、在第一階段和第二階段中插入乙個準備階段。保證了在最後提交階段之前各參與節點的狀態是一致的。
也就是說，除了引入超時機制之外，3pc把2pc的準備階段再次一分為二，這樣三階段提交就有cancommit、precommit、docommit三個階段。
分布式事務解決方案（二）
最終一致性方案之ebay模式 ebay在2008年公布了乙個關於base準則提到乙個分布式事務解決方案。ebay的方案其實是乙個最終一致性方案，它主要採用訊息佇列來輔助實現事務控制流程，方案的核心是將需要分布式處理的任務通過訊息佇列的方式來非同步執行，如果事務失敗，則可以發起人工重試的糾正流程。人工...
事務 分布式事務解決方案
事務acid特性 事務隔離級別 指的是讀和寫同時出現時出現的資料不一致問題。事務的一致性問題 存在問題問題描述 髒讀 dirty read 針對的是單條資料。即乙個更新操作a修改了某一條資料，但尚未提交該事務，此時另乙個讀操作b來查詢該條資料，讀到的是修改後的但尚未提交的資料。不可重複讀 unrep...
分布式事務解決方案
一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性，需要業務系統結合mq訊息中介軟體實現，在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 tcc補償性，分為三個階段tryi...