我们通过学习借鉴,哪些项目或应用都使用了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),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。如有任何疑问,请与我联系。