分佈式理論(三)—— 一致性協議之 2PC

分佈式理論(三)—— 一致性協議之 2PC

前言

爲了使系統儘量能夠達到 CAP,於是有了 BASE 協議,而 BASE 協議是在可用性和一致性之間做的取捨和妥協。

人們往往需要在系統的可用性和數據一致性之間反覆的權衡。於是呢,就產生我們標題中的一致性協議,而且還不止一個呢。

爲了解決分佈式問題,涌現了很多經典的算法和協議,最著名的就是二階段提交協議,三階段提交協議,Paxos 算法。

本文重點介紹二階段提交協議,簡稱 2PC。

1. 什麼是 2PC

在分佈式系統中,會有多個機器節點,因此需要一個 “協調者” ,而各個節點就是 “參與者”,協調者統一調度所有分佈式節點的執行邏輯,這些被調度的分佈式節點就是 “參與者”。

協調者最終決定這些參與者是否要把事務真正進行提交。正式基於這個思想,有了二階段提交和 三階段提交。

2PC ,不是 2 個 pc 機的意思,而是 Two-Phase Commit 。可以認爲是一種算法,也可以認爲是一種協議,主要目的就是爲了保證分佈式系統數據的一致性。

協議說明:顧名思義,二階段提交就是講事務的提交過程分成了兩個階段來進行處理。流程如下:

2. 2PC 階段一

1. 事務詢問

協調者向所有的參與者詢問,是否準備好了執行事務,並開始等待各參與者的響應。

2. 執行事務

各參與者節點執行事務操作,並將 Undo 和 Redo 信息記入事務日誌中

3. 各參與者向協調者反饋事務詢問的響應

如果參與者成功執行了事務操作,那麼就反饋給協調者 Yes 響應,表示事務可以執行;如果參與者沒有成功執行事務,就返回 No 給協調者,表示事務不可以執行。

從上面可以感覺到,這個一個 所謂的 “投票階段”,什麼意思呢?所有的節點都投票決定是否執行事務操作。

3. 2PC 階段二

在階段二中,會根據階段一的投票結果執行 2 種操作:執行事務提交,中斷事務。

執行事務提交步驟如下:

  1. 發送提交請求:協調者向所有參與者發出 commit 請求。
  2. 事務提交:參與者收到 commit 請求後,會正式執行事務提交操作,並在完成提交之後釋放整個事務執行期間佔用的事務資源。
  3. 反饋事務提交結果:參與者在完成事務提交之後,向協調者發送 Ack 信息。
  4. 協調者接收到所有參與者反饋的 Ack 信息後,完成事務。

中斷事務步驟如下:

  1. 發送回滾請求:協調者向所有參與者發出 Rollback 請求。
  2. 事務回滾:參與者接收到 Rollback 請求後,會利用其在階段一種記錄的 Undo 信息來執行事務回滾操作,並在完成回滾之後釋放在整個事務執行期間佔用的資源。
  3. 反饋事務回滾結果:參與者在完成事務回滾之後,想協調者發送 Ack 信息。
  4. 中斷事務:協調者接收到所有參與者反饋的 Ack 信息後,完成事務中斷。

從上面的邏輯可以看出,二階段提交就做了2個事情:投票,執行。

核心是對每個事務都採用先嚐試後提交的處理方式,因此也可以將二階段提交看成一個強一致性的算法。

整個事務的執行過程如圖(可能不是太直觀。。。。)

image.png

4. 優點缺點

優點:原理簡單,實現方便
缺點:同步阻塞,單點問題,數據不一致,過於保守

  1. 同步阻塞:

在二階段提交的過程中,所有的節點都在等待其他節點的響應,無法進行其他操作。這種同步阻塞極大的限制了分佈式系統的性能。

  1. 單點問題:

協調者在整個二階段提交過程中很重要,如果協調者在提交階段出現問題,那麼整個流程將無法運轉,更重要的是:其他參與者將會處於一直鎖定事務資源的狀態中,而無法繼續完成事務操作。

  1. 數據不一致:

假設當協調者向所有的參與者發送 commti 請求之後,發生了局部網絡異常或者是協調者在尚未發送完所有 commit 請求之前自身發生了崩潰,導致最終只有部分參與者收到了 commit 請求。這將導致嚴重的數據不一致問題。

  1. 過於保守:

如果在二階段提交的提交詢問階段中,參與者出現故障而導致協調者始終無法獲取到所有參與者的響應信息的化,這時協調者只能依靠其自身的超時機制來判斷是否需要中斷事務,顯然,這種策略過於保守。換句話說,二階段提交協議沒有設計較爲完善的容錯機制,任意一個節點是失敗都會導致整個事務的失敗

5. 總結

由於 Base 理論需要在一致性和可用性方面做出權衡,因此涌現了很多關於一致性的算法或者說協議,這些協議設計的目的,就是能讓分佈式系統能夠在可用性和一致性之間取得一個很好的平衡,能夠基本可用。 比如 2PC,two-phase commit,分爲兩個階段提交一個事務:投票,執行。通過協調者和各個參與者的配合,實現一致性協議。

當然,他也是有去缺點的,比如同步阻塞的時候性能較低,協調者的單點問題,網絡故障可能引起的數據不一致的問題,執行策略過於保守的問題等等。

這些問題,將在另一個算法 3PC 中解決。我們將在下一篇文章中詳細說明。

good luck!!!

作者:莫那魯道

 

出處: 博客園:http://www.cnblogs.com/stateis0/ 
            個人博客: thinkinjava.cn

 

本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須在文章頁面給出原文連接,否則保留追究法律責任的權利。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章