架構雜談《四》

分散式一致性協議

一、引言

　　在分散式系統中，為了保證數據的高可用，通常會將數據保留多個副本(replica)，這些個副本會放在不同的物理機上，為了對用戶提供正確的數據，我們需要保證這些放在不同物理機上的副本是一致的。為瞭解決這種分散式一致性問題，提出了很多經典的協議和演算法，比較著名的是 兩階段提交協議和三階段提交協議。

二、兩階段提交協議

　　兩階段提交協議把分散式事務分為兩個階段，一個是準備階段，一個是提交階段。準備階段和提交階段都是由事務管理器發起的，兩階段提交協議的流程如下：

　　1、準備階段：事務管理器向資源管理器發起指令，資源管理器評估自己的狀態，如果資源管理器評估指令可以完成。則會寫redo或者undo日誌，然後鎖定資源，執行操作，但是並不會提交

　　2、提交階段：如果每個資源管理器明確返回準備成功，事務管理器向資源管理器發起提交指令，資源管理器提交資源變更的事務，釋放鎖定的資源；如果任何一個資源管理明確返回準備失敗，則事務管理器向資源管理器發起中止指令，資源管理器取消已經變更的事務，執行undo日誌。釋放鎖定的資源。

（兩階段提交協議的成功場景圖）

　　我們從上圖中可以看到，兩階段提交協議在準備階段鎖定資源，這是一個重量級的操作，能保證強一致性，但是實現起來複雜、成本大、不夠靈活。還有以下缺點：

　　　  （1）、阻塞：對於任何一次指令都必須收到明確的響應，才會繼續進行下一步，否則處於阻塞狀態，占用的資源一直被鎖定，不會釋放

　　　  （2）、單點故障：如果事務管理器（協調者）掛了（宕機），資源管理器（參與者）沒有事務管理器（協調者）指揮，則會一直阻塞，儘管可以通過選舉新的協調者替代原有的協調者，但是參與者接收後也宕機，則新上任的協調者無法處理這種情況

　　　  （3）、腦裂：協調者發送提交指令，有的參與者接收到並執行了事務，有的參與者沒有接收到事務就沒有執行事務，多個參與者之間是不一致的。

　　上面的問題雖然很少發生，但每次發生都需要人工參與，沒有自動化解決方案，因此兩階段提交協議在正常情況下能保證系統的強一致性，但在出現異常的情況下，需要人工干預解決，因此可用性不夠好，其實這也符合CAP協議的一致性和可用性不能兼得的原理。

三、三階段提交協議

　　三階段提交協議是兩階段提交協議的改進版本，它通過超時機制解決了阻塞的問題，並且把兩個階段增加為三個階段。

　　1、詢問階段：事務管理器（協調者）詢問參與者（資源管理器）是否可以完成指令，參與者只需要回答是或者否，而不需要做真正的操作，這個階段超時會導致中止。

　　2、準備階段：如果在詢問階段所有參與者都返回可以執行操作，則協調者向參與者發送預執行請求，然後參與者寫 redo 和 undo 日誌，執行操作但不提交操作；如果在詢問階段任何一個參與者返回不能執行操作的結果，則協調者向參與者發送中止請求，這裡的邏輯和兩階段提交協議的準備階段是相似的。

　　3、提交階段：如果每個參與者在準備階段返回準備成功，則協調者向參與者發送提交指令，參與者提交資源變更的事務，釋放鎖定的資源；如果任何一個參與者返回準備失敗，則協調者向參與者發送中止指令，參與者自己取消已經變更的事務，執行 undo 日誌，釋放鎖定的資源。這裡的邏輯和兩階段提交協議的提交階段一致。

　（三階段提交協議的成功場景圖）

　　三階段提交協議與兩階段提交協議主要有以下不同點：

　　　　（1）、增加了一個詢問階段，詢問階段可以確保儘可能早地發現無法執行操作而需要中止的行為，但是它並不能發現所有的這種行為，只會減少這種情況的發生。

　　　　（2）、在準備階段以後，協調者和參與者執行的任務中都增加了超時，一旦超時，則協調者和參與者都會繼續提交事務，預設為成功。

　　三階段提交協議與兩階段提交協議相比，具有以上的優點，但是一旦發生超時，系統仍然會發生不一致，只不過這種情況很少見。好處是不會阻塞和永遠鎖定資源。　　

四、TCC

　　兩階段和三階段提交協議，在遇到極端情況時，系統會產生阻塞或者不一致的問題，需要人干預解決。兩階段及三階段方案中都包含多個參與者、多個階段實現一個事務。實現事務，性能也是一個很大的問題。因此在互聯網的高併發系統中，很少有使用兩階段提交和三階段提交協議的場景。

　　後來有人提出了TCC協議，TCC協議將一個任務分成 Try、Confirm、Cancel 三個步驟。正常的流程會先執行 Try，如果執行沒有問題，則再執行 Confirm，如果執行過程中出現了異常。則執行操作的逆操作 Cancel。從正常的流程上講。這還是一個兩階段提交協議，但在執行出現異常後有一定的自我修複能力，如果任何參與者出現了問題，則協調者通過執行操作的逆操作來 Cancel 之前的操作。達到最終一致性狀態。

　　可以看出，從時序上講，如果遇到機端情況，則TCC會有很多問題，如：如果在取消時一些參與者收到指令，而另一些參與者沒有收到指令，則整個系統任然是不一致的，對於這種複雜的情況，系統首先會通過補償的方式嘗試自我修複，如果系統無法修複。還是需要人工干預解決。

　　從 TCC 的邏輯上來看，它是簡化版的三階段提交協議，解決了兩階段提交協議的阻塞問題，但還是沒有解決極端情況下出現的問題（不一致和腦裂問題）。然而，TCC 通過自動化補償手段，將需要人工處理的不一致問題降到最低，也是一種很有用的解決方案。

（TCC 協議的使用場景）

說明：

　　1、參考書籍：《分散式服務架構：原理、設計與實戰》

　　2、如有不合適的地方請反饋。綜合後更改。