[從Paxos到ZooKeeper][分布式一致性原理與實踐]<二>一致性協議
阿新 • • 發佈:2017-08-13
邏輯 計算機 二階段提交 是否 組成 原子性 per 缺點 兩種
Overview
- 在<一>有介紹到,一個分布式系統的架構設計,往往會在系統的可用性和數據一致性之間進行反復的權衡,於是產生了一系列的一致性協議。
- 為解決分布式一致性問題,在長期的探索過程中,湧現了一大批經典的一致性協議和算法,其中最著名的就是二階段提交協議、三階段提交協議和Paxos算法了。
2PC與3PC
- 分布式系統中,每個機器節點雖然都能明確知道自己在進行事務操作過程中的結果是失敗or成功,但卻無法直接獲取到其他分布式節點的操作結果。
- 因此,當一個事務操作需要跨越多個分布式節點的時候,為了保持事務處理的ACID特性,就需要引入一個稱為“協調者(Coordinator)”的組件來統一調度所有分布式節點的執行邏輯。而被調度的分布式節點則被稱為“參與者(Participant)”。
- 協調者負責調度參與者的行為,並最終決定這些參與者是否要把事務真正進行提交。基於該思想,衍生出了二階段提膠片和三階段提交兩種協議。
2PC
- 2PC,即Two-Phase Commit。是計算機網絡尤其是數據庫領域內,為了使基於分布式系統架構下的所有節點在進行事務處理過程中能夠保持原子性和一致性設計的一種算法。
- 簡單來說,就是將一個事務的處理過程分為了投票和執行兩個階段。
協議說明
- 階段一:提交事務請求:
- 事務詢問:協調者向所有的參與者發送事務內容,詢問是否可以執行事務提交操作,並開始等待各參與者的響應;
- 執行事務:各參與者執行事務操作,並將Undo和Redo信息記入事務日誌;
- 各參與者向協調者反饋事務詢問的響應:
- 階段二:執行事務提交:
協調者根據各參與者的反饋情況來決定最終是否可以進行事務提交操作。
- 執行事務提交
- 發送提交請求:協調者向所有參與者節點發出Commit請求;
- 事務提交
- 反饋事務提交結果:參與者完成事務提交後,向協調者發送Ack
- 完成事務
- 中斷事務
- 發送回滾請求:協調者向所有參與者節點發出Rollback請求;
- 事務回滾:參與者利用其在階段一中記錄的Undo信息來執行回滾操作;
- 反饋事務回滾結果
- 中斷事務
- 執行事務提交
優缺點:
- 優點:原理簡單,實現方便
- 缺點:同步阻塞,單點問題,腦裂,太過保守。
- 同步阻塞:2PC最大的問題,會極大地限制分布式系統的性能。因為在2PC執行過程中,所有該事務操作的邏輯都處於阻塞狀態,也就是說,各個參與者在等待其他參與者響應的過程中將無法進行其他任何操作
- 單點問題:一旦協調者出現問題,整個2PC都無法運轉。更嚴重的是,如果協調者在phase2中出現問題的話,那麽其他參與者將會一直處於鎖定事務資源的狀態中,而無法繼續完成事務操作。
- 數據不一致:在phase2,如果協調者向所有的參與者發送Commit請求之後,發生了局部網絡異常或是協調者在尚未發送完Commit請求之前自身發生崩潰,最終導致只有部分參與者收到了Commit請求,那麽整個分布式系統就會出現數據不一致現象。
- 太過保守:當協調者無法獲取參與者的響應信息時,協調者只能依靠其自身的超時機制來判斷是否需要中斷事務,這樣的策略過於保守。換句話說,2PC提交協議沒有涉及較為完善的容錯機制,任意一個節點的失敗都會導致整個事務的失敗。
- 同步阻塞:2PC最大的問題,會極大地限制分布式系統的性能。因為在2PC執行過程中,所有該事務操作的邏輯都處於阻塞狀態,也就是說,各個參與者在等待其他參與者響應的過程中將無法進行其他任何操作
3PC
協議說明
- Three-Phase Commit是2PC的改進版。
- 3PC是有CanCommit、PreCommit和DoCommit三個階段組成的事務處理協議
[從Paxos到ZooKeeper][分布式一致性原理與實踐]<二>一致性協議