ZooKeeper
发自简书
- ZooKeeper定义
- ZooKeeper在产品的位置
- 系统架构
- 关键特性介绍
- 与组件的关系
1、Zookeeper定义
Zookeeper 分布式服务框架主要是用来解决分布式应用中经常遇到的一些数据管理问题，提供分布式、高可用性的协调服务能力,在FusionInsight集群中主要用途是保存上层组件的元数据，并保证其主备倒换。
2、ZooKeeper在产品的位置
3、ZooKeeper服务架构
模型
1.分布式地分布在一组机器中
2.所有节点存储整份数据（在内存也在硬盘）
3.在启动时候选举出Leader
4.Leader会做原子广播到所有其他节
5.严格的顺序访问控制6.不会部分读写
容灾能力
一般情况下，ZooKeeper能够完成选举即能够正常对外提供服务。
ZooKeeper选举时，当某一个实例获得了半数以上的票数时，则变为
leader。
对于n个实例的服务，n可能为奇数或偶数
n为奇数时，假定n=2x+1，则成为leader的节点需获得x+1票，容灾能
力为x
n为偶数时，假定n=2x+2，则成为leader的节点需要获得x+2票（大于一半），容灾能力为x。
由此可见，2x+1个节点与2x+2个节点的容灾能力相同（3个与4个相同，5
个与6个相同…），而考虑到选举以及完成写操作的速度与节点数的相关性，我们建议ZooKeeper部署奇数个节点。
ZooKeeper数据模型
- 分层命名空间
- 每个命名空间的节点都叫做“znode”
- 每个znode被路径区分（如：/app1）
- znode节点类型– 永久节点和临时节
点
5.临时节点不能有子节点
6.每个znode节点有数据，也可以选择
有子节点 - znode不能被重命名
-
可以给znode增加或者删除watchers
4、关键特性
最终一致性：无论哪个server，对外展示的均是同一个视图。
实时性：保证客户端将在一个时间间隔范围内获得服务器的更新信息，或
者服务器失效的信息。
可靠性：一条消息被一个server接收，它将被所有server接受。
等待无关性：慢的或者失效的client不得干预快速的client的请求，使得每
个client都能有效的等待。
原子性：更新只能成功或者失败，没有中间状态。
顺序性：客户端的更新顺序与它们被发送的顺序相一致。
读特性
由ZooKeeper的一致性可知，客户端无论连接哪个server，获取的均是同一个视图。所以，读操作可以在客户端与任意节点间完成。
写特性
ACL（访问控制列表）
ACL可以控制访问ZooKeeper的节点，只能应用于特定的znode上，而不能应用于该znode的所有子节点上。设置ACL命令为 setAcl /znode scheme:id:perm
Scheme为认证方式， ZooKeeper内置了4种方式：
world 一个单独的ID，表示任何人都可以访问
auth 不使用ID，只有认证的用户可以访问
digest 使用username:password生成MD5哈希值作为认证ID
IP 使用客户端主机IP地址来进行认证
Id：用来认证的字段，用来判断认证信息是否合法，不同的scheme的认证方式不同。
Perm：即permission，通过Acl认证的用户对该节点可拥有的操作权限
日志增强
Ephemeral node（临时节点）在session过期之后就会被系统删除，
在审计日志中添加Ephemeral node被删除的审计日志，以便了解
当时Ephemeral node的状态信息。
客户端常用命令使用
调用ZooKeeper客户端，执行命令：
sh zkCli.sh –server 172.0.0.1:24002
执行创建节点，设置ACL，查询ACL，查询节点值，删除节点操作。
创建节点：create /node
获取节点子节点： ls /node
设置Acl：setAcl /node sasl:admin@HADOOP.COM:cdrwa
查询节点Acl： getAcl /node
创建节点数据: set /node data
获取节点数据: get /node
删除节点：delete /node
删除节点及所有子节点: deleteall /node
5、与组件的关系
ZooKeeper和Storm Nimbus HA的配合关系
Storm Nimbus利用zookeeper来选主。ZooKeeper提供了以下两种能力：
分布式锁服务多个Nimbus进程都尝试着去ZooKeeper中写入一个对应的节点，该节点只能被一个Nimbus进程创建成功，创建成功的Nimbus进程成为主Nimbus。
事件侦听机制--watcher。 备Nimbus在侦听那个对应的ZooKeeper节点。主Nimbus进程宕掉之后，该节点会被删除，那么，备Nimbus就可以收到相应的消息。
ZooKeeper和HDFS的配合关系
ZKFC（ZKFailoverController）作为一个ZooKeeper集群的客户端，用来监控NameNode的状态信息。ZKFC进程仅在部署了NameNode的节点中存在。HDFS
NameNode的Active和Standby节点均部署有zkfc进程：
HDFS NameNode的ZKFC连接到ZooKeeper，把主机名等信息保存到ZooKeeper中，即“/hadoop-ha”下的znode目录里。先创建znode目录的NameNode节点为主节点，另一个为备节点。HDFS NameNode Standby通过ZooKeeper定时读取NameNode信息。
当主节点进程异常结束时，HDFS NameNode Standby通过ZooKeeper感知“/hadoop-ha”目录下发生了变化。
ZooKeeper和YARN的配合关系
在系统启动时，ResourceManager会尝试把选举信息写入ZooKeeper，第一个成功把写入ZooKeeper的ResourceManager被选举为Active
ResourceManager，另一个为StandbResourceManager。Standby
ResourceManager定时去ZooKeeper监控Active ResourceManager选举信息。
Active ResourceManager还会在ZooKeeper中创建Statestore目录，存储Application相关信息。当Active ResourceManager产生故障时，Standby ResourceManager会从Statestore目录获取Application相关信息，恢复数据并升为Active。
ZooKeeper和HBase的配合关系
HRegionServer把自己以Ephemeral方式注册到ZooKeeper中。其中ZooKeeper存储HBase的如下信息：HBase元数据、HMaster地址。 HMaster通过ZooKeeper随时感知各个HRegionServer的健康状况，以便进行控制管理。
HBase也可以部署多对HMaster类似HDFS NameNode，当HMaster主节点出现故障时，HMaster备用节点会通过ZooKeeper获取主HMaster存储的整个HBase集群状态信息。即通过ZooKeeper实现避免HBase单点故障问题。
思考
1 ZooKeeper在集群中的位置及作用是什么？
2 ZooKeeper节点结构是什么样子？节点类型有哪些？
3 ZooKeeper为什么建议奇数部署？
4 ZooKeeper一致性的含义是什么？
