ZooKeeper在大型分布式系统中的应用。

Hadoop

在Hadoop中，ZooKeeper主要用于实现HA（High Availability），这部分逻辑主要集中在Hadoop Common的HA模块中，HDFS的NameNode与YARN的ResourceManager都是基于HA模块来实现自己的HA功能的。同时，在YARN中又特别提供了ZooKeeper来存储应用的运行状态。

YARN
YARN是Hadoop 为了提高计算节点Master（JT）的扩展性，同时为了支持多计算模型和提供资源的细粒度调试而引入的全新一代分布式调试框架。其上可以支持MapReduce计算引擎，也支持其它一些计算引擎，如Tez,Spark,Storm,Imlala和Open MPI等。
YARN主要由ResourceManager、NodeManager、ApplicationMaster和Container四部分组成。其中最核心的就是ResourceManager，它作为全局的资源管理器，负责整个系统的资源管理和分配。

YARN设计了一套Active/Standby模式的Resourcemanager HA架构。在运行期间，允许多个ResourceManager并存，并且其中只有一个ResourceManager处于Active状态，另外的一些则是处理Standby状态，当Active节点无法正常工作时，其余处于Standby状态的节点则会通过竞争选举产生新的Active节点。

主备切换
YARN实现多个ResourceManager之间的主备切换过程：
1. 创建锁节点，在ZooKeeper上会有一个类似于/yarn-leader-election/pseudo-yarn-rm-cluster的锁节点，所有的ResourceManager在启动的时候，都会去竞争写一个Lock子节点，创建成功的那个就切换为Active状态。
2. 注册Watcher监听，所有Standby状态的ResourceManager都会向/yarn-leader-election/pseudo-yarn-rm-cluster/ActiveStandbyElectorLock节点注册一个节点变更的Watcher监听。
3. 主备切换

Fencing隔离
在分布式环境中，经常会出现诸如单机”假死“的情况。所谓的”假死“是指机器由于网络闪断或是其自身由于负载过高而导致无法正常地对外进行及时响应。这会发生某个时刻出现多个Active状态的ResourceManager。
Yarn中引入了Fencing机制，借助ZooKeeper数据节点的ACL权限控制机制来实现不同RM之间的隔离。具体做法是，在上文的”主备切换**部分中，多个RM之间通过竞争创建锁节点来实现主备状态的确定。这个地方需要改进的一点是，创建的根节点必须携带ZooKeeper的ACL信息，目的是为了独占该节点，以防止其它RM对该节点进行更新。

ResourceManager状态存储
在ResourceManager中，RMStateStore能够存储一些RM的内部状态信息，包括 Application以及它们的Attempts信息、Delegation Token及Version Information等。需要注意的是，RMStateStore中绝大多数状态信息都是不需要持久化存储的，因为很容易从上下文信息中将其重构出来，如资源的使用情况。在存储的设计方案中，提供了三种可能的实现，分别如下：

基于内存实现，一般是用于日常开发测试 基于文件系统的实现，如HDFS 基于ZooKeeper的实现。
Hadoop官方建议基于ZooKeeper来实现状态信息的存储。在ZooKeeper中，ResourceManager的状态信息都被存储在/rmstore这个根节点下面。

ZooKeeper一开始是Hadoop的子项目，因此很多设计之初的原始需求都是为了解决Hadoop系统中碰到的一系列分布式问题。

HBase

HBase是Google BigTable的开源实现，一个基于Hadoop文件系统设计的面向海量数据的高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可以在廉价的PC服务器上搭建起大规模结构化的存储集群。

与大部分分布式NoSQl数据库不同的是，HBase针对数据写入具有强一致性的特性，甚至包括索引列也都实现了强一致性。HBase的实现上严格遵守了Google BigTable论文的设计思想。BigTable使用Chubby来负责分布式状态的协调，这是Google实现的一种基于Paxos算法的分布式锁服务，而HBase则采用了开源的ZooKeeper服务来完成对整个系统的分布式协调工作。

在HBase的整体构架体系中，ZooKeeper是串联起HBase集群与Client的关键所在，实现以下几个重要功能：

系统冗错 RootRegion管理 Region状态管理 分布式SplitLog任务管理 Replication管理

Kafka

Kafka是一个吞吐量极高的分布式消息系统，其整体设计是典型的发布与订阅模式系统。
Kafka在以下功能中会使用ZooKeeper
1. Broker注册
2. Topic注册
3. 生产者负载均衡
4. 四层负载的均衡
5. 使用ZooKeeper进行负载均衡
6. 消费者负载均衡

Kafka从设计之初就是一个大规模的分布式消息中间件，其服务端存在多个Broker，同时为了达到负载均衡，将每个Topic的消息分布了多个分区，并分布在不同的Broker上，多个生产者和消费者能够同时发送和接收消息。Kafka使用ZooKeeper作为其分布式协调框架，很好地将消息生产、消息存储和消息消费的过程有机地结合起来。同时借助ZooKeeper，Kafka能够在保持包括生产者、消费者和Broker在内的所有组件无状态的情况下，建立起生产者和消费者之间的订阅关系，并实现了生产者和消费者的负载均衡。

ZooKeeper在阿里巴巴的实践与应用

消息中间件：Metamorphosis

项目地址： https://github.com/killme2008/Metamorphosis

JMS规范的开源实现。

RPC服务框架：Dubbo

项目地址：https://github.com/alibaba/dubbo

基于MySQL Binlog的增量订阅和消费组件：Canal

项目地址：https://github.com/alibaba/canal
早期的数据库同步业务，大多都是使用MySQl的数据库的触发器机制（即Trigger）来获取数据库的增量变更。从2010年开始，阿里系下属公司开始逐步尝试基于数据库的日志解析来获取增量变更，并在此基础上实现数据的同步，由此衍生出了数据库的增量订阅和消费业务——Canal项目也由此诞生了。

分布式数据库同步系统：Otter

项目地址： https://github.com/alibaba/otter

轻量级分布式通用搜索平台：终搜

阿里早期的一款产品。

JStorm 实时计算引擎

阿里在Storm基础上改造和优化的一个分布式实时计算引擎。