課題：zk選舉演算法、ZAB原子廣播協議如何實現的，CAS、Paxos

1、Zookeeper簡介

        Zookeeper是一個高效的分散式協調服務，它暴露了一些公用服務，比如：命名/配置管理/同步控制/群組服務等。我們可以使用ZK來實現比如：達成共識/叢集管理/Leader選舉等。

        Zookeeper是一個高可用的分散式管理與協調框架，基於ZAB演算法（原子訊息廣播協議）的實現。該框架能夠很好的保證分散式環境中資料的一致性。也正是基於這樣的特性，使得Zookeeper成為了解決分散式一致性問題的利器。

2、Zookeeper特點

        順序一致性：從一個客戶端發起的事物請求，最終將會嚴格的按照其發起的順序被應用到Zookeeper中去。

        原子性：所有事物請求的處理結果在整個叢集中所有機器上的應用情況是一致的。也就是說，要麼整個叢集所有的機器都成功應用了某一事物，要麼都沒有應用，一定不會出現部分機器應用了該事物，而另一部分沒有應用的情況。

        單一檢視：無論客戶端連線的是哪一個Zookeeper伺服器，其看到的伺服器端資料模型都是一致的。

        可靠性：一旦伺服器成功的應用了一個事物，並完成對客戶端的響應，那麼該事物所引起的伺服器端狀態將會被一直保留下來，除非有另一個事物對其更改。

        實時性：通常所說的實時性就是指一旦事物被成功應用，那麼客戶端就能立刻從伺服器上獲取變更後的新資料。Zookeeper僅僅能保證在一段時間內，客戶端最終一定能從伺服器端讀取最新的資料（最終一致性）。

3、Zookeeper設計目標

        目標1：簡單的資料結構。Zookeeper就是以簡單的樹形結構來進行相互協調的（也叫樹形名字空間）。

        目標2：可以構建叢集。一般Zookeeper叢集通常由一組機器構成，一般3~5臺機器就可以組成一個Zookeeper叢集了。只要叢集中超過半數以上的機器能夠正常工作，那麼整個叢集就能夠正常對外提供服務。

        目標3：順序訪問。對應來自每一個客戶端的每一個請求，Zookeeper都會分配一個全域性唯一的遞增編號，這個編號反應了所有事物操作的先後順序，應用程式可以使用Zookeeper的這個特性來實現更高層次的同步。

        目標4：高效能。由於Zookeeper將全量資料儲存在記憶體中，並直接服務於所有的非事物請求，因此尤其是在讀操作為主的場景下效能非常突出。在JMater壓力測試下（100%讀請求場景下），其結果大約在12~13w的QPS。

4、資料模型

        每個子目錄項如NameService都被稱作為znode，這個znode是被它所在的路徑唯一標識，如Server1這個znode的標識為/NameService/Server1

        znode可以有子節點目錄，並且每個znode可以儲存資料，注意EPHEMERAL型別的目錄節點不能有子節點目錄。

        znode是有版本的，每個znode中儲存的資料可以有多個版本，也就是一個訪問路徑中可以儲存多份資料。

        znode可以是臨時節點，一旦建立這個znode的客戶端與伺服器失去聯絡，這個znode也將自動刪除，Zookeeper的客戶端和伺服器通訊採用長連線方式，每個客戶端和伺服器通過心跳來保持連線，這個連線狀態稱為session，如果znode是臨時節點，這個session失效，znode也就刪除了。

        znode的目錄名可以自動編號，如App1已經存在，再建立的話，將會自動命名為App2.

        znode可以被監控，包括這個目錄節點中儲存的資料的修改，子節點目錄的變化等，一旦變化可以通知設定監控的客戶端，這個是Zookeeper的核心特性，Zookeeper的很多功能都是基於這個特性實現的。

5、Zookeeper組成

        ZK server根據其身份特性分為三種：Leader，Follower，Observer。其中Follower和Observer又稱Learner（學習者）。

        Leader：負責客戶端的writer型別的請求，所有事物請求。

        Follower：負責客戶端的reader型別的請求

        Observer：特殊的“Follower”，其可以接受客戶端reader請求，但不參與選舉，不響應提議，不將事物持久化到磁碟。（擴容系統支援能力，提高了讀取速度、吞吐量）（如果ZooKeeper叢集的讀取負載很高，或者客戶端多到跨機房，可以設定一些observer伺服器，以提高讀取的吞吐量。Observer和Follower比較相似，只有一些小區別：首先observer不屬於法定人數，即不參加選舉也不響應提議；其次是observer不需要將事務持久化到磁碟，一旦observer被重啟，需要從leader重新同步整個名字空間。）

6、應用場景

        Zookeeper從設計模式角度來看，是一個基於觀察者模式設計的分散式服務管理框架，它負責儲存和管理大家都關心的資料，然後接受觀察者的註冊，一旦這些資料的狀態發生變化，Zookeeper就將負責通知已經在Zookeeper上註冊的那些觀察者做出相應的反應，從而實現叢集中類似Master/Slave管理模式。

        配置管理：配置的管理在分散式應用環境中很常見，比如我們在平常的應用系統中，經常會碰到這樣的需求：如機器的配置列表、執行時的開關配置、資料庫配置資訊等。這些全域性配置資訊通常具備以下3個特性：①資料量比較小。②資料內容在執行時動態發生變化。③叢集中各個叢集共享資訊，配置一致。

        叢集管理：Zookeeper不僅能維護當前的叢集中機器的服務狀態，而且能夠幫你選出一個“總管”，讓這個總管來管理叢集，這就是Zookeeper的另一個功能Leader，並實現叢集容錯功能。①：希望知道當前叢集中究竟有多少機器工作。②對叢集中每天叢集的執行時狀態進行資料收集。③對叢集中每臺叢集進行上下線操作。

        釋出與訂閱：Zookeeper是一個典型的釋出/訂閱模式的分散式數控管理與協調框架，開發人員可以使用它來進行分散式資料的釋出與訂閱。

        資料庫切換：比如我們初始化Zookeeper的時候讀取節點上的資料庫配置檔案，當配置一旦發生變更時，Zookeeper就能幫助我們把變更的通知發生到各個客戶端，每個客戶端在接受到這個變更通知後，就可以重新進行最新資料的獲取。

        分散式日誌的收集：我們可以做一個日誌系統收集叢集中所有的日誌資訊，進行統一管理。

        分散式鎖、佇列管理等等

        開源框架應用：Hadoop、Storm、訊息中介軟體、RPC服務框架、資料庫增量訂閱與消費元件（如 Mysql Binlog）、分散式資料庫同步系統：淘寶的Otter等，

7、Zookeeper API

        Zookeeper的特性就是在分散式場景下高可用，但是原生的API實現分散式功能非常困難，團隊去實現也太浪費時間，即使實現了也未必穩定。那麼可用採用第三方的客戶端的完美實現，比如Curator框架，它是Apache的頂級專案。

8、Watcher、ZK狀態、事件型別

        Zookeeper有watch事件，是一次性觸發的，當watch監視的資料發生變化時，通知設定了該watch的client，即watcher。

        同樣，其watcher是監聽資料傳送了某些變化，那就一定會有對應的事件型別和狀態型別。

        事件型別：（znode節點相關的）

                        EventType.NodeCreated

                        EventType.NodeDataChanged

                        EventType.NodeChildrenChanged

                        EventType.NodeDeleted

        狀態型別：(和客戶端例項相關)

                        KeeperState.Disconnected

                        KeeperState.SyncConnected

                        KeeperState.AuthFailed

                        KeeperState.Expired

9、watcher的特性

        一次性、客戶端序列執行、輕量。

        一次性：對於ZK的watcher，你只需要記住一點：Zookeeper有watch事件，是一次性觸發的，當watch監視的資料發生變化時，通知設定了該watch的client，即watcher，由於Zookeeper的監控都是一次性的，所以每次必須設定監控。

        客戶端序列執行：客戶端watcher回撥的過程是一個串行同步的過程，這為我們保證了順序，同時需要開發人員注意一點，千萬不要因為一個watcher的處理邏輯影響了整個客戶端的watcher回撥。

        輕量：WatchedEvent是Zookeeper整個Watcher通知機制的最小通知單元，整個資料結構只包含三部分：通知狀態、事件型別和節點路徑。也就是說Watcher通知非常的簡單，只會告訴客戶端發生了事件而不會告知其具體內容，需要客戶自己去進行獲取，比如NodeDataChanged事件，Zookeeper只會通知客戶端指定節點的資料發生了變更，而不會直接提供具體的資料內容。

10、ACL

        Zookeeper作為一個分散式協調框架，其內部儲存的都是一些關乎分散式系統執行時狀態的元資料，尤其是設計到一些分散式鎖、Master選舉和協調等應用場景。我們需要有效的保證Zookeeper中的資料安全，Zookeeper提供了三種模式。許可權模式、授權模式、許可權。

        許可權模式的分類：IP、Digest、World、Super

        許可權物件：指的是許可權賦予的使用者或者一個指定的實體，例如ip地址或機器等。在不同的模式下，授權物件是不同的。這種模式和許可權物件一一物件。

        許可權：許可權就是指那些通過許可權檢測後可以被執行執行的操作，在ZK中，對資料的操作許可權分為五大類：CREATE、DELETE、READ、WRITE、ADMIN

11、Curator場景應用

        分散式鎖功能：在分散式場景中，我們為了保證資料的一致性，經常在程式執行的某一個點需要進行同步操作。使用Curator基於Zookeeper的特性提供的分散式鎖來處理分散式場景的資料一致性。

        分散式計數器功能：針對jvm的場景，可能想到AtomicInteger。但是我們在分散式場景下，就需要利用Curator框架的DistributedAtomicInteger了。

12、ZAB協議（具體參考《從Paxos到Zookeeper》）

        ZAB協議的核心是定義了對於那些會改變ZooKeeper伺服器資料狀態的事物請求的處理方式：即：所有事物請求必須由一個全域性唯一的伺服器來協調處理，這樣的伺服器被稱為Leader伺服器，而餘下的其他伺服器則成為Follower伺服器。？Leader伺服器負責將一個客戶端事物請求轉換成為一個事物Proposal（提議），並將該Proposal分發給叢集中所有的Follower伺服器。之後Leader伺服器需要等待所有Follower伺服器的反饋，一旦超過半數的Follower伺服器進行了正確的反饋後，那麼Leader就會再次向所有的Follower伺服器分發Commit訊息，要求將前一個Proposal進行提交。

        ZAB協議的兩種基本模式：崩潰恢復和訊息廣播。

        保證舊Leader已經提交的訊息所有其他節點都提交，保證所有其他節點丟棄已經跳過的訊息。

13、ZAB與Paxos演算法的聯絡與區別

        具體參考《從Paxos到Zookeeper》4.2.4  P77

14、Leader選舉演算法（ZXID）

        具體參考《從Paxos到Zookeeper》4.2.4  P321

        ①每個Server會發出一個投票。

        ②接受來自各個伺服器的投票。

        ③處理投票。

        ④統計投票。

        ⑤改變伺服器狀態。

15、Leader選舉演算法核心實現

         具體參考《從Paxos到Zookeeper》4.2.4  P332

        ①自增選舉輪次

        ②初始化選票

        ③傳送初始化選票

        ④接收外部投票

        ⑤判斷選舉輪次

        ⑥選票PK

        ⑦變更投票

        ⑧選票歸檔

        ⑨統計投票

        ⑩更新伺服器狀態