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

参考链接

Creative Commons License

本文基于署名-非商业性使用-相同方式共享 4.0许可协议发布,欢迎转载、使用、重新发布,但务必保留文章署名时延军(包含链接:http://shiyanjun.cn),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。如有任何疑问,请与我联系

限时福利1:原价 129 元,最后2天仅需 69 元!后天涨价至98元 限时福利2:购课进答疑群专享柳峰(刘运强)老师答疑服务 限时福利3:购课添加助教领取价值 800 元的编程大礼包 为什么需要掌握高性能的MySQL实战? 由于互联网产品用户量大、高并发请求场景多,因此对MySQL的性能、可用性、扩展性都提出了很高的要求。使用MySQL解决大量数据以及高并发请求已经是程序员的必备技能,也是衡量一个程序员能力和薪资的标准之一。 为了让大家快速系统了解高性能MySQL核心知识全貌,我为你总结了「高性能 MySQL 知识框架图」,帮你梳理学习重点,建议收藏! 【课程设计】 课程分为四大篇章,将为你建立完整的 MySQL 知识体系,同时将重点讲解 MySQL 底层运行原理、数据库的性能调优、高并发、海量业务处理、面试解析等。 一、性能优化篇: 主要包括经典 MySQL 问题剖析、索引底层原理和事务与锁机制。通过深入理解 MySQL 的索引结构 B+Tree ,学员能够从根本上弄懂为什么有些 SQL 走索引、有些不走索引,从而彻底掌握索引的使用和优化技巧,能够避开很多实战中遇到的“坑”。 二、MySQL 8.0新特性篇: 主要包括窗口函数和通用表表达式。企业中的许多报表统计需求,如果不采用窗口函数,用普通的 SQL 语句是很难实现的。 三、高性能架构篇: 主要包括主从复制和读写分离。在企业的生产环境中,很少采用单台MySQL节点的情况,因为一旦单个节点发生故障,整个系统都不可用,后果往往不堪设想,因此掌握高可用架构的实现是非常有必要的。 四、面试篇: 程序员获得工作的第一步,就是高效的准备面试,面试篇主要从知识点回顾总结的角度出发,结合程序员面试高频MySQL问题精讲精练,帮助程序员吊打面试官,获得心仪的工作机会。
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页