分布式一致性協議

• 二階段提交協議（2pc）
• 三階段提交協議（3pc）
• paxos
• zab

在分布式系統中，每個機器都可以確定自己進行的事務操作是否成功，但是無法直接了解其他機器的操作結果。因此，當一個分布式事務操作需要保持ACID 特性時，就需要一個“協調者”節點調度其他“參與者”節點來進行分布式事務操作。

二階段提交（2pc）

提交事務請求 -> 執行事務提交；缺點：同步阻塞（參與者之間阻塞）、單點問題，腦裂（導致數據不一致問題）；主要用于關系型數據庫中，解決了分布式事務的原子性問題；

1. 提交事務請求

協調者向參與者發送事務，并詢問是否可以執行事務提交操作，等待參與者響應；

參與者執行事務，將操作寫入本地事務日志，向協調者發送反饋；

2. 執行事務提交

參與者反饋，全部ACK

協調者向參與者發送Commit；

參與者執行事務提交，釋放事務資源，反饋ACK，；

協調者收到反饋完成事務

參與者反饋，存在NO；協調者等待超時

協調者向參與者發送RollBack；

參與者利用undo，進行事務回滾；

參與者事務回滾之后，向協調者發送ACK 反饋；

協調者接收到ACK，完成事務中斷；

三階段提交（3pc）

cancommit -> precommit -> docommit；優缺點：降低了參與者同步阻塞范圍，但是又引入了數據不一致性問題（若出現網絡分區）、單點問題依然存在；

1. CanCommit

協調者向參與者發送cancommit 請求（包含事務內容），等待參與者反饋；

參與者接收到cancommit 請求之后，反饋ACK或者NO；

2. PreCommit

參與者反饋，全部ACK

協調者向參與者發送precommit 請求，等待反饋；

參與者執行事務，將操作寫入本地事務日志，向協調者發送反饋；

參與者反饋，存在NO；協調者等待超時

協調者向參與者發送abort 請求；

參與者無論是接收到abort 請求還是等待超時都會中斷事務；

3. DoCommit

參與者反饋，全部ACK

協調者向參與者發送docommit 請求，等待反饋；

參與者執行事務提交，釋放事務資源，反饋ACK，；

協調者接收反饋，完成事務提交；

參與者反饋，存在NO；協調者等待超時

協調者向參與者發送abort 請求；

參與者進行事務回滾；

參與者反饋ACK；

協調者接收到ACK，完成事務中斷；

paxos 算法

• paxos 基于消息傳遞并具有高度容錯性；
• paxos 算法的核心是，分布式系統如何就某個狀態（提案）達成一致；
• paxos 算法假設不存在“拜占庭將軍問題”；
• paxos 算法中的角色：proposer、acceptor、learner；
  • proposer：發送提案；
  • acceptor：裁決提案；只能批準一個提案；過半批準原則；
  • learner：學習提案；　

1. prepare 階段（生成提案）

• proposer 提出編號為Mn 的提案，向acceptor 集合發送prepare 請求；
• acceptor 反饋；
  • 保證不再接收編號小于Mn 的提案；
  • 返回已經批準的，編號最大的提案的Value；
  • 若Mn 小于已經批準的最大編號，則忽略Mn；（優化）　　
• proposer 收到過半響應，則發送accept 請求（Mn，Vn）給acceptor 集合；Vn 是接收回的最大編號提案的Value；若無Value 可選（acceptor 都未接收提案），Vn 可為任意值；

2. accept 階段（批準提案）

acceptor 接收到accept 請求之后，只要Mn 不小于已接受提案最大的編號，則批準提案；

learner 獲取提案（學習策略）

一旦提案被批準（過半），則發送給所有learner；

提案批準，則發送給一個learner，該learner再發送給其他learner；

提案批準，則發送給一個learner集合，該learner集合再發送給其他learner；

優化

問題：proposer1 與 proposer2 兩者陷入死循環；

解決：選出主proposer，只要主proposer 和 過半acceptor 能保持正常，那么但凡主proposer 能提出一個編號更高的提案，這個提案最終將會批準；

應用

chubby：分布式鎖、GFS 中 master 選舉

ZAB 協議

ZAB 協議

ZAB 協議是為分布式協調服務（Zookeeper）專門設計的一種支持故障恢復的原子廣播協議。

消息廣播：

只允許有一個主進程（leader）接收事務請求并處理。

當leader 接收到請求之后，將事務請求轉化為事務提議（proposal） 并將該proposal 分別入隊 （leader 會為每個follower 分別創建一個響應隊列用來保證事務提交的順序）。

每個事務proposal 有一個遞增的全局唯一的ID，事務ID（ZXID）

leader 通過響應隊列將proposal 分發到其他節點之后，等待反饋；follower 接收到proposal 之后寫入本地日志，返回 ack；

leader 收到一半以上follower 的反饋之后，會向其他節點 發送commit，同時提交事務。

故障恢復：

保證已經在leader 機器上提交的事務最終被所有機器提交

丟棄只在leader 機器上被提出的事務

為保證以上兩點：

• Leader選舉：選擇ZXID 最大的節點作為Leader。
• 數據同步：leader 為每個follower 創建一個隊列，將沒有被各個follower 提交的事務 proposal填入各個隊列，并分發給follower。follower 事務同步以后，leader會將它加入到真正可用follower 列表中。

ZAB協議中兩種模式：

消息廣播和故障恢復。

當系統啟動或者leader 機器出現故障現象時，進入故障恢復模式并進行leader選舉。選舉產生的leader 會與過半的follower 進行數據同步。同步結束，退出故障恢復模式，進入消息廣播模式；任意一臺遵從ZAB協議的機器啟動后，如果檢測到leader 廣播，都會自動進入故障恢復模式與leader 進行數據同步，同步之后，進入消息廣播模式；非leader 接收到客戶端事務請求時，會轉發給leader 處理；

Leader 重新選舉條件：

leader 宕機或故障

與leader 保持連接的機器少于一半

Zookeeper

• zookeeper 為分布式應用提供了一個高效可靠的分布式協調服務；
• 實現依賴于ZAB 協議，實現了一種主備模式的架構來保持集群的數據一致性；
• zookeeper 可以幫助分布式應用以一個共享的樹形的命名空間實現協調；
• zookeeper 將數據全部存儲在內存中并且集群中任意一臺機器都可以響應客戶端讀操作，因此它更適合用以讀操作為主的場景；
• zookeeper 集群節點有三種角色：leader、follower、observer。
  • leader：通過選舉產生的集群領導者；提供讀寫服務；
  • follower：提供讀服務；參與leader 選舉和寫操作“過半寫成功”策略；
  • observer：提供讀服務；不影響集群寫性能的前提下提升集群的讀性能；
• zookeeper 集群節點總數為奇數；
• zookeeper 數據節點類型：持久節點（只能采用刪除操作清除該節點）、臨時節點（其生命周期取決于session 是否失效）、順序節點（子節點順序表，節點名有數字后綴） ；
• zookeeper 每個節點都有 Stat 結構（數據節點的所有狀態信息）
• 最重要的功能：watcher；
• 開源客戶端：zkclient、curator；?

總結

以上是生活随笔為你收集整理的简述分布式一致性协议（2pc、3pc、paxos、zab）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。