ZooKeeper应用案例

我们通过学习借鉴，哪些项目或应用都使用了ZooKeeper，可以了解我们的应用使用ZooKeeper是否能真正地带来价值，当然，有些项目可能也未必非常适合使用ZooKeeper，我们要批判地学习、借鉴和吸收。 下面是一些使用了ZooKeeper实现的案例：

HDFS HA(QJM)

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是一个开源的分布式搜索引擎，支持索引的分片和复制，可以根据需要来线性增加节点，扩展集群。Solr使用ZooKeeper主要实现如下功能：

  • 配置文件的管理：每个Collection都有对应的配置文件，多个分片共享配置文件（schema.xml、solrconfig.xml）
  • Collection管理：一个Solr集群可以有多个逻辑上独立的Collection，每个Collection又包括多个分片和副本
  • 集群节点管理：Solr集群中有哪些活跃的节点可以使用，每个节点上都有Collection的分片（Shard）
  • Leader分片选举：一个Collection的多个分片可以设置冗余的副本，一个分片的多个副本中只有一个Leader可以进提供服务，如果某个存储Leader分片的节点宕机，Solr基于ZooKeeper来重新选出一个Leader分片，持续提供服务

HBase

HBase是一个基于Hadoop平台的开源NoSQL数据库，它使用ZooKeeper主要实现如下功能：

  • 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），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。如有任何疑问，请与我联系。

 

posted @ 2016-04-30 23:11  "程序猿"~在路上  阅读(2589)  评论(0)  编辑  收藏  举报