3.一致性協議 2PC協議(ZooKeeper手記)

2PC和3PC來歷

在分佈式系統中，每一個機器節點都能明確知道，自己在進行的事務操作是否成功(可以理解爲單機操作)，但是卻無法直接獲取到其他分佈式節點的操作結果。因此，當一個事務操作需要跨越多個分佈式節點的時候，爲了保持事務處理的ACID特性，就需要引入一個稱爲“協調者”的組件來統一調度所有分佈式節點的執行邏輯，我們把他稱作“參與者”。基於這個思想，衍生了2PC和3PC的兩種協議。

1. 2PC（Two-Phase Commit）二階段提交

• 階段一：提交事務請求

  • 事務詢問。
    協調者向所有的參與者發送事務內容，詢問是否可以執行事務提交操作，並開始等待各參與者的響應。
  • 執行事務
    各參與者執行事務操作，並將undo和redo信息記入事務日誌中。
  • 各參與者向協調者反饋事務詢問的響應
    如果參與者成功執行了事務操作，那麼反饋給協調者Yes響應,反之反饋No響應。

• 階段二：執行事務提交 (階段一反饋的結果都是Yes)

  • 發送提交請求
    協調者向所有參與者節點發出Commit請求。
  • 事務提交
    參與者接收到Commit請求後，會正式執行事務提交操作。
  • 反饋事務提交結果
    參與者在完成事務提交之後，向協調者發送ACK消息。
  • 完成事務
    協調者接受到所有參與者反饋的ACK消息後，完成事務。

• 階段二：中斷事務 (階段一反饋的結果有No或者有超時情況)

  • 發送回滾請求
    協調者向所有參與者節點發出RollBack請求。
  • 事務回滾
    參與者接收到RollBack請求後，利用階段一中undo信息來執行事務回滾操作。
  • 反饋事務回滾結果
    參與者在完成事務回滾之後，向協調者發送ACK消息。
  • 中斷事務
    協調者接受到所有參與者反饋的ACK消息後，完成事務中斷。
• 優點
  原理簡單，實現方便。
• 缺點
  • 同步阻塞
  • 單點問題
  • 數據不一致
  • 太過保守