上篇上述了分佈式系統的一些經典理論，即在設計分佈式系統時候應該考慮的問題，那麼本篇主要講述分佈式系統中數據的一致性，即數據在不同節點中如何保證一致性的問題。
經典一致性協議，主要分爲以下三個：
- 二階段提交協議——2PC
- 三階段提交協議——3PC
- paxos算法
下面就這三個協議做具體的分析與總結。
1、二階段提交協議——2PC
分佈式系統中同樣有數據庫中的事務的概念，當不同的節點處理一個事物操作額時候，雖然本節點知道當前事務操作的成功與否，但是卻不知道其它節點是否成功失敗，如何同一個事務操作在本節點上成功，但是在其它節點上失敗了，那麼肯定會造成所謂的不一致現象。
二階段提交協議提出就是解決在分佈式事務操作上的一致性問題
2PC主要分爲兩個階段：提交事務階段、執行事務階段
分爲兩個角色：協調者和參與者
第一階段：提交事務階段
1.事務詢問：協調者向所有參與者發送事務內容，詢問是否可以執行事務提交操作，並開始等待參與者的響應。
2.執行事務：各參與者節點執行事務操作，將類似undo和redo的信息持久化到日誌中，注意，這裏進行了實際的事務操作過程
3.反饋事務：參與者成功執行了事務操作，則返回成功給協調者，否則則反饋失敗給協調者，無論是成功還是失敗都需要反饋。
第二階段：執行事務的提交
第二階段協調者將根據第一階段的反饋結果，決定事務最終是否提交或者中斷。
執行事務提交：第一階段所有參與者都回覆成功
1.協調者向所有參與者發送提交事務commit請求
2.參與者收到commit請求後，會正式提交事務操作，並完成之後釋放對應占用資源
3.反饋事務提交結果：提交成功後，返回ack確認信息
4.完成事務：協調者接受到所有參與者發送的ack消息後，完成事務。
中斷事務：其中任何一個參與者向協調者反饋了失敗消息，或者協調者等待超時了還無任何反饋消息，此時會執行中斷事務請求。
1.發送回滾請求：協調者會向所有的參與者發送Rollback請求
2.事務回滾：參與者接收到了回滾請求後，會利用第一階級持久化到入職的undo信息，執行回滾操作，回滾操作完成之後會釋放對應占用的資源
3.反饋回滾結果：參與者完成回滾之後，會向協調者發送ack確認信息。
4.協調者受到左右信息之後，完成事務的回滾中斷。
事務提交和事務回滾兩種操作的示意圖如下：
兩段式提交2PC的優缺點
優點：
原理簡單，實現方便
缺點：
1.同步阻塞
由於在協調者還未發送提交或者中斷請求時，所有參與者都處於阻塞狀態，因爲每個參與者反饋信息的延時是不一致的，因此存在短板效應，同步阻塞。
2.單點問題
很明顯，協調者自身是2PC裏面最重要的角色，其本身存在單點問題，一旦故障，無法繼續完成事務操作。
3.數據不一致
在2PC的第二階段，執行事務提交時，如果發生了網絡問題，導致只有部分參與者收到了提交請求，此時這部分的參與者會提交事務，沒有收到的參與者則會繼續等待事務是否提交，此時整個系統則會出現不一致。
4.太過保守
沒有容錯機制，一旦任何一個參與者或者網絡出現問題，都會導致整個事務的失敗，重試。這樣的效率太低下的了。
以上就是對兩段式提交2PC的總結，其它一致性協議後續進行。。。
參考：
《從paxos搭配zookeeper》