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