【zookeeper】第2篇：一致性協議

2PC

什麼是2PC

2PC是Two-Phase Commit的縮寫，即二階提交協議。它是將事務的提交過程分紅兩個階段來處理的，分別是提交事務請求階段和執行事務提交階段；二階提交協議經常使用於保證分佈式系統的數據一致性。

提交事務請求階段

1. 事務提交詢問

協調者向參與者發送事務內容，並詢問是否可執行事務提交操做，等待參與者的應答結果。

2. 事務執行

參與者對詢問的事務內容進行操做，並將Undo和Redo的信息記錄到事務日誌中。

3. 各參與者給協調者反饋響應結果

反饋結果包括能夠執行事務或者不能夠執行事務。

二階提交的第一階段也能夠稱做「投票階段」，即各參與者投票代表是否要繼續執行事務提交操做。

執行事務提交階段

協調者根據參與者的反饋結果決定是否能夠進行事務提交操做，通常有如下兩種狀況：

1. 正常執行事務提交

• 發送事務提交請求
  協調者向參與者發送事務commit請求。
• 執行事務提交
  參與者接受到commit請求後，正式執行事務，並在事務執行完成以後釋放資源。
• 反饋事務提交執行結果
  參與者完成事務提交後，向協調者發送ack消息。
• 完成事務
  協調者接收到全部參與者的ack消息後事務完成。

2. 中斷事務

• 發送事務回滾請求
  協調者向全部參與者發出rollback請求。
• 執行事務回滾
  參與者接受到rollback請求後，利用第一階段記錄的Undo信息執行事務回滾操，而後釋放資源。
• 反饋事務回滾結果
  參與者向協調者發送ack信息。
• 事務中斷完成
  協調者收到全部ack消息後表示完成事務中斷。

2PC的優缺點

優勢

簡單易於理解，容易實現。

缺點

• 同步阻塞
  爲何說是同步阻塞呢？由於在執行過程各參與者在等待其餘參與者時，將沒法執行其餘操做。
• 協調者單點
  協調者在整個二階提交中起到了關鍵性做用，一旦協調者出現了問題，操做將沒法執行下去。
• 存在數據不一致的可能性
  在二階提交的第二階段中，即執行事務提交操做時，若是出現網絡異常或致使部分參與者接受到了commit請求，部分參與者沒有接收到commit請求，此時就會致使數據不一致。

3PC

什麼是3PC

3PC是Three-Phase Commit的縮寫，即三階提交，是對二階提交的改進。

canCommit階段

• 事務詢問
  協調者向參與者發送一個包含事務內容的請求，詢問是否能夠執行事務提交，並等待參與者響應。
• 各參與者向協調者反饋事務詢問結果
  參與者自身認爲能夠順利執行事務，則反饋yes，並進入預備狀態，不然反饋no。

preCommit階段

根據階段一種參與者的反饋結果來決定是否進行preCommit操做，通常有兩種可能：

執行事務預提交

協調者從參與者獲得的反饋結果都是yes，此時執行事務預提交。

• 協調者向全部參與者發送preCommit請求，並作好事務提交準備
• 事務預提交
  參與者受到preCommit請求，會執行事務預提交，並將Undo和Redo寫進日誌文件中。
• 參與者反饋執行結果
  若是全部參與者成功執行事務，那麼會給給協調者ack響應，同時等待協調者最終的提交(commit)和停止(abort)命令。

中斷事務

任何一個參與者反饋了no，或者等待超時，或者協調者沒法接受到參與者的結果，那麼都會執行事務中斷。

• 協調者向參與者發送abort請求
• 中斷事務

doCommit階段

該階段是事務真正的提交階段，會存在一下可能性問題：

執行提交

• 發提交請求

協調者接收到了全部參與者的ack響應，它將總「預提交」狀態轉化爲「提交」狀態，並向全部參與者發送doCommit請求。

• 參與者執行事務提交，事務提交完成後釋放事務佔用資源。
• 參與者反饋結果
• 完成事務

中斷事務

進入該階段，假如協調者處於正常工做狀態，而且有任意一個參與者反饋了no響應，或者等待超時，或者協調者沒法接受反饋結果，那麼就中斷事務

• 協調者向參與者發送abort請求
• 事務回滾
  參與者收到abort命令後，利用階段記錄的Redo信息來執行事務回滾，完成後是否資源。
• 反饋事務回滾結果
• 中斷事務

3PC的優缺點

存在的問題

• 協調者故障
• 協調者和參與者網絡故障

不管哪一種狀況出現，最終會致使參與者沒法及時接受到協調者的doCommit或者abort請求，針對這種狀況，參與在等待超時後會繼續執行相應的事務提交。

優勢

• 可以在單點故障後繼續達成一致

缺點

• 參與者接收到preCommit後，若是網絡出現分區，部分網絡沒法通訊，任然會出現數據不一致的可能