一致性協議

  從這周開始深刻學習Zookeeper,主要是看PAXOS到ZOOKEEPER分佈式一致性理論與實踐以及Zookeeper3.5的源碼,在整個學習過程當中會整理一些學習筆記。html

  1.分佈式基本概念算法

  2.一致性協議數據庫

2PC

  2PC即兩階段提交,是計算機網絡尤爲是在數據庫領域內,爲了使基於分佈式系統架構下的全部節點在進行事務處理過程當中可以保持原子性和一致性而設計的一種算法。兩階段提交將事務處理過程分爲投票階段和執行階段兩個步驟,其核心是採用先嚐試後提交的處理方式。兩階段提交協議將事務的提交過程分紅兩個階段來進行處理,其執行流程以下:網絡

階段一:提交事務請求架構

  1. 事務詢問。協調者向全部的事務參與者發送事務內容,詢問是否能夠執行事務的提交操做,並等待個參與者的響應。
  2. 執行事務。各參與者執行事務操做,並將Undo和Redo信息記入事務日誌。
  3. 各參與者向協調者反饋事務響應。若是參與者成功執行了事務操做,反饋YES,表示事務能夠執行;若是參與者沒有成功執行事務,反饋NO,表示事務不能夠執行。

階段二:執行事務提交分佈式

  • 執行事務提交:協調者返回的都是YES。
  1. 發送提交請求:協調者向全部參與節點發出Commit請求
  2. 事務提交參與者收到Commit請求後,執行事務提交操做,並在完成後釋放佔用的資源;
  3. 反饋提交結果:參與者在完成事務提交以後,向協調者發送ACK消息。
  4. 完成事務:協調者收到全部ACK後,完成事務。

 

  • 中斷事務:在第一個階段任何一個參與者反饋了NO或者等待超時後然沒法收到響應,就中斷事務。
  1. 發送回滾請求。協調者向參與者發送RollBack請求
  2. 事務回滾。參與者接收到Rollback請求後,會利用Undo信息執行回滾操做,並釋放佔用的資源。
  3. 反饋事務回滾結果
  4. 中斷事務。協調者接收到全部參與者的Ack消息後,完成事務中斷。

 

優缺點

  優勢:原理簡單,實現方便。學習

  缺點計算機網絡

  1. 同步阻塞。在兩階段提交過程當中,全部參與者事務操做都處於阻塞狀態,各個參與者在等待其餘參與者響應。
  2. 單點問題。
  3. 數據不一致。

3PC

  3PC即三階段提交,其將二階段提交協議的「提交事務請求」的過程一分爲二,造成了CanCommit、PreCommit和DoCommit三個階段。設計

 

階段一:CanCommit日誌

  1. 事務詢問。協調者向全部參與者發送包含事務內容的canCommit請求,詢問是否能夠執行事務提交操做。
  2. 參與者向協調者反饋事務詢問的響應。若是能夠順利執行反饋YES,不然反饋NO響應。

階段二:PreCommit

         該階段協調者根據參與者的反饋決定是否能夠順利進行事務的PreCommit操做。

  • 執行事務預提交(全部參與者返回YES)
  1. 發送預提交請求。協調者向全部參與者發出preCommit請求,並進入Prepared階段。
  2. 事務預提交。參與者接收到preCommit請求後執行事務操做,並將Undo和Redo信息記錄到事務日誌中
  3. 各參與者向協調者反饋事務執行的響應。若是參與者成功提交了事務操做,返回ACK,同時等待最終指令:提交(Commit)或停止(abort)。
  • 中斷事務(任何一個參與者返回NO或者超時)
  1. 協調者發送中斷(abort)請求
  2. 參與者中斷事務。(協調者發送abort或者參與者等待超時)

階段三:doCommit

  • 執行提交
  1. 協調者從preCommit狀態轉換到「提交」狀態,並向全部的參與者發送doCommit請求。
  2. 參與者接收到doCommit請求後,執行事務提交
  3. 參與者向協調者發送ACK消息。
  4. 協調者接收到全部參與者的反饋ACK消息後,完成事務。
  • 中斷事務(參與者向協調者反饋NO或者等待超時)
  1. 協調者發送中斷請求
  2. 事務回滾。
  3. 反饋事務回滾結果。
  4. 中斷事務。

  須要注意的是,一旦進入階段三不論協調者出現問題仍是協調者與參與者網絡之間的故障,最終都會致使參與者沒法及時收到來自協調者大額doCommit或者Abort請求,針對這種異常狀況,參與者在等待超時後,繼續進行事務的提交。

  和二階段提交協議相比,三階段提交協議最大的優勢就是下降了參與者的阻塞返回,而且可以在出現單點故障後繼續達成一致。

相關文章
相關標籤/搜索