ZooKeeper概述

• ZooKeeper 分布式服务框架主要是用来解决分布式应用中经常遇到的一些数据管理问题，提供分布式、高可用性的协调服务能力。
• 安全模式下ZooKeeper依赖于Kerberos和LdapServer进行安全认证，非安全模式则不依赖于Kerberos与Ldap。ZooKeeper作为底层组件广泛被上层组件使用并依赖，如Kafka，HDFS，HBase，Storm等。
• 精简的文件系统，每个节点可以存数据，可以存子节点的信息。

ZooKeeper关键特性

• 最终一致性：无论哪个server，对外展示的均是同一个视图。
• 实时性：保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。
• 可靠性：一条消息被一个server接收，它将被所有server接受。
• 等待无关性：慢的或者失效的client不会干预快速的client的请求，使得每个client都能有效的等待。
• 原子性：更新只能成功或者失败，没有中间状态。
• 顺序一致性：客户端所发送的更新会按照它们被发送的顺序进行应用。

ZooKeeper模型

• ZooKeeper集群由一组Server节点组成，这一组Server节点中存在一个角色为Leader的节点，其他节点都为Follower。当客户端Client连接到ZooKeeper集群，并且执行写请求时，这些请求会被发送到Leader节点上，然后Leader节点上数据变更会同步到集群中其他的Follower节点。
• Leader节点在接收到数据变更请求后，首先将变更写入本地磁盘，以作恢复之用。当所有的写请求持久化到磁盘以后，才会将变更应用到内存中。
• ZooKeeper使用了一种自定义的原子消息协议（ZooKeeper Atomic Broadcast Zab协议），在消息层的这种原子特性，保证了整个协调系统中的节点数据或状态的一致性。Follower基于这种消息协议能够保证本地的ZooKeeper数据与Leader节点同步，然后基于本地的存储来独立地对外提供服务。
• 当一个Leader节点发生故障失效时，失败故障是快速响应的，消息层负责重新选择一个Leader，继续作为协调服务集群的中心，处理客户端写请求，并将ZooKeeper协调系统的数据变更同步（广播）到其他的Follower节点。

ZooKeeper容灾能力

• ZooKeeper能够完成选举即能够正常对外提供服务。ZooKeeper选举时，当某一个实例获得了半数以上的票数时，则变为leader。
• 由此可见，2x+1个节点与2x+2个节点的容灾能力相同（3个与4个相同，5个与6个相同…），而考虑到选举以及完成写操作的速度与节点数的相关性，我们建议ZooKeeper部署奇数个节点。

ZooKeeper读特性

由ZooKeeper的一致性可知，客户端无论连接哪个server，获取的均是同一个视图。所以，读操作可以在客户端与任意节点间完成。

ZooKeeper写特性

1. 同读请求一样，客户端可以向任一server提出写请求。
2. server将这一请求发送给leader。
3. leader获取写请求后，会向所有节点发送这条写请求信息，询问是否能够执行这次写操作。
4. follower节点根据自身情况给出反馈信息ACK应答消息，leader根据反馈信息，若获取到的可以执行写操作的数量大于实例总数的一半，则认为本次写操作可执行。
5. leader将结果反馈给各follower，并完成写操作，各follower节点同步leader的数据，本次写操作完成。

ZooKeeper和HDFS

• ZKFC（ZKFailoverController）作为一个ZooKeeper集群的客户端，用来监控NameNode的状态信息，ZKFC进程仅在部署NameNode的节点中存在。HDFS NameNode的Active和Standby节点均有ZKFC进程。
• Standby NameNode通过ZooKeeper感知Active NameNode的变化。一旦Active NameNode宕机，HDFS就会进行主备切换。
• HDFS NameNode的ZKFC连接到ZooKeeper，把主机名等信息保存到ZooKeeper中，即“/hadoop-ha”下的znode目录里。先创建znode目录的NameNode节点为主节点，另一个为备节点。HDFS NameNode Standby通过ZooKeeper定时读取NameNode信息。
• 当主节点进程异常结束时，HDFS NameNode Standby通过ZooKeeper感知“/hadoop-ha”目录下发生了变化，NameNode会进行主备切换。

ZooKeeper和YARN

• 在系统启动时，ResourceManager会尝试把选举信息写入ZooKeeper，第一个成功把写入ZooKeeper的ResourceManager被选举为Active ResourceManager，另一个为Standby ResourceManager。Standby ResourceManager定时去ZooKeeper监控Active ResourceManager选举信息。
• 一旦Active ResourceManager异常结束，Yarn就会进行主备切换。
• Active ResourceManager还会在ZooKeeper中创建Statestore目录，存储Application相关信息。当Active ResourceManager产生故障时，Standby ResourceManager会从Statestore目录获取Application相关信息，恢复数据并升为Active ResourceManager。

ZooKeeper和HBase

• ZooKeeper要存储HBase元数据、HMaster地址，同时要接受HRegionServer的注册。
• HMaster通过ZooKeeper感知各HRegionServer的健康状况，以便进行控制管理。
• HBase可以部署多对Hmaster实现HA，与HDFS HA 类似。当出现active HMaster 宕机时，HBase可立即实现主备切换。避免HBase单点故障问题。