zookeeper
概念
分佈式協調服務
服務
統一名稱服務，主從協議，配置管理，狀態感知，分佈式鎖
兩個核心功能：
- 管理用戶提交的數據(狀態數據)
- 節點監聽
集羣機制
ZAB協議:ZooKeeper原子廣播協議
所有的事務請求必須由唯一的 Leader 服務來處理，Leader 服務將事務請求轉換爲事務 Proposal，並將該 Proposal 分發給集羣中所有的 Follower 服務。如果有半數的 Follower 服務進行了正確的反饋，那麼 Leader 就會再次向所有的 Follower 發出 Commit 消息，要求將前一個 Proposal 進行提交。
ZAB 協議兩種基本的模式
-
崩潰恢復:
當整個服務框架在啓動過程中，或者當 Leader 服務器出現異常時，ZAB 協議就會進入恢復模式，通過過半選舉機制產生新的 Leader，之後其他機器將從新的 Leader 上同步狀態，當有過半機器完成狀態同步後，就退出恢復模式，進入消息廣播模式。
-
消息廣播
ZAB 協議的消息廣播過程使用的是原子廣播協議。在整個消息的廣播過程中，Leader 服務器會每個事物請求生成對應的 Proposal，併爲其分配一個全局唯一的遞增的事務 ID(ZXID)，之後再對其進行廣播。具體過程如下：
Leader 服務會爲每一個 Follower 服務器分配一個單獨的隊列，然後將事務 Proposal 依次放入隊列中，並根據 FIFO(先進先出) 的策略進行消息發送。Follower 服務在接收到 Proposal 後，會將其以事務日誌的形式寫入本地磁盤中，並在寫入成功後反饋給 Leader 一個 Ack 響應。當 Leader 接收到超過半數 Follower 的 Ack 響應後，就會廣播一個 Commit 消息給所有的 Follower 以通知其進行事務提交，之後 Leader 自身也會完成對事務的提交。而每一個 Follower 則在接收到 Commit 消息後，完成事務的提交。
3. 爲什麼過半數就可以認爲成功
這樣整個集羣只要超過半數的機器正常，就可以繼續正常服務；此外可以認爲過半數的機器保存的數據就是正確的數據，因爲他們佔了大多數，也就是少數服從多數，數據錯誤的機器可以通過複製數據以及日誌進行恢復
集羣角色
- Leader ：爲客戶端提供寫服務，並維護集羣狀態，它是由集羣選舉所產生的
- Follower ：爲客戶端提供讀服務，向Leader轉發寫請求，並定期向 Leader 彙報自己的節點狀態。同時也參與寫操作“過半寫成功”的策略和 Leader 的選舉
- Observer ：爲客戶端提供讀寫服務，向Leader轉發寫請求，並定期向 Leader 彙報自己的節點狀態，但不參與寫操作“過半寫成功”的策略和 Leader 的選舉，因此 Observer 可以在不影響寫性能的情況下提升集羣的讀性能
常用服務
注意每次設置的監聽只能用一次，一次監聽結束後要再次設置
-
命名服務
在分佈式系統中,通過使用命名服務,客戶端應用能夠根據指定名字來獲取資源或服務的地址,提供者等信息。被命名的實體通常可以是集羣中的機器,提供的服務地址,遠程對象等等—這些我們都可以統稱他們爲名字(Name)。其中較爲常見的就是一些分佈式服務框架中的服務地址列表。通過調用Z提供的創建節點的AP,能夠很容易創建一個個名稱。
-
分佈式鎖
分佈式鎖這個主要得益於Zookeeper保證了數據的強一致性。鎖服務可分爲兩類：保持獨佔和控制時序．所謂保持獨佔,就是所有試圖來獲取這個鎖的客戶端,最終只有一個可以成功獲得這把鎖。通常的做法是把zk上的一個znode看作是一把鎖,通過crete創建的那個客戶端也即擁有了這把鎖．控制時序,就是所有試圖來獲取這個鎖的客戶蝠最終都是會被安排執行,只是有個全局時序了,做法和上面基本類似,只是這裏/distribte_lock已經預先存在,客戶端在它下面創建臨時有序節點（這個可以通過節點的屬性控制時序，CreatMode.EPHEMERAL_SEQUENTIAL），ZK父節點維持一份sequence，保證子節點創建時序性。
Curator
Apache Curator是Apache ZooKeeper的Java / JVM客戶端庫，它包含一個高級API框架和實用程序，使使用Apache ZooKeeper更加容易和可靠。它還包括常見用例和擴展的配方，例如服務發現和Java 8異步DSL。