Zookeeper简介

Zookeeper简介

Zookeeper是一个开源的分布式协调服务，它是集群的管理者，监视着集群中各个节点的状态。根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效，功能稳定的系统提供给用户。

分布式应用程序可基于Zookeeper实现诸如数据发布/订阅，负载均衡，命名服务，分布式协调/通知，集群管理，Master选举，分布式锁和分布式队列等功能

客户端的读请求可以被集群中的任意一台机器处理，如果读请求在节点上注册了监听器，这个监听器也是由所连接的zookeeper机器来处理。对于写请求，这些请求会同时发给其他zookeeper机器并且达成一致后，请求才会返回成功。因此，随着zookeeper的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。

有序性是zookeeper中非常重要的一个特性，所有的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为zxid（Zookeeper Transaction Id）。而读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个zookeeper最新的zxid。

1.Zookeeper角色

Zookeeper 集群是一个基于主从复制的高可用集群，每个服务器承担如下三种角色中的一种

1>Leader

• 一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各个Follower及Observer间的心跳
• 所有的写操作必须要通过Leader完成，再由Leader将写操作广播给其他服务器。只要有超过半数节点（不包括Observer节点）写入成功，该写请求就会被提交

2>Follower

• 一个Zookeeper集群中可能同时存在多个Follower，它会响应Leader的心跳
• Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理
• 并且在Leader处理写请求时对请求进行投票

3>Observer

角色与Follower相似，但没有投票权。Zookeeper需保证高可用和强一致性，为了支持更多的客户端，需要增加更多Server；Server增多，投票阶段延迟增大，影响性能；引入Observer节点，Observer不参与投票；Observer接受客户端的连接，并将写请求转发给Leader节点；加入更多Observer节点，提高伸缩性，同时不影响吞吐率。

2.ZAB协议

事务编号zxid（事务请求计数器+epoch）：
在ZAB（Zookeeper Atomic Broadcast，ZooKeeper原子广播协议）协议的事务编号zxid的设计中，zxid是一个64位的数字，其中低32位是一个简单的单调递增的计数器，针对客户端每一个事务请求，计数器+1；而高32位代表Leader周期epoch编号，每当选举产生一个新的Leader服务器，就会从这个Leader服务器上取出其本地日志最大的zxid，并从中读取epoch值，然后+1，以此作为新的epoch，并将低32位从0开始计数。
zxid，用于标识一次更新操作的Proposal（提议ID）。为了保证顺序性，该zxid必须单调递增

ZAB协议有两种模式：恢复模式（选主），广播模式（同步）：
当服务启动或者Leader宕机后，ZAB就进入了恢复模式；当Leader被选举出来，且绝大多数Server完成了和Leader的状态同步后，恢复模式就结束了。状态同步保证了Server和Leader具有相同的系统状态

ZAB协议4阶段：

• 1.Leader Election（选举阶段，选出准Leader）
  节点在一开始都处于选举阶段，只要有一个节点得到超过半数节点的票数，它就可以当选准Leader。只有到达广播阶段（Broadcast），准Leader才会成为真正的Leader。
• 2.Discovery（发现阶段，生成epoch，接受epoch）
  在这个阶段，Followers与准Leader进行通信，同步Followers最近接收的事务提议。这一个阶段的主要目的是发现当前大多数节点接收的最新提议，并且准Leader生成新的epoch，让Followers接受，更新它们的accepted Epoch。
  一个Follower只会连接一个Leader，如果一个节点f任务另一个Follower p是Leader，f在尝试连接p时会被拒绝，f被拒绝之后就会进入重新选举阶段
• 3.Synchronization（同步阶段，同步Follower副本）
  同步阶段主要是利用Leader前一阶段获得的最新提议历史，同步集群中所有的副本。只有当大多数节点都同步完成，准Leader才会成为真正的Leader。Follower只接受zxid比自己的lastZxid大的提议
• 4.Broadcast（广播阶段，Leader消息广播）
  到了这个阶段，Zookeeper集群才能正式对外提供事务服务，并且Leader可以进行事务广播。同时如果有新的节点加入，还需要对新节点进行同步

ZAB提交事务不像2PC一样需要全部Follower都ACK，只需要得到超过半数节点的ACK就可以了

ZAB协议的JAVA实现（发现阶段和同步阶段合并成恢复阶段），所以ZAB的实现只有三个阶段：Fast Leader Election；Recovery Phase；Broadcast Phase

3.投票机制

每个Server首先给自己投票，然后用自己的选票和其他Server对比，权重大的胜出，使用权重更大的更新自身选票箱，具体选举过程如下：

• 1.每个Server启动后都询问其他的Server投票给谁。对于其他Server的询问，Server每次根据自己的状态都回复自己推荐的Leader的id和上一次处理事务的zxid（系统启动时每个Server会推荐自己）
• 2.收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server
• 3.计算这过程中获得选票最大的Server为获胜者，如果获胜者的票数超过半数，则改Server为Leader。否则继续这个过程，直到Leader被选举出来。
• 4.Leader会开始等待Server连接
• 5.Follower连接Leader，将最大的zxid发送给Leader
• 6.Leader根据Follower的zxid确定同步点，至此选举阶段完成
• 7.选举阶段完成Leader同步后通知Follower已经成为Update状态
• 8.Follower收到Update消息后，又可以重新接受Client的请求进行服务了

例子：

4.Zookeeper文件系统

Zookeeper的命名空间就是Zookeeper应用的文件系统，它和Linux文件系统很像，也是树状，这样就可以确定每个路径都是唯一的。对于命名空间的操作必须都是绝对路径。但Linux文件系统有目录和文件的区别，而Zookeeper统一叫znode，一个znode既可以包含子znode，也可以包含数据，但只能存储小于1M的数据。

znode在类型上分为4种：

1. PERSISTENT：持久的节点。
2. EPHEMERAL：暂时的节点。
3. PERSISTENT_SEQUENTIAL：持久化顺序编号目录节点。
4. EPHEMERAL_SEQUENTIAL：暂时化顺序编号目录节点。

相关命令：

//1.查看目录(指定znode下的子znode)
ls /

//2.查看目录内容(znode种存储的数据)
get /config

//3.创建znode
create /config/test abc

delete path [version] #删除目录，但是只能删除没有子目录的
rmr path # 什么都可以删除
get path [watch] # 获取信息
create [-s] [-e] path data acl # 创建目录
quit # 退出当前的shell