常見一致性協議（一）

這是Zookeeper學習總結 的系列文章。

在上一節的理論基礎部分也提到，一個分布式系統往往是在可用性與一致性之間平衡。大多都是在保證一致性的前提下，盡可能地提高系統的整體可用性。常見的有二階段提交（2PC）、三階段提交（3PC）、Paxos、Raft等算法，在本文將介紹他們中的一部分。

2PC

2PC即Two-Phase Commit，二階段提交。廣泛應用在數據庫領域，為了使得基於分布式架構的所有節點可以在進行事務處理時能夠保持原子性和一致性。絕大部分關系型數據庫，都是基於2PC完成分布式的事務處理。
顧名思義，2PC分為兩個階段處理，

階段一：提交事務請求

1. 事務詢問。協調者向所有參與者發送事務內容，詢問是否可以執行提交操作，並開始等待各參與者進行響應；
2. 執行事務。各參與者節點，執行事務操作，並將Undo和Redo操作計入本機事務日志；
3. 各參與者向協調者反饋事務問詢的響應。成功執行返回Yes，否則返回No。

階段二：執行事務提交

協調者在階段二決定是否最終執行事務提交操作。這一階段包含兩種情形：

執行事務提交
所有參與者reply Yes，那么執行事務提交。

1. 發送提交請求。協調者向所有參與者發送Commit請求；
2. 事務提交。參與者收到Commit請求后，會正式執行事務提交操作，並在完成提交操作之后，釋放在整個事務執行期間占用的資源；
3. 反饋事務提交結果。參與者在完成事務提交后，寫協調者發送Ack消息確認；
4. 完成事務。協調者在收到所有參與者的Ack后，完成事務。

中斷事務
事情總會出現意外，當存在某一參與者向協調者發送No響應，或者等待超時。協調者只要無法收到所有參與者的Yes響應，就會中斷事務。

1. 發送回滾請求。協調者向所有參與者發送Rollback請求；
2. 回滾。參與者收到請求后，利用本機Undo信息，執行Rollback操作。並在回滾結束后釋放該事務所占用的系統資源；
3. 反饋回滾結果。參與者在完成回滾操作后，向協調者發送Ack消息；
4. 中斷事務。協調者收到所有參與者的回滾Ack消息后，完成事務中斷。

2PC具有明顯的優缺點：
優點主要體現在實現原理簡單；
缺點比較多：

• 2PC的提交在執行過程中，所有參與事務操作的邏輯都處於阻塞狀態，也就是說，各個參與者都在等待其他參與者響應，無法進行其他操作；
• 協調者是個單點，一旦出現問題，其他參與者將無法釋放事務資源，也無法完成事務操作；
• 數據不一致。當執行事務提交過程中，如果協調者向所有參與者發送Commit請求后，發生局部網絡異常或者協調者在尚未發送完Commit請求，即出現崩潰，最終導致只有部分參與者收到、執行請求。於是整個系統將會出現數據不一致的情形；
• 保守。2PC沒有完善的容錯機制，當參與者出現故障時，協調者無法快速得知這一失敗，只能嚴格依賴超時設置來決定是否進一步的執行提交還是中斷事務。

3PC

針對2PC的缺點，研究者提出了3PC，即Three-Phase Commit。作為2PC的改進版，3PC將原有的兩階段過程，重新划分為CanCommit、PreCommit和do Commit三個階段。

階段一：CanCommit

1. 事務詢問。協調者向所有參與者發送包含事務內容的canCommit的請求，詢問是否可以執行事務提交，並等待應答；
2. 各參與者反饋事務詢問。正常情況下，如果參與者認為可以順利執行事務，則返回Yes，否則返回No。

階段二：

在本階段，協調者會根據上一階段的反饋情況來決定是否可以執行事務的PreCommit操作。有以下兩種可能：

執行事務預提交

1. 發送預提交請求。協調者向所有節點發出PreCommit請求，並進入prepared階段；
2. 事務預提交。參與者收到PreCommit請求后，會執行事務操作，並將Undo和Redo日志寫入本機事務日志；
3. 各參與者成功執行事務操作，同時將反饋以Ack響應形式發送給協調者，同事等待最終的Commit或Abort指令。

中斷事務
加入任意一個參與者向協調者發送No響應，或者等待超時，協調者在沒有得到所有參與者響應時，即可以中斷事務：

1. 發送中斷請求。 協調者向所有參與者發送Abort請求；
2. 中斷事務。無論是收到協調者的Abort請求，還是等待協調者請求過程中出現超時，參與者都會中斷事務；

階段三：doCommit

在這個階段，會真正的進行事務提交，同樣存在兩種可能。

執行提交

1. 發送提交請求。假如協調者收到了所有參與者的Ack響應，那么將從預提交轉換到提交狀態，並向所有參與者，發送doCommit請求；
2. 事務提交。參與者收到doCommit請求后，會正式執行事務提交操作，並在完成提交操作后釋放占用資源；
3. 反饋事務提交結果。參與者將在完成事務提交后，向協調者發送Ack消息；
4. 完成事務。協調者接收到所有參與者的Ack消息后，完成事務。

中斷事務
在該階段，假設正常狀態的協調者接收到任一個參與者發送的No響應，或在超時時間內，仍舊沒收到反饋消息，就會中斷事務：

1. 發送中斷請求。協調者向所有的參與者發送abort請求；
2. 事務回滾。參與者收到abort請求后，會利用階段二中的Undo消息執行事務回滾，並在完成回滾后釋放占用資源；
3. 反饋事務回滾結果。參與者在完成回滾后向協調者發送Ack消息；
4. 中端事務。協調者接收到所有參與者反饋的Ack消息后，完成事務中斷。

3PC的優缺點：
3PC有效降低了2PC帶來的參與者阻塞范圍，並且能夠在出現單點故障后繼續達成一致；
但3PC帶來了新的問題，在參與者收到preCommit消息后，如果網絡出現分區，協調者和參與者無法進行后續的通信，這種情況下，參與者在等待超時后，依舊會執行事務提交，這樣會導致數據的不一致。