我們通過學習借鑒，哪些項目或應用都使用了ZooKeeper，可以了解我們的應用使用ZooKeeper是否能真正地帶來價值，當然，有些項目可能也未必非常適合使用ZooKeeper，我們要批判地學習、借鑒和吸收。 下面是一些使用了ZooKeeper實現的案例：
Hadoop 2.x之前的版本，HDFS集群中Namenode是整個集群的中央元數據存儲和服務節點，它存在SPOF的問題。在2.x版本中，提出了各種HA方案，避免Namenode的SPOF問題，其中基於QJM（Quorum Journal Manager）的方案可以解決這個問題：使用QJM的方案中，HDFS集群中存在兩類節點，一類是Namenode節點（包括Active狀態的Namenode，和Standby狀態的Namenode），另一類是JournalNode，進行容錯。當Active狀態的Namenode元數據發生改變時，通過JournalNode進程（ZooKeeper集群中）來監視這種變化，然后同步到Standby狀態的Namenode節點（實際上同步的是EditLog鏡像文件內容的變更）。 當Active狀態的節點發生故障后，Standby節點的Namenode自動切換，並接管HDFS集群中Active狀態Namenode的服務，用來向客戶端提供元數據服務。
Solr是一個開源的分布式搜索引擎，支持索引的分片和復制，可以根據需要來線性增加節點，擴展集群。Solr使用ZooKeeper主要實現如下功能：
- 配置文件的管理：每個Collection都有對應的配置文件，多個分片共享配置文件（schema.xml、solrconfig.xml）
- Collection管理：一個Solr集群可以有多個邏輯上獨立的Collection，每個Collection又包括多個分片和副本
- 集群節點管理：Solr集群中有哪些活躍的節點可以使用，每個節點上都有Collection的分片（Shard）
- Leader分片選舉：一個Collection的多個分片可以設置冗余的副本，一個分片的多個副本中只有一個Leader可以進提供服務，如果某個存儲Leader分片的節點宕機，Solr基於ZooKeeper來重新選出一個Leader分片，持續提供服務
HBase是一個基於Hadoop平台的開源NoSQL數據庫，它使用ZooKeeper主要實現如下功能：
- Master選舉：HBase基於Master-Slave模式架構，可以有多個HMaster，使用ZooKeeper實現了SPOF下Master的選舉
- 租約管理：客戶端與RegionServer交互時，會生成租約，該租約對象具有有效期
- 表元數據管理：HBase中包括用戶表及其兩個特殊的表：-ROOT-表和.META.表（例如，管理-ROOT-表中location信息，一個-ROOT-表只有一個Region，它保存了RegionServer的地址信息。）
- 協調RegionServer節點：數據變更會通過ZooKeeper同步復制到其他節點
Lily是一個分布式數據管理平台，它基於Hadoop、HBase、Solr、ZooKeeper實現。使用ZooKeeper來注冊Lily Node，從而管理集群節點的狀態信息。
Dubbo是阿里巴巴開源的分布式服務框架，它可以選擇使用ZooKeeper作為服務注冊中心。Dubbo服務基於Provider-Consumer模型，在服務發布的時候可以選擇使用ZooKeeper作為注冊中心來管理注冊的服務，包括Provider發布的服務和Consumer訂閱的服務。
Katta實現了Lucene的分布式索引，能夠提供數據的實時訪問。Katta使用ZooKeeper實現了集群節點的管理，Master的選舉，以及Lucene索引的管理。
Storm流式計算框架使用ZooKeeper來協調整個計算集群，Storm計算集群存在Nimbus和Supervisor兩類節點。Nimbus負責分配任務（Topology），將任務信息寫入ZooKeeper存儲，然后Supervisor從ZooKeeper中讀取任務信息。另外，Nimbus也監控集群中的計算任務節點，Supervisor也會發送心跳信息（包括狀態信息）到ZooKeeper中，使得Nimbus可以實現狀態的監控，任何計算節點出現故障，只要重新啟動之后，繼續從ZooKeeper中獲取數據即可繼續執行計算任務。
BookKeeper是Apache ZooKeeper項目的一個子項目。它是一個用來可靠地記錄流數據的系統，主要用於存儲WAL（Write Ahead Log）。 我們知道，Hadoop Namenode用來存儲HDSF集群的元數據，其中存在一個用於寫就花數據的EditLog文件，和一個存在於內存中的FsImage鏡像，每當客戶端與HDFS集群交互時，對於集群中數據的變更都會記錄在Namenode的EditLog文件中，然后再將該變更同步到內存的FsImage鏡像上。 在BookKeeper中，服務節點（多個）稱為Bookie，日志流（Log Stream）稱為Ledger，每個日志單元（如一條記錄）被稱為Ledger條目。一組服務節點Bookie主要存儲Ledger，Ledger的類型非常復雜多樣，那么可能某一個Bookie節點可能發生故障，然而只要我們的BookKeeper系統的多個服務節點Bookie存儲中存在正確可用的節點，整個系統就可以正常對外提供服務，BookKeeper的元數據存儲在ZooKeeper中（使用ZooKeeper存儲的只是元數據，實際日志流數據存儲在Bookie中）。 Hadoop HDFS HA基於BookKeeper系統，可以實現HDFS Namenode的高可用性，這種方案稱為BJM（BookKeeper Journal Manager），HDFS HA的另一種方案叫做QJM（Quorum Journal Manager）。可以參考相關文檔，在后面會給出參考連接。
HedWig是基於ZooKeeper和BookKeeper的發布-訂閱系統。在HedWig系統中，使用ZooKeeper來持久化系統的元數據，使用BookKeeper來存儲實際的消息數據。
其他方案
還有其他一些開源方案，都使用了ZooKeeper，如下所示：
更多其他使用ZooKeeper的公司或方案，可以參考鏈接：http://wiki.apache.org/hadoop/ZooKeeper/PoweredBy
參考鏈接
- http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/HDFSHighAvailabilityWithQJM.html#Deploying_ZooKeeper
- http://hbase.apache.org
- http://wiki.apache.org/hadoop/Hbase/MultipleMasters
- http://lucene.apache.org/solr/
- http://www.lilyproject.org/lily/index.html
- http://code.alibabatech.com/wiki/display/dubbo
- http://katta.sourceforge.net/
- http://katta.sourceforge.net/about
- http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/
- https://github.com/nathanmarz/storm/wiki/Setting-up-a-Storm-cluster
- http://zookeeper.apache.org/bookkeeper/
- https://cwiki.apache.org/confluence/display/BOOKKEEPER/BookKeeper
- http://koven2049.iteye.com/blog/1290713
- https://cwiki.apache.org/confluence/display/BOOKKEEPER/HDFS+BookKeeperJournalManager
- https://cwiki.apache.org/confluence/display/BOOKKEEPER/HedWig
- http://kafka.apache.org/
- http://flume.apache.org/
- http://accumulo.apache.org/
- http://mesos.apache.org/
- http://stackoverflow.com/questions/1479442/real-world-use-of-zookeeper
- http://wiki.apache.org/hadoop/ZooKeeper/PoweredBy
本文基於署名-非商業性使用-相同方式共享 4.0許可協議發布，歡迎轉載、使用、重新發布，但務必保留文章署名時延軍（包含鏈接：http://shiyanjun.cn），不得用於商業目的，基於本文修改后的作品務必以相同的許可發布。如有任何疑問，請與我聯系。