ZooKeeper應用案例

時間 2019-11-12

原文原文鏈接

咱們經過學習借鑑，哪些項目或應用都使用了ZooKeeper，能夠了解咱們的應用使用ZooKeeper是否能真正地帶來價值，固然，有些項目可能也未必很是適合使用ZooKeeper，咱們要批判地學習、借鑑和吸取。下面是一些使用了ZooKeeper實現的案例：html

HDFS HA(QJM) java

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的服務，用來向客戶端提供元數據服務。node

Solr git

Solr是一個開源的分佈式搜索引擎，支持索引的分片和複製，能夠根據須要來線性增長節點，擴展集羣。Solr使用ZooKeeper主要實現以下功能：github

配置文件的管理：每一個Collection都有對應的配置文件，多個分片共享配置文件（schema.xml、solrconfig.xml）
Collection管理：一個Solr集羣能夠有多個邏輯上獨立的Collection，每一個Collection又包括多個分片和副本
集羣節點管理：Solr集羣中有哪些活躍的節點可使用，每一個節點上都有Collection的分片（Shard）
Leader分片選舉：一個Collection的多個分片能夠設置冗餘的副本，一個分片的多個副本中只有一個Leader能夠進提供服務，若是某個存儲Leader分片的節點宕機，Solr基於ZooKeeper來從新選出一個Leader分片，持續提供服務

HBase 數據庫

HBase是一個基於Hadoop平臺的開源NoSQL數據庫，它使用ZooKeeper主要實現以下功能：apache

Master選舉：HBase基於Master-Slave模式架構，能夠有多個HMaster，使用ZooKeeper實現了SPOF下Master的選舉
租約管理：客戶端與RegionServer交互時，會生成租約，該租約對象具備有效期
表元數據管理：HBase中包括用戶表及其兩個特殊的表：-ROOT-表和.META.表（例如，管理-ROOT-表中location信息，一個-ROOT-表只有一個Region，它保存了RegionServer的地址信息。）
協調RegionServer節點：數據變動會經過ZooKeeper同步複製到其餘節點

Lily 架構

Lily是一個分佈式數據管理平臺，它基於Hadoop、HBase、Solr、ZooKeeper實現。使用ZooKeeper來註冊Lily Node，從而管理集羣節點的狀態信息。框架

Dubbo 分佈式

Dubbo是阿里巴巴開源的分佈式服務框架，它能夠選擇使用ZooKeeper做爲服務註冊中心。Dubbo服務基於Provider-Consumer模型，在服務發佈的時候能夠選擇使用ZooKeeper做爲註冊中心來管理註冊的服務，包括Provider發佈的服務和Consumer訂閱的服務。

Katta

Katta實現了Lucene的分佈式索引，可以提供數據的實時訪問。Katta使用ZooKeeper實現了集羣節點的管理，Master的選舉，以及Lucene索引的管理。

Strom

Storm流式計算框架使用ZooKeeper來協調整個計算集羣，Storm計算集羣存在Nimbus和Supervisor兩類節點。Nimbus負責分配任務（Topology），將任務信息寫入ZooKeeper存儲，而後Supervisor從ZooKeeper中讀取任務信息。另外，Nimbus也監控集羣中的計算任務節點，Supervisor也會發送心跳信息（包括狀態信息）到ZooKeeper中，使得Nimbus能夠實現狀態的監控，任何計算節點出現故障，只要從新啓動以後，繼續從ZooKeeper中獲取數據便可繼續執行計算任務。

BookKeeper

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

HedWig是基於ZooKeeper和BookKeeper的發佈-訂閱系統。在HedWig系統中，使用ZooKeeper來持久化系統的元數據，使用BookKeeper來存儲實際的消息數據。

其餘方案

還有其餘一些開源方案，都使用了ZooKeeper，以下所示：

更多其餘使用ZooKeeper的公司或方案，能夠參考連接：http://wiki.apache.org/hadoop/ZooKeeper/PoweredBy

參考連接

本文基於署名-非商業性使用-相同方式共享 4.0許可協議發佈，歡迎轉載、使用、從新發布，但務必保留文章署名時延軍（包含連接：http://shiyanjun.cn），不得用於商業目的，基於本文修改後的做品務必以相同的許可發佈。若有任何疑問，請與我聯繫。

相關標籤/搜索