Zookeeper的那些事

Zookeeper基本概念

Zookeeper是一个开源的分布式协调服务，其设计目标是将那些复杂的且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一些简单的接口提供给用户使用。zookeeper是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据订阅/发布、负载均衡、命名服务、集群管理、分布式锁和分布式队列等功能。

Zookeeper角色

Leader、Follower、Observer三种角色

Zookeeper集群中的所有机器通过Leader选举来选定一台被称为 Leader的机器，Leader服务器为客户端提供读和写服务。除Leader外，其他机器包括Follower和 Observer，Follower和Observer都能提供读服务，唯一的区别在于Observer不参与Leader选举过程， 不参与写操作的过半写成功策略，因此Observe r可以在不影响写性能的情况下提升集群的性能。

客户端发送写请求

一、客户端写请求会随机请求到follower、observer或leader

如果写请求分给follower/observer节点，则将请求转发给leader去处理

leader接收到写请求后，把该写请求转换成带各种状态的事务，将该事务进行广播（发送proposal，类似Paxos算法中的提案Proposal）

所有接收到proposal的follower进行投票，需要向leader返回ACK消息

leader根据follower返回的ACK消息，判断如果大部分节点可以执行事务，则向所有follower和observer发送事务提交操作。follower和observer接收到leader发送来的提交事务的请求后，将事务写到日志中并去完成事务的执行。

二、写请求完成后，谁接收的客户端请求则由谁再将结果返回给客户端。

客户端发送读请求

客户端读请求会随机请求到follower、observer或leader

Observer角色

Observer不参与Leader投票过程，只提供读服务。当Observer接收到leader发送提交事务请求后，会去提交事务，保持数据的一致性。

但是能接收到leader的投票广播。

Observer除了不进行投票外和Follower功能相同。因此observer在不影响写性能的前提下，提高集群性能。

会话（session）

Session指客户端会话，一个客户端连接是指客户端和服务端之间的一个TCP长连接，Zookeeper对外的服务端口默认为2181。客户端启动的时候，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期也开始了，通过这个连接，客户端能够心跳检测与服务器保持有效的会话，也能够向Zookeeper服务器发送请求并接受响应，同时还能够通过该连接接受来自服务器的Watch事件通知。

数据节点（Znode）

Zookeeper中，"节点"分为两类，第一类同样是指构成集群的机器，我们称之为机器节点；第二类则是指数据模型中的数据单元，我们称之为数据节点一一ZNode。

Zookeeper将所有数据存储在内存中，数据模型是一棵树（ZNode Tree），由斜杠（/）进行分割的路径，就是一个Znode,例如/app/path1。每个ZNode上都 会保存自己的数据内容，同时还会保存一系列属性信息。

Zookeeper基本使用

在ZooKeeper中，数据信息被保存在一个个数据节点上，这些节点被称为znode。ZNode是 Zookeeper中最小数据单位，在ZNode下面又可以再挂ZNode,这样一层层下去就形成了一个层次化 命名空间ZNode树，我们称为ZNode Tree,它采用了类似文件系统的层级树状结构进行管理。

ZNode的类型
持久性节点(Persistent)

临时性节点(Ephemeral)

顺序性节点(Sequential)

**持久节点：**是Zookeeper中最常见的一种节点类型，所谓持久节点，就是指节点被创建后会一直存在服 务器，直到删除操作主动清除

**持久顺序节点：**就是有顺序的持久节点，节点特性和持久节点是一样的，只是额外特性表现在顺序上。 顺序特性实质是在创建节点的时候，会在节点名后面加上一个数字后缀，来表示其顺序。

**临时节点：**就是会被自动清理掉的节点，它的生命周期和客户端会话绑在一起，客户端会话结束，节点 会被删除掉。与持久性节点不同的是，临时节点不能创建子节点。

**临时顺序节点：**就是有顺序的临时节点，和持久顺序节点相同，在其创建的时候会在名字后面加上数字 后缀。

事务ID

ZooKeeper中，事务是指能够改变ZooKeeper服务器状态的操作，我们也称之为事务操作或更新操作，一般包括数据节点创建与删除、数据节点内容更新等操作。对于每一个事务请求，ZooKeeper都会为其分配一个全局唯一的事务ID，用ZXID来表示，通常是一个64位的数字。每一个ZXID对应一次更新操作，从这些ZXID中可以间接地识别出ZooKeeper处理这些更新操作请求的全局顺序

ZNode的状态信息

整个ZNode节点内容包括两部分：节点数据内容和节点状态信息。

cZxid 就是 Create ZXID，表示节点被创建时的事务ID。

ctime 就是 Create Time，表示节点创建时间。

mZxid 就是 Modified ZXID，表示节点最后⼀次被修改时的事务ID。

mtime 就是 Modified Time，表示节点最后⼀次被修改的时间。

pZxid 表示该节点的⼦节点列表最后⼀次被修改时的事务 ID。只有⼦节点列表变更才会更新 pZxid，⼦节点内容变更不会更新。

cversion 表示⼦节点的版本号。

dataVersion 表示内容版本号。

aclVersion 标识acl版本

ephemeralOwner 表示创建该临时节点时的会话 sessionID，如果是持久性节点那么值为 0

dataLength 表示数据⻓度。

numChildren 表示直系⼦节点数。

Watcher–数据变更通知

Zookeeper使用Watcher机制实现分布式数据的发布/订阅功能

Zookeeper的Watcher机制主要包括客户端线程、客户端WatcherManager、Zookeeper服务器三部分。

具体工作流程为：客户端在向Zookeeper服务器注册的同时，会将Watcher对象存储在客户端的WatcherManager当中。当Zookeeper服务器触发Watcher事件后，会向客户端发送通知，客户端线程从WatcherManager中取出对应的Watcher对象来执行回调逻辑。

ACL–保障数据的安全

如何保障系统中数据的安全，从而避免因误操作所带来的数据随意变更，而导致的数据库异常十分重要，在Zookeeper中，提供了一套完善的 ACL (Access Control List)权限控制机制来保障数据的安全。

我们可以从三个方面来理解ACL机制：权限模式(Scheme)、授权对象(ID)、权限(Permission)，通常使用"scheme: id:permission"来标识一个有效的ACL信息。

四种模式：

IP
Digest
Wordld
Super

Zookeeper应用场景

数据发布/订阅

命名服务

集群管理

分布式日志收集系统

Master选举

分布式锁

排他锁

共享锁

羊群效应

分布式队列

Zookeeper的leader选举

进行leader选举有两种情况：

1. 服务器启动时。
2. 服务器运行期间无法与leader保持连接。
   1.服务器启动时leader选举
   若要进行选举，必须要有超过2台以上的服务器，这里以3台服务器组成的集群为例。

服务器server1启动时，其单独无法完成选举。当服务器server2启动时，两台服务器进行通信，都试图找到leader，于是进入leader选举。过程如下：

（1）每个server发送一个投票
由于是初始化，每个服务器将自己作为leader来进行投票。每次投票都包含（myid，ZXID）（服务器指定id，事务id），server1的投票信息为（1，0），server2的投票信息为（2，0），然后各自将投票信息发送给其他服务器。

（2）接收各个服务器的投票
集群的每个服务器接收投票后，对投票信息进行有效性验证，如检查是否本轮投票，是否来自LOOKING状态的服务器。

（3）处理投票
优先检查ZXID，ZXID大的服务器优先作为leader。

如果ZXID相同，那么比较myid，myid大的服务器作为leader服务器。

（4）统计投票
每次投票后服务器都会统计所有投票，判断是否有过半服务器收到相同的投票信息。所谓过半是指，大于集群中服务器一半的数量，要大于等于（n/2+1）。

（5）改变服务器状态
一旦确定了leader，每个服务器会更新自己的状态。如果是leader，改为LEADING；如果是follower，那么改为FOLLOWING。

2.服务器运行时期的leader选举
在ZooKeeper集群正常运行过程中，一旦选出一个Leader，那么所有服务器的集群角色一般不会再发生变化。也就是说，Leader服务器将一直作为集群的Leader，即使集群中有非Leader机器挂了，或是有新机器加入集群也不会影响Leader。

但是一旦Leader所在的机器挂了，那么整个集群将暂时无法对外服务，而是进入新一轮的Leader选举。服务器运行期间的Leader选举，和启动时期的Leader选举基本过程是一致的。

（1）变更状态

leader挂掉后，余下的非observer服务器都会将自己标记为looking状态，然后进入leader选举。

（2）每个server发出一个投票

各服务器都会为自己一票。既将投自己的票发送给集群中其他服务器。

（3）接收来自各个服务器的投票，与启动时过程相同

（4）处理投票。与启动时过程相同，此时，Server 1将会成为Leader

（5） 统计投票。与启动时过程相同

（6）改变服务器的状态。与启动时过程相同

直播总结的那些事

• ZAB 协议通过主备模式来保证最终一致性；
• leader 的周期 epoch，通过周期编号来区分 leader。以 raft 协议为例，编号小的 leader 会转为 Follower，听从编号大的 leader；
• 自定义配置中心 SpringBootBean
• zk 伪集群的缺点，一台机器多个 zk，所以存在单点故障问题；
• zk 命名服务保证唯一性，通过调用 zk 创建节点的 API 来创建一个顺序节点，并且在 API 返回时返回这个节点的完成名称。该名称是一个带序号后缀的，利用这个特性可生成全局唯一 ID，即通过创建顺序节点可保证唯一性；
• zk 为什么要奇数台部署；
  1. 防止由脑裂造成的集群不可用；
  2. 在容错能力相同的情况下，奇数台更省资源。
• zk 分布式锁和 redis 分布式锁的应用场景；
  1. zk 分布式锁适合性能较低、不需要高并发的场景；
  2. 性能高且高并发的场景，使用 redis 分布式锁。
• Observer 可手动配置，指定哪个节点称为 Observer；
• zk 监听节点是通过定时轮询检查达到监听目的；
• zk 负载均衡和 nginx 负载均衡对比；
  1. zk 不存在单点故障问题，可重新选举 leader，进行负载均衡；
  2. zk 要实现负载均衡算法，nginx 自带负载均衡算法。
• Curator 和 ZkClient 对比，Curator 用的多，满足基本开发需求，可用性更强；
• redis 可做服务发向，但通常推荐使用 zk。