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消息后，完成事務中斷。
• 優點
  原理簡單，實現方便。
• 缺點
  • 同步阻塞
  • 單點問題
  • 數據不一致
  • 太過保守