概述
大型業務系統有著使用者多、併發高的特點，而在這方面，集中式資料庫（單機資料庫）的效能很難支援，因此主流的網際網路公司往往採用分散式（架構）資料庫，物理上利用更多的低端裝置，邏輯上對大表水平拆分支撐業務的需要。
雖然分散式資料庫能解決效能難題，但事務一致性（Consistency）的問題，卻很難在分散式資料庫上得到解決。
資料一致性？一致性問題，“萬惡之源”是資料冗餘和分佈並通過網路互動+網路異常是常態。
1、資料一致性的情形
主庫、從庫和快取資料一致性，相同資料冗餘，關係資料庫，為保證關據庫的高可用和高效能，一般會採用主從（備）架構並引入快取。其中資料不一致性存在於資料冗餘的時間視窗內。常用的解決方案見資料庫之網際網路常用架構方案。
多副本資料之間的資料一致性，相同資料副本，大資料領域，一份資料會有多個副本並存儲到不同的節點上。客戶端可以訪問任何一個節點進行讀寫操作。常用的解決方案是基於Paxos、ZAB、Raft、Quorum、Gossip等的開源實現。
分散式服務之間的資料一致性，相關資料分佈，分散式服務，不同的服務操作不同的庫（表），而且庫（表）間要保持一致。常用的解決方案是分散式事務一致性解決方案。
2、資料一致性的概念
強一致性弱一致性最終一致性3、資料一致性的原理
ACIDCAPBASE4、資料一致性的協議
兩階段提交協議三階段提交協議TCC協議Paxos協議ZAB協議Raft協議Quorum協議Gossip協議分散式事務XA實現資料一致性所謂分散式服務，就是把之前通過本地介面互動的模組，拆分成單獨的應用獨立部署，並通過RPC和MQ互動。拿物流中的訂單和庫存舉例（新增一條訂單記錄，庫存就要-1），集中式架構中，要想保證訂單表和庫存表的一致性，只要一個本地事務（ACID）就能保證兩者的強一致性；而分散式架構中，訂單表由訂單服務操作，庫存表由庫存服務操作。要想保證訂單表和庫存表的一致性，那麼就必須保證訂單服務對訂單表的操作和庫存服務對庫存表的操作同時成功。之前的一個本地事務就變成了一個分散式事務。由於服務之間通過網路互動+網路異常是常態，就會產生服務間資料不一致的情況。這就涉及一個分散式事務一致性的問題。
如何來保證分散式事務的ACID，業界也有比較成熟的方案，一般是2段提交2PC協議或者改進版也就是3段提交3PC協議，下面來分別簡單介紹下。
2PC協議也成為2段提交，1prepare階段，2commit階段。
所謂的兩個階段是指：第一階段：準備階段(投票階段)和第二階段：提交階段（執行階段）。
準備階段事務協調者(事務管理器)給每個參與者(資源管理器)傳送Prepare訊息，每個參與者要麼直接返回失敗(如許可權驗證失敗)，要麼在本地執行事務，寫本地的redo和undo日誌，但不提交，到達一種“萬事俱備，只欠東風”的狀態。
可以進一步將準備階段分為以下三個步驟：
提交階段1）協調者節點向所有參與者節點詢問是否可以執行提交操作(vote)，並開始等待各參與者節點的響應。
2）參與者節點執行詢問發起為止的所有事務操作，並將Undo資訊和Redo資訊寫入日誌。（注意：若成功這裡其實每個參與者已經執行了事務操作）
3）各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功，則它返回一個”同意”訊息；如果參與者節點的事務操作實際執行失敗，則它返回一個"中止"訊息。
如果協調者收到了參與者的失敗訊息或者超時，直接給每個參與者傳送回滾(Rollback)訊息；否則，傳送提交(Commit)訊息；參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源。(注意:必須在最後階段釋放鎖資源)
當協調者節點從所有參與者節點獲得的相應訊息都為”同意”時:
1）協調者節點向所有參與者節點發出”正式提交(commit)”的請求。
2）參與者節點正式完成操作，並釋放在整個事務期間內佔用的資源。
3）參與者節點向協調者節點發送”完成”訊息。
4）協調者節點受到所有參與者節點反饋的”完成”訊息後，完成事務。
如果任一參與者節點在第一階段返回的響應訊息為”中止”，或者 協調者節點在第一階段的詢問超時之前無法獲取所有參與者節點的響應訊息時：
1）協調者節點向所有參與者節點發出”回滾操作(rollback)”的請求。
2）參與者節點利用之前寫入的Undo資訊執行回滾，並釋放在整個事務期間內佔用的資源。
3）參與者節點向協調者節點發送”回滾完成”訊息。
4）協調者節點受到所有參與者節點反饋的”回滾完成”訊息後，取消事務。
不管最後結果如何，第二階段都會結束當前事務。
二階段提交看起來確實能夠提供原子性的操作，但是不幸的事，二階段提交還是有幾個缺點的：
1、同步阻塞問題。執行過程中，所有參與節點都是事務阻塞型的。當參與者佔有公共資源時，其他第三方節點訪問公共資源不得不處於阻塞狀態。
2、單點故障。由於協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤其在第二階段，協調者發生故障，那麼所有的參與者還都處於鎖定事務資源的狀態中，而無法繼續完成事務操作。（如果是協調者掛掉，可以重新選舉一個協調者，但是無法解決因為協調者宕機導致的參與者處於阻塞狀態的問題）
3、資料不一致。在二階段提交的階段二中，當協調者向參與者傳送commit請求之後，發生了局部網路異常或者在傳送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之後就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。於是整個分散式系統便出現了資料部一致性的現象。
4、二階段無法解決的問題：協調者再發出commit訊息之後宕機，而唯一接收到這條訊息的參與者同時也宕機了。那麼即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。
由於二階段提交存在著諸如同步阻塞、單點問題、腦裂等缺陷，所以後來在二階段提交的基礎上做了改進，提出了三階段提交。
PC三階段提交（Three-phase commit），也叫三階段提交協議（Three-phase commit protocol），是二階段提交（2PC）的改進版本。
與兩階段提交不同的是，三階段提交有兩個改動點。
1、引入超時機制。同時在協調者和參與者中都引入超時機制。
2、在第一階段和第二階段中插入一個準備階段。保證了在最後提交階段之前各參與節點的狀態是一致的。
也就是說，除了引入超時機制之外，3PC把2PC的準備階段再次一分為二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段。
CanCommit階段3PC的CanCommit階段其實和2PC的準備階段很像。協調者向參與者傳送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。
PreCommit階段1.事務詢問 協調者向參與者傳送CanCommit請求。詢問是否可以執行事務提交操作。然後開始等待參與者的響應。
2.響應反饋 參與者接到CanCommit請求之後，正常情況下，如果其自身認為可以順利執行事務，則返回Yes響應，並進入預備狀態。否則反饋No
協調者根據參與者的反應情況來決定是否可以記性事務的PreCommit操作。根據響應情況，有以下兩種可能。
假如協調者從所有的參與者獲得的反饋都是Yes響應，那麼就會執行事務的預執行。
1.傳送預提交請求 協調者向參與者傳送PreCommit請求，並進入Prepared階段。
2.事務預提交 參與者接收到PreCommit請求後，會執行事務操作，並將undo和redo資訊記錄到事務日誌中。
3.響應反饋 如果參與者成功的執行了事務操作，則返回ACK響應，同時開始等待最終指令。
假如有任何一個參與者向協調者傳送了No響應，或者等待超時之後，協調者都沒有接到參與者的響應，那麼就執行事務的中斷。
doCommit階段1.傳送中斷請求 協調者向所有參與者傳送abort請求。
2.中斷事務 參與者收到來自協調者的abort請求之後（或超時之後，仍未收到協調者的請求），執行事務的中斷。
該階段進行真正的事務提交，也可以分為以下兩種情況。
執行提交
1.傳送提交請求 協調接收到參與者傳送的ACK響應，那麼他將從預提交狀態進入到提交狀態。並向所有參與者傳送doCommit請求。
2.事務提交 參與者接收到doCommit請求之後，執行正式的事務提交。並在完成事務提交之後釋放所有事務資源。
3.響應反饋 事務提交完之後，向協調者傳送Ack響應。
4.完成事務 協調者接收到所有參與者的ack響應之後，完成事務。
中斷事務 協調者沒有接收到參與者傳送的ACK響應（可能是接受者傳送的不是ACK響應，也可能響應超時），那麼就會執行中斷事務。
在doCommit階段，如果參與者無法及時接收到來自協調者的doCommit或者rebort請求時，會在等待超時之後，會繼續進行事務的提交。（其實這個應該是基於概率來決定的，當進入第三階段時，說明參與者在第二階段已經收到了PreCommit請求，那麼協調者產生PreCommit請求的前提條件是他在第二階段開始之前，收到所有參與者的CanCommit響應都是Yes。（一旦參與者收到了PreCommit，意味他知道大家其實都同意修改了）所以，一句話概括就是，當進入第三階段時，由於網路超時等原因，雖然參與者沒有收到commit或者abort響應，但是他有理由相信：成功提交的機率很大。 ）
相信看到這的朋友應該都知道什麼是2PC協議和3PC協議了，還不清楚的話建議自己畫下圖，對於理解還是很有幫助的，後面會分享更多devops和DBA方面的內容，感興趣的朋友可以關注下~