zookeeper
一、zookeeper概述
ZooKeeper是一個分布式的，開放源碼的分布式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個為分布式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分布式同步、組服務等。
ZooKeeper的目標就是封裝好復雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。
ZooKeeper包含一個簡單的原語集，提供Java和C的接口。
二、CAP原則
CAP原則又稱CAP定理，指的是在一個分布式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。
一致性（C）：在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
可用性（A）：保證每個請求不管成功或者失敗都有響應。
分區容忍性（P）：系統中任意信息的丟失或失敗不會影響系統的繼續運作。
一致性：
分為強一致性、弱一致性和最終一致性；
1、強一致性：
當更新操作完成之后，任何多個后續進程或者線程的訪問都會**返回最新的更新過的值，直到這個數據被其他數據更新為止。
但是這種實現對性能影響較大，因為這意味着，只要上次的操作沒有處理完，就不能讓用戶讀取數據。
2、弱一致性：
系統並不保證進程或者線程的訪問都會返回最新更新過的值。系統在數據寫入成功之后，不承諾立即可以讀到最新寫入的值，也不會具體的承諾多久之后可以讀到。甚至不能保證可以訪問到。
3、最終一致性：
最終一致性也是弱一致性的一種，它無法保證數據更新后，所有后續的訪問都能看到最新數值，而是需要一個時間，在這個時間之后可以保證這一點（就是在一段時間后，節點間的數據會最終達到一致狀態），而在這個時間內，數據也許是不一致的，這個系統無法保證強一致性的時間片段被稱為「不一致窗口」。不一致窗口的時間長短取決於很多因素，比如備份數據的個數、網絡傳輸延遲速度、系統負載等。
可用性：
可用性指的是服務一直可用，而且是正常的相應時間。好的可用性主要是指系統能夠很好的為用戶服務，不出現用戶操作失敗或者訪問超時等用戶體驗不好的情況。
分區容錯性：
分布式系統在遇到網絡故障的時候，仍然能夠對外提供滿足一致性和可用性的服務，除非整個網絡環境都發生了故障
三、一致性協議
2PC：
它可以保證在分布式事務中，要么所有參與進程都提交事務，要么都取消事務，即實現 ACID 的原子性（A）。
在數據一致性中，它的含義是：要么所有副本（備份數據）同時修改某個數值，要么都不更改，以此來保證數據的強一致性。
2PC分為2個階段
1、表決階段：
1、事務詢問
Coordinator （協調者）向所有的參與者發送一個 vote request
2、執行事務
各個參與者節點執行事務操作,並講Undo和Redo信息記入事務日志中
3、各參與者向協調者反饋事務詢問的響應.
如果參與者成功執行了事務操作,那么就反饋給協調者vote_commit響應,表示事務可以執行,如果沒有參與者成功執行事務,那么就反饋給協調者vote_abort響應,表示事務不可以執行.
2、提交階段：
Coordinator 收到所有參與者的表決信息，如果所有參與者一致認為可以提交事務，那么 Coordinator 就會發送 GLOBAL_COMMIT 消息，否則發送 GLOBAL_ABORT 消息；對於參與者而言，如果收到 GLOBAL_COMMIT 消息，就會提交本地事務，否則就會取消本地事務。
2PC的問題
1、同步阻塞：2PC 有幾個過程（比如 Coordinator 等待所有參與者表決的過程中）都是同步阻塞的，所有參與該事務操作的邏輯都處於阻塞狀態，各個參與者在等待其他參與者響應的過程中，將無法進行其他任何操作。在實際的應用中，這個問題是通過超時判斷機制來解決的，但並不能完全解決同步阻塞問題；
2、Coordinator 單點問題：實際生產應用中，Coordinator 都會有相應的備選節點；
3、數據不一致：這個在前面已經講述過了，如果在第二階段，Coordinator 和參與者都出現掛掉的情況下，是有可能導致數據不一致的。
3PC：
三階段提交協議（Three-Phase Commit， 3PC）最關鍵要解決的就是 Coordinator 和參與者同時掛掉導致數據不一致的問題，所以 3PC 把在 2PC 中又添加一個階段，這樣三階段提交就有：CanCommit、PreCommit 和 DoCommit 三個階段。
CanCommit
1.事務詢問協調者向參與者發送CanCommit請求。詢問是否可以執行事務提交操作。然后開始等待參與者的響應。
2.響應反饋參與者接到CanCommit請求之后，正常情況下，如果其自身認為可以順利執行事務，則返回Yes響應，並進入預備狀態。否則反饋No
PreCommit
執行事務預提交：如果 Coordinator 接收到各參與者反饋都是Yes，那么執行事務預提交：
發送預提交請求：Coordinator 向各參與者發送 preCommit 請求，並進入 prepared 階段；
事務預提交：參與者接收到 preCommit 請求后，會執行事務操作，並將 Undo 和 Redo 信息記錄到事務日記中；
各參與者向 Coordinator 反饋事務執行的響應：如果各參與者都成功執行了事務操作，那么反饋給協調者 ACK 響應，同時等待最終指令，提交 commit 或者終止 abort，結束流程；
中斷事務：如果任何一個參與者向 Coordinator 反饋了 No 響應，或者在等待超時后，Coordinator 無法接收到所有參與者的反饋，那么就會中斷事務。
發送中斷請求：Coordinator 向所有參與者發送 abort 請求；
中斷事務：無論是收到來自 Coordinator 的 abort 請求，還是等待超時，參與者都中斷事務
doCommit
執行提交
發送提交請求：假設 Coordinator 正常工作，接收到了所有參與者的 ack 響應，那么它將從預提交階段進入提交狀態，並向所有參與者發送 doCommit 請求；
事務提交：參與者收到 doCommit 請求后，正式提交事務，並在完成事務提交后釋放占用的資源；
反饋事務提交結果：參與者完成事務提交后，向 Coordinator 發送 ACK 信息；
完成事務：Coordinator 接收到所有參與者 ack 信息，完成事務。
在doCommit階段，如果參與者無法及時接收到來自協調者的doCommit或者rebort請求時，會在等待超時之后，會繼續進行事務的提交。（其實這個應該是基於概率來決定的，當進入第三階段時，說明參與者在第二階段已經收到了PreCommit請求，那么協調者產生PreCommit請求的前提條件是他在第二階段開始之前，收到所有參與者的CanCommit響應都是Yes。（一旦參與者收到了PreCommit，意味他知道大家其實都同意修改了）所以，一句話概括就是，當進入第三階段時，由於網絡超時等原因，雖然參與者沒有收到commit或者abort響應，但是他有理由相信：成功提交的幾率很大。 ）
中斷事務：
假設 Coordinator 正常工作，並且有任一參與者反饋 No，或者在等待超時后無法接收所有參與者的反饋，都會中斷事務。
發送中斷請求：Coordinator 向所有參與者節點發送 abort 請求；
事務回滾：參與者接收到 abort 請求后，利用 undo 日志執行事務回滾，並在完成事務回滾后釋放占用的資源；
反饋事務回滾結果：參與者在完成事務回滾之后，向 Coordinator 發送 ack 信息；
中斷事務：Coordinator 接收到所有參與者反饋的 ack 信息后，中斷事務。
3PC 分析
3PC 雖然解決了 Coordinator 與參與者都異常情況下導致數據不一致的問題，3PC 依然帶來其他問題：比如，網絡分區問題，在 preCommit 消息發送后突然兩個機房斷開，這時候 Coordinator 所在機房會 abort, 另外剩余參與者的機房則會 commit。
而且由於3PC 的設計過於復雜，在解決2PC 問題的同時也引入了新的問題，所以在實際上應用不是很廣泛。
2PC與3PC的區別
相對於2PC，3PC主要解決的單點故障問題，並減少阻塞，因為一旦參與者無法及時收到來自協調者的信息之后，他會默認執行commit。而不會一直持有事務資源並處於阻塞狀態。但是這種機制也會導致數據一致性問題，因為，由於網絡原因，協調者發送的abort響應沒有及時被參與者接收到，那么參與者在等待超時之后執行了commit操作。這樣就和其他接到abort命令並執行回滾的參與者之間存在數據不一致的情況。
參考資料
https://baijiahao.baidu.com/s?id=1650890231453975345&wfr=spider&for=pc
https://blog.csdn.net/demon7552003/article/details/86657767
本文內容屬於個人學習記錄使用，文中引用了其他博客內容。