zookeeper介绍

ZooKeeper集群分布式协调服务
1.ZooKeeper概述
1.1.ZooKeeper分布式服务框架主要是用来解决分布式应用中经常遇到的一些数据管理问题，提供分布式、高可用性的协调服务能力。
1.2.安全模式下ZooKeeper依赖于Kerberos和LdapServer进行安全认证，非安全模式则不依赖于Kerberos与Ldap。ZooKeeper作为底层组件广泛被上层组件使用并依赖，如Kafka，HDFS，HBase，Storm等。
1.3.在FusionInsight集群中主要用途是保存上层组件的元数据，并保证其主备倒换。
2.ZooKeeper简介
2.1.ZooKeeper基于开源Apache ZooKeeper作为底层组件为上层组件提供服务,主要用于解决分布式应用中经常遇到的一些数据管理问题。
3.ZooKeeper在FusionInsight中的位置
3.1.ZooKeeper基于开源Apache ZooKeeper作为底层组件为上层组件提供服务,主要用于解决分布式应用中经常遇到的一些数据管理问题
4.ZooKeeper服务架构 - 模型
4.1.ZooKeeper集群由一组Server节点组成，这一组Server节点中只存在一个Leader的节点，其他节点都为Follower。
4.2.启动时选举出leader。
4.3.ZooKeeper使用自定义的原子消息协议，保证了整个系统中的节点数据的一致性。
4.4.Leader节点在接收到数据变更请求后，先写磁盘再写内存。
4.5.ZooKeeper集群由一组Server节点组成，这一组Server节点中存在一个角色为Leader的节点，其他节点都为Follower。当客户端Client连接到ZooKeeper集群，并且执行写请求时，这些请求会被发送到Leader节点上，然后Leader节点上数据变更会同步到集群中其他的Follower节点。
4.6.Leader节点在接收到数据变更请求后，首先将变更写入本地磁盘，以作恢复之用。当所有的写请求持久化到磁盘以后，才会将变更应用到内存中。
4.7.ZooKeeper使用了一种自定义的原子消息协议（ZooKeeper Atomic Broadcast Zab协议），在消息层的这种原子特性，保证了整个协调系统中的节点数据或状态的一致性。Follower基于这种消息协议能够保证本地的ZooKeeper数据与Leader节点同步，然后基于本地的存储来独立地对外提供服务。
4.8.当一个Leader节点发生故障失效时，失败故障是快速响应的，消息层负责重新选择一个Leader，继续作为协调服务集群的中心，处理客户端写请求，并将ZooKeeper协调系统的数据变更同步（广播）到其他的Follower节点。
5.ZooKeeper服务架构 - 容灾能力
5.1.ZooKeeper能够完成选举即能够正常对外提供服务。
5.2.ZooKeeper选举时，当某一个实例获得了半数以上的票数时，则变为leader。
5.3.对于n个实例的服务，n可能为奇数或偶数。
5.4.n为奇数时，假定 ，则成为leader的节点需获得x+1票，容灾能力为x。
5.5.n为偶数时，假定 ，则成为leader的节点需要获得x+2票（大于一半），容灾能力为x。
5.6.由此可见，2x+1个节点与2x+2个节点的容灾能力相同（3个与4个相同，5个与6个相同…），而考虑到选举以及完成写操作的速度与节点数的相关性，我们建议ZooKeeper部署奇数个节点。
6.ZooKeeper关键特性
6.1.最终一致性：无论哪个server，对外展示的均是同一个视图。
6.2.实时性：保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。
6.3.可靠性：一条消息被一个server接收，它将被所有server接受。
6.4.等待无关性：慢的或者失效的client不会干预快速的client的请求，使得每个client都能有效的等待。
6.5.原子性：更新只能成功或者失败，没有中间状态。
6.6.顺序一致性：客户端所发送的更新会按照它们被发送的顺序进行应用。
7.ZooKeeper写特性
7.1.1.同读请求一样，客户端可以向任一server提出写请求。
7.2.2.server将这一请求发送给leader。
7.3.3.leader获取写请求后，会向所有节点发送这条写请求信息，询问是否能够执行这次写操作。
7.4.4.follower节点根据自身情况给出反馈信息ACK应答消息，leader根据反馈信息，若获取到的可以执行写操作的数量大于实例总数的一半，则认为本次写操作可执行。
7.5.5.leader将结果反馈给各follower，并完成写操作，各follower节点同步leader的数据，本次写操作完成。
8.ZooKeeper读特性
8.1.由ZooKeeper的一致性可知，客户端无论连接哪个server，获取的均是同一个视图。所以，读操作可以在客户端与任意节点间完成。
9.ACL (访问控制列表)
9.1.ACL可以控制访问ZooKeeper的节点，只能应用于特定的znode上，而不能应用于该znode的所有子节点上。设置ACL命令为 setAcl /znodescheme🆔perm。
9.2.Scheme为认证方式， ZooKeeper内置了4种方式：
9.3.world 一个单独的ID，表示任何人都可以访问。
9.4.auth 不使用ID，只有认证的用户可以访问
9.5.digest 使用username:password生成MD5哈希值作为认证ID。
9.6.IP 使用客户端主机IP地址来进行认证。
9.7.Id：用来认证的字段，不同的scheme的认证方式不同。
9.8.Perm：即permission，通过Acl认证的用户对该节点可拥有的操作权限。
9.9.对zk目录/spark设置ACL，用户可以访问/spark，但不可访问/spark子目录/spark/consumer。
9.10.在对节点进行操作时，只有通过节点ACL认证的用户才能访问该节点并对其进行操作。可以使getAcl命令来查询一个节点的Acl信息。
9.11.ZooKeeper 中的目录节点权限(znode 权限)不具有传递性，父目录节点的权限不能传递给子目录节点。
9.12.当前最为常用的ACL认证方式为sasl方式（一种依赖于kerberos的认证方式，在非安全环境中不能使用。），是ZooKeeper服务端通过记录登录用户的认证信息作为scheme来设置节点的ACL的一种方式。
9.13.例如：setAcl /znode sasl:admin@HADOOP.COM:cdrwa。
9.14.perm 有 ALL、READ、WRITE、CREATE、DELETE、ADMIN 几种。
10.日志增强
10.1.Ephemeral node（临时节点）在session过期之后就会被系统删除。在审计日志中添加Ephemeral node被删除的审计日志，以便了解当时Ephemeral node的状态信息。
12.ZooKeeper和Streaming
12.1.Streaming利用ZooKeeper实现Nimbus的主备。其中ZooKeeper提供了2种服务：
12.2.分布式锁服务
12.3.多个Nimbus进程都会尝试去ZooKeeper创建对应的节点，该节点只能被一个Nimbus进程创建成功，创建 成功的Nimbus进程成为主Nimbus。
12.4.事件侦听机制—watcher
12.5.备Nimbus侦听对应的ZooKeeper节点。主Nimbus进程宕掉之后，该节点会被删除，那么，备Nimbus就可以收到相应的消息。
13.ZooKeeper和HDFS
13.1.ZKFC（ZKFailoverController）作为一个ZooKeeper集群的客户端，用来监控NameNode的状态信息，ZKFC进程仅在部署NameNode的节点中存在。HDFS NameNode的Active和Standby节点均有ZKFC进程。
13.2.Standby NameNode通过ZooKeeper感知Active NameNode的变化。一旦Active NameNode宕机，HDFS就会进行主备切换。
13.3.HDFS NameNode的ZKFC连接到ZooKeeper，把主机名等信息保存到ZooKeeper中，即“/hadoop-ha”下的znode目录里。先创建znode目录的NameNode节点为主节点，另一个为备节点。HDFS NameNode Standby通过ZooKeeper定时读取NameNode信息。
13.4.当主节点进程异常结束时，HDFS NameNode Standby通过ZooKeeper感知“/hadoop-ha”目录下发生了变化，NameNode会进行主备切换。
13.5.图中，实线为写入操作，虚线为监控操作。
14.ZooKeeper和YARN
14.1.在系统启动时，ResourceManager会尝试把选举信息写入ZooKeeper，第一个成功把写入ZooKeeper的ResourceManager被选举为Active ResourceManager，另一个为Standby ResourceManager。Standby ResourceManager定时去ZooKeeper监控Active ResourceManager选举信息。
14.2.一旦Active ResourceManager异常结束，Yarn就会进行主备切换。
14.3.Active ResourceManager还会在ZooKeeper中创建Statestore目录，存储Application相关信息。当Active ResourceManager产生故障时，Standby ResourceManager会从Statestore目录获取Application相关信息，恢复数据并升为Active ResourceManager。
14.4.图中，实线写入，虚线监控。
15.ZooKeeper和HBase
15.1.ZooKeeper要存储HBase元数据、HMaster地址，同时要接受HRegionServer的注册。
15.2.HMaster通过ZooKeeper感知各HRegionServer的健康状况，以便进行控制管理。
15.3.HBase可以部署多对Hmaster实现HA，与HDFS HA 类似。当出现active HMaster 宕机时，HBase可立即实现主备切换。避免HBase单点故障问题。
15.4.多对HMaster是指启用HBase 多实例（HBase1,HBase2… …）特性。