架構雜談《四》

架構雜談《四》

分佈式一致性協議

1、引言

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

2、兩階段提交協議

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

　　一、準備階段：事務管理器向資源管理器發起指令，資源管理器評估本身的狀態，若是資源管理器評估指令能夠完成。則會寫redo或者undo日誌，而後鎖定資源，執行操做，可是並不會提交

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

　　

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

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

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

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

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

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

3、三階段提交協議

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

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

　　二、準備階段：若是在詢問階段全部參與者都返回能夠執行操做，則協調者向參與者發送預執行請求，而後參與者寫 redo 和 undo 日誌，執行操做但不提交操做；若是在詢問階段任何一個參與者返回不能執行操做的結果，則協調者向參與者發送停止請求，這裏的邏輯和兩階段提交協議的準備階段是類似的。

　　三、提交階段：若是每一個參與者在準備階段返回準備成功，則協調者向參與者發送提交指令，參與者提交資源變動的事務，釋放鎖定的資源；若是任何一個參與者返回準備失敗，則協調者向參與者發送停止指令，參與者本身取消已經變動的事務，執行 undo 日誌，釋放鎖定的資源。這裏的邏輯和兩階段提交協議的提交階段一致。

　　　　

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

　　三階段提交協議與兩階段提交協議主要有如下不一樣點：

　　　　（1）、增長了一個詢問階段，詢問階段能夠確保儘量早地發現沒法執行操做而須要停止的行爲，可是它並不能發現全部的這種行爲，只會減小這種狀況的發生。

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

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

4、TCC

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

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

　　能夠看出，從時序上講，若是遇到機端狀況，則TCC會有不少問題，如：若是在取消時一些參與者收到指令，而另外一些參與者沒有收到指令，則整個系統任然是不一致的，對於這種複雜的狀況，系統首先會經過補償的方式嘗試自我修復，若是系統沒法修復。仍是須要人工干預解決。

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

                                  

（TCC 協議的使用場景）

說明：

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

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