首页 > 新闻动态 > 电商技术

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来存储实际的消息数据。


产品推荐

关于我们  | 联系我们  | 加入我们 版权所有 ©2015-©2024 北京易写科技有限公司.保留一切权利.ICP证:京ICP备16052268号-3