中小研發團隊架構實踐之分散式協調器.Net版ZooKeeper
Apache ZooKeeper是由Apache Hadoop的子專案發展而來，於2010年11月正式成為了Apache的頂級專案。
ZooKeeper是一個開放原始碼的分散式協調服務。它具有高效能、高可用的特點，同時也具有嚴格的順序訪問控制能力（主要是寫操作的嚴格順序性）。基於對ZAB協議（ZooKeeper Atomic Broadcast，ZooKeeper原子訊息廣播協議）的實現，它能夠很好地保證分散式環境中資料的一致性。也正是基於這樣的特性，使得ZooKeeper成為了解決分散式資料一致性問題的利器。
ZooKeeper整體架構
請見上圖，文字說明如下：
ZooKeeper由兩部分組成：ZooKeeper服務端和客戶端。
ZooKeeper伺服器採用叢集的形式。值得一提的是，只要叢集中存在超過一半的、處於正常工作狀態的伺服器，那麼整個叢集就能夠正常對外服務。組成ZooKeeper叢集的每臺伺服器都會在記憶體中維護當前的ZooKeeeper服務狀態，並且每臺伺服器之間都互相保持著通訊。
客戶端在連線ZooKeeper服務叢集時，會按照一定的隨機演算法選擇叢集中的某臺伺服器，然後和它共同建立一個TCP連線，使客戶端連上到那臺伺服器。而當那臺伺服器失效時，客戶端自動會重新選擇另一臺伺服器進行連線，從而保證服務的連續性。
當其中一個客戶端修改資料時，ZooKeeper會將修改同步到叢集中所有的伺服器上，從而使連線到叢集中其它伺服器上的客戶端也能立即看到修改後的資料，很好地保證了分散式環境中資料的一致性。
2.2 ZooKeeper資料模型
ZooKeeper資料模型
請見上圖，文字說明如下：
Zookeeper的資料模型採用類似於檔案系統的樹結構。樹上的每個節點稱為ZNode，而每個節點都可能有一個或者多個子節點。ZNode的節點路徑標識方式是由一系列斜槓【/】進行分割的路徑表示。
可以向ZNode節點寫入、修改、讀取資料，也可以建立、刪除ZNode節點或ZNode節點下的子節點。值得注意的是，ZooKeeper的設計目標不是傳統的資料庫儲存或者大資料物件儲存，而是協同資料的儲存，因此在實現時ZNode儲存的資料大小不應超過1MB。另外，每一個節點都有個ACL（Access Control List，訪問控制列表），據此控制該節點的訪問許可權。
ZNode資料節點是有生命週期的，其生命週期的長短取決於資料節點的節點型別。節點型別共有4種：持久節點（PERSISTENT）、持久順序節點（PERSISTENT_SEQUENTIAL）、臨時節點（EPHEMERAL）、臨時順序節點（EPHEMERAL_SEQUENTIAL）。
2.3 Watcher：ZNode資料變化通知ZooKeeper的Watcher機制，概括為三個過程：客戶端註冊Watcher成為訂閱者、服務端處理Watcher以及客戶端回撥Watcher。
客戶端在自己需要關注的位於ZooKeeper伺服器裡的ZNode節點上註冊一個Watcher監聽後，一旦這個ZNode節點發生變化，則在該節點上註冊過Watcher監聽的所有客戶端會收到ZNode節點變化通知。在收到通知時，客戶端通過回撥Watcher做相應的處理，從而實現特定的功能。
三、ZooKeeper的典型應用場景通過對ZooKeeper中豐富的資料節點型別進行交叉使用，配合Watcher事件通知機制，可以非常方便地構建分散式應用中都會涉及的核心功能，如：資料釋出/訂閱（即配置中心）、負載均衡、命名服務、分散式協調/通知、叢集管理、Master選舉、分散式鎖和分散式佇列等。
3.1 配置服務：ConfigServiceDemoDemo中的【ConfigServiceDemo（配置服務Demo）】適用於ZooKeeper的配置中心應用場景：
應用中用到的一些常用配置資訊放到ZooKeeper的一系列ZNode節點上，供應用獲取配置資料；同時，如果某應用在需要關注的配置項節點上註冊了個Watcher，則以後每次被關注的配置項有更新的時候，都會實時通知到該應用，從而達到獲取最新配置資訊的目的。
3.1.1 為公司解決了什麼問題a. 減少我們的運維工作人員的工作量：當公司的應用程式以叢集環境模式被部署的時候，若第1次部署應用程式或遇到需要配置新增/修改/刪除的情況，我們的運維工作人員不得不為叢集中的每臺伺服器進行一臺一臺地修改。而利用了ZooKeeper後，他們只需要修改一次，就能為叢集中的所有伺服器完成配置新增/修改/刪除。
b. 使任意客戶端能夠看到即時生效的被改後的配置資料：目前現狀：由於運維工作人員需要為叢集中的每臺伺服器進行一臺一臺地配置修改，而導致出現了配置延時問題，使得叢集中的每臺伺服器的配置資料不一致。也就是說，客戶端（如應用程式）可能會無法立即讀取到最新的配置值，需要過段時間後才能讀取到。當運維工作人員利用ZooKeeper修改配置資料後，新的配置資料會立即被同步到叢集中的所有伺服器，從而保證叢集中的所有伺服器的配置資料對於任意客戶端而言每時每刻都是準確無誤的（可選加Watcher）。
3.1.2 ConfigService管理下圖顯示的是ZooKeeper配置服務頁面。
3.2 Master選舉：MasterElectionDemo 3.2.1 為公司解決了什麼問題
我們都知道，叢集中的伺服器一般只有1臺起著Master角色。一旦這臺具有Master角色的伺服器出現宕機情況，則就出現了伺服器單點故障問題。並且，我們並不知道這臺具有Master角色的伺服器是從什麼時候開始處於宕機狀態。利用ZooKeeper的“對在ZooKeeper上建立的臨時順序節點（EPHEMERAL_SEQUENTIAL），一旦建立它的客戶端與ZooKeeper服務叢集之間的會話失效，那麼該臨時節點也就被自動清除”這一特性，再加上Watcher事件通知機制的使用，就能夠解決伺服器的單點故障問題——一旦當前具有Master角色的伺服器宕機了，它建立的臨時順序節點（EPHEMERAL_SEQUENTIAL）會馬上消失；緊接著叢集中註冊過Watcher的所有伺服器會馬上收到當前Master伺服器已宕機的通知，然後將重新進行Master選舉。
四、Demo下載及更多資料- ZooKeeperDemo下載地址：https://github.com/das2017/ZooKeeperDemo
- ZooKeeper（v3.4.10） 官網：http://zookeeper.apache.org/doc/r3.4.10/
- ZooKeeper客戶端下載地址：https://github.com/ewhauser/zookeeper