兩階段提交協議

集中式與分布式事務的乙個重要的不同點在於它們各自所需關注的錯誤的屬性上。在集中式系統中，錯誤都是要麼不錯要麼全錯(all-or-nothing)，也就是說要麼系統正常工作事務正常處理，要麼系統出錯不會有任何事務完成。但是在分布式系統中，可能出現部分失敗(partial failures)的情況，某些節點正常工作但是其他一些節點出錯了。

這種區域性失敗的情況正是造成分布式系統中很多難解的問題的根源。在事務處理中就有這樣的乙個難解問題，即分布式事務的一致性問題。比如t就可能在某些節點上進行了commit，而在某些節點上進行了abort，這樣就產生了不一致。

兩階段提交(two-phase commit/2pc)就是為了使基於分布式系統架構下的所有節點在進行事務提交時保持一致性而設計的一種演算法(algorithm)。

在分布式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。所以當乙個事務跨越多個節點時，需要引入乙個作為協調者的元件來統一掌控所有節點(稱作參與者)的操作結果並最終指示這些節點是否要把操作結果進行真正的提交(比如將更新後的資料寫入磁碟等等)。

因此，兩階段提交的演算法思路可以概括為：參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。

2pc的兩個階段是指投票階段和決定階段：

第一階段(提交請求階段/投票階段)

協調者節點向所有參與者節點詢問是否可以執行提交操作，並開始等待各參與者節點的響應。

參與者節點執行詢問發起為止的所有事務操作，並將undo資訊和redo資訊寫入日誌。

各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功，則它返回乙個」同意」訊息；如果參與者節點的事務操作實際執行失敗，則它返回乙個」中止」訊息。

簡單地說，就是各參與者投票是否要繼續接下來的提交操作。

第二階段(提交執行階段/決定階段)：

1）成功

當協調者節點從所有參與者節點獲得的相應訊息都為」同意」時：

協調者節點向所有參與者節點發出」正式提交」的請求。

參與者節點正式完成操作，並釋放在整個事務期間內占用的資源。

參與者節點向協調者節點傳送」完成」訊息。

協調者節點受到所有參與者節點反饋的」完成」訊息後，完成事務。

2）失敗

如果任一參與者節點在第一階段返回的響應訊息為」終止」，或者協調者節點在第一階段的詢問超時之前無法獲取所有參與者節點的響應訊息時：

協調者節點向所有參與者節點發出」回滾操作」的請求。

參與者節點利用之前寫入的undo資訊執行回滾，並釋放在整個事務期間內占用的資源。

參與者節點向協調者節點傳送」回滾完成」訊息。

協調者節點受到所有參與者節點反饋的」回滾完成」訊息後，取消事務。

請注意，在失敗情況下有一種情況為超時，因為訊息可能會由於故障而無法到達。因此，程序可能會無限等待下去。為避免這個問題，需要使用超時機制。

還是來舉個現實生活中的例子吧：

你是個大吃貨，發現了聚餐的好地方，想叫上好**們去嘗鮮。於是，你給他們**簡訊：「各位親，我發了個好地兒，現在出來聚聚吧，位址是******」，收到資訊的小夥伴們，就尋路過去了，邊走邊記回去的路（寫日誌），到了的發簡訊給你「我到啦」，還有找了半天沒找地的小夥伴發簡訊給你「我沒找到地，就不去啦」（投票階段）

你如果收到所有小夥伴到了的資訊，又發資訊給他們「我訂了紫蘭廳，你們去吧」，小夥伴們把車停好（釋放資源），來到紫蘭廳，又給你發資訊「我來啦」，你看大家到齊了，乖乖點菜去了。

如果，你收到了有人不能來的簡訊，或者有人乙個小時都沒回簡訊（關機或者電信故障什麼的），你決定取消這次聚餐，發簡訊給大家說「小夥伴們，有人不能來啦，你們回去吧」。於是，大家順著記的路回家了（回滾），回到家後，把車停好（釋放資源），發簡訊給你「我到啦」，你收到大家的簡訊，恩，你可以睡覺去了。

總結：

2pc是分布式情況下強一致性演算法

協調者發生故障。協調者需要將事務相關資訊記錄到操作日誌並同步到備用協調者，假如協調者發生故障，備用協調者可以接替它完成後續的工作。如果沒有備用協調者，協調者又發生了永久性故障，事務參與者將無法完成事務而一直等待下去。

該演算法吞吐量較低，兩階段提交協議是阻塞協議，執行過程中需要鎖住其他更新，且不能容錯，大多數分布式儲存系統都採用敬而遠之的做法，放棄對分布式事務的支援。

兩階段提交協議

兩階段提交協議

兩階段提交協議

兩階段提交協議

相關推薦