为什么选用Zookeeper？观察者-选举图文梳理

本文链接：https://blog.csdn.net/qq_41858479/article/details/121945045

从毕业到现在，已经进入工作岗位多半年了，在这半年中我一直在想通过公司的实际业务场景使用分布式的一些组件，然后带着一些使用的疑问去打通原理与实际业务场景。

一个系统不可能是单纯的一个服务，而是多个服务相互依赖，只要存在依赖关系就难免会出现远程过程调用RPC,在远程过程调用的过程中最为重要的 “分布式协调/通知”，配合dubbo组件或者其他RPC方案完成调用，所以使用到zookeeper。而对于我理解的zk来说犹如千呼万唤始出来，犹抱琵琶半遮面的感觉，因此我在这里整理一下，方便自己的同时也方便大家。

Zookeeper工作机制以及存储结构

它负责存储和管理数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。其实就是利用临时节点/持久节点和监听特性等特性完成一系列业务操作。

数据存储结构是依据数据接结构中的数，整体上是一棵树，每个节点称做一个 ZNode。每一个 ZNode 默认能够存储 1MB 的数据，每个 ZNode 都可以通过其路径唯一标识。

在下载安装完成之后，zookeeper中最重要的一个文件就是zoo.cfg 配置文件，在这个配置文件中存在一些重要的参数配置信息。

tickTime = 2000：通信心跳时间，Zookeeper服务器与客户端心跳时间，单位毫秒。
initLimit = 10：LF初始通信时限，Leader和Follower初始连接时能容忍的最多心跳数（tickTime的数量）
dataDir：保存Zookeeper中的数据
clientPort = 2181：客户端连接端口，通常不做修改。

客户端命令行操作

help	显示所有操作命令
ls path	使用 ls 命令来查看当前 znode 的子节点 [可监听] -w 监听子节点变化 -s 附加次级信息
create	普通创建 -s 含有序列 -e 临时（重启或者超时消失）
get path	获得节点的值 [可监听] -w 监听节点内容变化 -w 监听节点内容变化
set	设置节点的具体值
stat	查看节点状态
delete	删除节点
deleteall	递归删除节点0..0010

当键入 ls -s / 在之后，可以看到节点的一些详细信息，具体描述如下:

czxid：创建节点的事务 zxid 。每次修改 ZooKeeper 状态都会产生一个 ZooKeeper 事务 ID。事务 ID 是 ZooKeeper 中所有修改总的次序。每次修改都有唯一的 zxid，如果 zxid1 小于 zxid2，那么 zxid1 在 zxid2 之前发生。
ctime：znode 被创建的毫秒数（从 1970 年开始）
mzxid：znode 最后更新的事务 zxid
mtime：znode 最后修改的毫秒数（从 1970 年开始）
pZxid：znode 最后更新的子节点 zxid
cversion：znode 子节点变化号，znode 子节点修改次数
dataversion：znode 数据变化号
aclVersion：znode 访问控制列表的变化号
ephemeralOwner：如果是临时节点，这个是 znode 拥有者的 session id。如果不是临时节点则是 0。
dataLength：znode 的数据长度
dataLength：znode 的数据长度

Zookeeper特点

Zookeeper：一个领导者（Leader），多个跟随者（Follower）组成的集群。
集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。所以Zookeeper适合安装奇数台服务器。
全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。
更新请求顺序执行，来自同一个Client的更新请求按其发送顺序依次执行。
数据更新原子性，一次数据更新要么成功，要么失败。
实时性，在一定时间范围内，Client能读到最新数据。

Zookeeper特点的存在的疑问

SID：服务器ID。用来唯一标识一台 ZooKeeper集群中的机器，每台机器不能重复，和myid一致。
ZXID：事务ID。ZXID是一个事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关。
Epoch：每个Leader任期的代号。没有 Leader时同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加

1.领导者和跟随着是如何选出来的？【源码使用ZAB 算法实现，下面只是陈述过程】

情景一：第一次启动

1. service1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为 LOOKING（等待半数值）。

2. service2启动，再发起一次选举。service2投自己一票，然后与service1交换选票信息：此时服务器1发现服务器2的myid比自己目前投票推举的（服务器1）大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING

3. service3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；

4. service4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为 1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；

5. service5启动，同4一样当小弟。从此就按照现在选举出来的方案完成相关业务。

情景二：非第一次启动

1. 当ZooKeeper集群中的一台服务器出现以下两种情况之一时，就会开始进入Leader选举：

服务器初始化启动。
服务器运行期间无法和Leader保持连接。【超时、leader宕机等】

2. 当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态：

集群中本来就已经存在一个Leader。对于第一种已经存在Leader的情况，机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可。
集群中确实不存在Leader。按照规则选举： ①EPOCH大的直接胜出 ②EPOCH相同，事务id大的胜出 ③事务id相同，服务器id大的胜出。也就是上面所描述的（EPOCH，ZXID，SID ）

例如：假设ZooKeeper由5台服务器组成，SID分别为1、2、3、4、5，ZXID分别为8、8、8、7、7，并且此时SID为3的服务器是Leader。某一时刻， 3和5服务器出现故障，因此开始进行Leader选举。