Zookeeper
Zookeeper簡述
Zookeeper是一個分佈式服務框架，是Apache Hadoop 的一個子項目，它提供的是分佈式協調服務。用來解決分佈式應用中經常遇到的一些數據管理問題，比如統一命名服務、協調鎖資源、狀態同步服務、集羣管理、分佈式應用配置項的管理等。而Zookeeper實現這些功能的支撐其實是它類似於文件系統的數據模型和監聽機制。
監聽機制
客戶端可以通過在它關心的目錄節點上註冊監聽事件監聽器(Watcher)，當目錄節點發生相應的事件（數據改變、節點被刪除、子目錄節點增加刪除）時，zookeeper會通知客戶端並且進行信息同步。
zookeeper的常用操作如下:create–創建節點；delete–刪除節點；exists–判斷節點是否存在；getData–獲得一個節點的數據；setData–設置一個節點的數據；getChildren–獲取節點下的所有子節點。當客戶端進行create、delete、setData等操作時可以通過設置watch參數進行watcher註冊。
數據模型
Zookeeper的數據模型類似於文件系統，由一層層的目錄組成，而每一個目錄其實都是一個存儲信息的節點，存儲着狀態/配置信息，Zookeeper的節點有着自己的獨特名稱—Znode，Znode除了存儲信息還存儲了子目錄(節點)的指針，因此Znode的訪問方式也與文件系統相同，採用的是路徑引用，例如上圖中我要訪問SunAPP1這個節點則訪問路徑是/Apps/App3/SubApp1。這樣的層級結構，讓每一個Znode節點擁有唯一的路徑，就像命名空間一樣對不同信息作出清晰的隔離。
Znode類型
Znode分爲四種類型，分別是持久節點 （PERSISTENT）、持久節點順序節點（PERSISTENT_SEQUENTIAL）、臨時節點（EPHEMERAL） 、臨時順序節點（EPHEMERAL_SEQUENTIAL） 。
(1)持久節點： 默認的節點類型。創建節點的客戶端與zookeeper斷開連接後，該節點依舊存在 。
(2)持久節點順序節點: 與持久節點的區別就是在創建節點時，Zookeeper根據創建的時間順序給該節點名稱進行編號。
(3)臨時節點: 和持久節點相反，當創建節點的客戶端與zookeeper斷開連接後，臨時節點會被刪除：
(4)臨時順序節點： 和臨時順序節點的區別就是創建節點時，Zookeeper根據創建的時間順序給該節點名稱進行編號。客戶端斷開鏈接後還是會被刪除。Zookeeper實現分佈式鎖就是使用的這種節點。
Znode節點內信息
Zookeeper是爲讀多寫少的場景所設計，主要用來進行狀態、配置管理的，因此Znode並不用來存儲大規模業務數據，而是用於存儲少量的狀態和配置信息，每個節點的數據最大不能超過1MB。Znode包含訪問權限、數據、子節點指針等信息。
(1)Data：Znode存儲的數據信息。
(2)ACL：記錄Znode的訪問權限，即哪些人或哪些IP可以訪問本節點。ZooKeeper定義瞭如下5種權限,CREATE: 創建子節點的權限。READ: 獲取節點數據和子節點列表的權限。WRITE：更新節點數據的權限。DELETE: 刪除子節點的權限。ADMIN: 設置節點ACL的權限。需要注意的是CREATE 和 DELETE 都是針對子節點的權限控制。
(3)Stat：包含Znode的各種元數據，比如事務ID、版本號、時間戳、大小等等。Stat中記錄了這個ZNode的三個數據版本，分別是version（當前ZNode的版本）、cversion（當前ZNode子節點的版本）和aversion（當前ZNode的ACL版本）。
(4)Child：當前節點的子節點引用，類似於二叉樹的左孩子右孩子。
會話(Session)
Session是指客戶端會話，在ZooKeeper中，一個客戶端連接是指客戶端和ZooKeeper服務器之間的TCP長連接。ZooKeeper對外的服務端口默認是2181，客戶端啓動時，首先會與服務器建立一個TCP連接，從第一次連接建立開始，客戶端會話的生命週期也開始了，通過這個連接，客戶端能夠通過心跳檢測和服務器保持有效的會話，也能夠向ZooKeeper服務器發送請求並接受響應，同時還能通過該連接接收來自服務器的Watch事件通知。Session的SessionTimeout值用來設置一個客戶端會話的超時時間。當由於服務器壓力太大、網絡故障或是客戶端主動斷開連接等各種原因導致客戶端連接斷開時，只要在SessionTimeout規定的時間內能夠重新連接上集羣中任意一臺服務器，那麼之前創建的會話仍然有效。
心跳檢測: 這裏的心跳檢測指的是客戶端每隔一定時間就會像服務器發送Ping請求，證明自己還活着，服務器端接收到客戶端的請求後，會進行對應的客戶端的會話激活，會話激活就會延長該會話的存活期。如果會話一直沒有激活，那麼說明該客戶端掛掉了，服務器端的會話超時檢測任務就會檢查出那些一直沒有被激活的與客戶端的會話，然後進行清理，清理中有一步就是刪除這些客戶端創建的臨時節點和臨時有序節點。
事務操作
在ZooKeeper中，能改變ZooKeeper服務器狀態的操作稱爲事務操作。一般包括數據節點創建與刪除、數據內容更新和客戶端會話創建與失效等操作。對應每一個事務請求，ZooKeeper都會爲其分配一個全局唯一的事務ID，用ZXID表示，通常是一個64位的數字。每一個ZXID對應一次更新操作，從這些ZXID中可以間接地識別出ZooKeeper處理這些事務操作請求的全局順序。
Zookeeper特性
(1)順序一致性：從同一個客戶端發起的事務請求，最終將會嚴格按照其發起順序被應用到ZooKeeper中。
(2)原子性: 所有事務請求的結果在集羣中所有機器上的應用情況是一致的，也就是說要麼整個集羣所有集羣都成功應用了某一個事務，要麼都沒有應用，一定不會出現集羣中部分機器應用了該事務，而另外一部分沒有應用的情況。
(3)單一視圖：無論客戶端連接的是哪個ZooKeeper服務器，其看到的服務端數據模型都是一致的。
(4)可靠性：一旦服務端成功地應用了一個事務，並完成對客戶端的響應，那麼該事務所引起的服務端狀態變更將會被一直保留下來，除非有另一個事務又對其進行了變更。
(5)實時性:通常人們看到實時性的第一反應是，一旦一個事務被成功應用，那麼客戶端能夠立即從服務端上讀取到這個事務變更後的最新數據狀態。這裏需要注意的是，ZooKeeper僅僅保證在一定的時間段內，客戶端最終一定能夠從服務端上讀取到最新的數據狀態。這是因爲Zookeeper放棄了CAP原則中的A，而滿足了CP原則，Zookeeper爲了保證數據的一致性，需要在集羣各個節點機器上完成同步，再將數據返回。
Zookeeper集羣介紹
Zookeeper爲分佈式應用提供協調服務，作爲一個協調者每時每刻都可能需要進行協調，因此Zookeeper不能出現停止工作的時候，若Zookeeper位於單個機器上面，則可能會出現宕機情況，因此Zookeeper必須選擇集羣部署。而Zookeeper爲了提供了數據的一致性和容錯性，放棄了可用性，選擇了CP原則。Zookeeper爲了實現數據的一致性，必須先完成數據同步才能返回數據，而Zookeeper通過ZAB協議高效的完成了數據的同步並且完成了機器崩潰的修復，以此實現數據的一致性和容錯性。Zookeeper集羣採用的是一主多從的形式，一主也就是一個集羣只有一個Leader節點，多從也就是集羣有多個Follower、Observer服務器節點。只有Leader節點才能做寫服務，因此數據同步其實就是從Leader節點同步到其他從節點；而當Leader節點崩潰時，就無節點能進行寫服務以及協調從節點，因此Zookeeper服務基本不能使用，此時就需要有一定的機制進行恢復，ZAB協議提供了崩潰恢復和數據同步功能。
集羣角色與狀態
在ZooKeeper中，有三種角色：Leader、Observer、Follower，一個ZooKeeper集羣同一時刻只會有一個Leader，其他都是Follower或Observer；ZooKeeper默認只有Leader和Follower兩種角色，沒有Observer角色，若想添加Observer角色需要修改服務器節點的相關配置。Leader服務器爲客戶端提供讀和寫服務。Follower和Observer都能提供讀服務，不能提供寫服務。兩者唯一的區別在於，Observer機器不參與Leader選舉過程，也不參與寫操作的『過半寫成功』策略，因此Observer可以在不影響寫性能的情況下提升集羣的讀性能。
正常狀態下，不同節點有着各自的狀態，Leader節點狀態爲Leading，Observer節點狀態爲Observering，follow節點狀態爲following，當Leader節點崩潰後，集羣進入選舉狀態，此時除了不參與選舉的Observer節點，其它節點狀態都爲爲Locking。
ZAB協議
Zookeeper使用了一種稱爲ZooKeeper Atomic Broadcast（ZAB，ZooKeeper原子廣播協議）的協議作爲其數據一致性的核心算法。它是一種特別爲ZooKeeper設計的崩潰可恢復的原子廣播算法。ZAB協議包括兩種基本的模式，分別是崩潰恢復和消息廣播。在整個ZooKeeper集羣啓動過程中，或是當Leader服務器節點出現網絡中斷、崩潰退出與重啓等異常情況時，ZAB協議就會進入恢復模式並選舉產生新的Leader服務器節點。當選舉產生了新的Leader服務器節點，同時集羣中有過半的機器與該Leader服務器完成了數據同步之後，ZAB協議就會退出恢復模式進入消息廣播模式。消息廣播模式指的是Zookeeper在正常狀態下通過廣播的方式實現數據同步，採用的是二階段提交的方式。
崩潰修復
ZAB的崩潰恢復分成三個階段：選舉、發現、同步階段。
1.Leader election(選舉)
選舉階段，此時集羣中的節點處於Looking狀態。它們會各自向其他節點發起投票，投票當中包含自己的服務器ID和最新事務ID（ZXID）。接下來，節點會用自身的ZXID和從其他節點接收到的ZXID做比較，如果發現別人家的ZXID比自己大，也就是數據比自己新，那麼就重新發起投票，投票給目前已知最大的ZXID所屬節點。每次投票後，服務器都會統計投票數量，判斷是否有某個節點得到半數以上的投票。如果存在這樣的節點，該節點將會成爲準Leader，狀態變爲Leading。其他節點的狀態變爲Following。
2.Discovery(發現階段)
發現階段，用於在從節點中發現最新的ZXID和事務日誌。或許有人會問：既然Leader被選爲主節點，已經是集羣裏數據最新的了，爲什麼還要從節點中尋找最新事務呢？這是爲了防止某些意外情況，比如因網絡原因在上一階段產生多個Leader的情況。所以這一階段，Leader集思廣益，接收所有Follower發來各自的最新epoch值。Leader從中選出最大的epoch，基於此值加1，生成新的epoch分發給各個Follower。各個Follower收到全新的epoch後，返回ACK給Leader，帶上各自最大的ZXID和歷史事務日誌。Leader選出最大的ZXID，並更新自身歷史日誌。(epoch爲紀元，可以理解爲投票的輪次)
3.Synchronization(同步階段)
同步階段，把Leader剛纔收集得到的最新歷史事務日誌，同步給集羣中所有的Follower。只有當半數Follower同步成功，這個準Leader才能成爲正式的Leader。
消息廣播
1、所有寫事務請求必須由一個全局唯一的服務器來協調處理，這樣的服務器被稱爲Leader服務器，因此客戶端發出寫入數據請求給任意Follower，Follower都會把寫入數據請求轉發給Leader。
2、Leader採用二階段提交方式，先發送Propose(提案)廣播給Follower。
3.Follower接到Propose消息，寫入日誌成功後，返回ACK消息給Leader。
4.Leader接到半數以上ACK消息，返回成功給客戶端，並且廣播Commit請求給Follower，讓Follower節點提交事務。
參考:
https://www.jianshu.com/p/84ad63127cd1
https://mp.weixin.qq.com/s/Gs4rrF8wwRzF6EvyrF_o4A
https://my.oschina.net/u/3796575/blog/1845035