共计 2450 个字符，预计需要花费 7 分钟才能阅读完成。
一、节点类型二、构造体三、监听器原理四、选举机制 4.1 重要的参数。4.2 选举状态：4.3 服务器启动时的 leader 选举 4.4 运行过程中的 leader 选举
作 者：雨中散步撒哈拉
来 源：https://liudongdong.top
公众号：雨中散步撒哈拉
备 注：欢送关注公众号，学习技术，一起成长！
一、节点类型
image.png
- 长久（Persistent）：客户端和服务器端断开连接后，创立的节点不删除
1.1. 长久化目录节点：客户端与 Zookeeper 断开连接后，该节点仍旧存在
1.2. 长久化程序编号目录节点：客户端与 Zookeeper 断开连接后，该节点仍旧存在，只是 Zookeeper 给该节点名称进行程序编号 - 短暂（Ephemeral）：客户端和服务器端断开连接后，创立的节点本人删除
2.1. 长期目录节点：客户端与 Zookeeper 断开连接后，该节点被删除
2.2. 长期程序编号目录节点：客户端与 Zookeeper 断开连接后，该节点被删除，只是 Zookeeper 给该节点名称进行程序编号。
阐明：创立 znode 时设置程序标识，znode 名称后会附加一个值，顺序号是一个枯燥递增的计数器，由父节点保护
留神：在分布式系统中，顺序号能够被用于为所有的事件进行全局排序，这样客户端能够通过顺序号推断事件的程序
二、构造体
应用 stat 命令，查看节点详细信息
image.png
| cZxid | 创立节点时的事务 ID |
|---|---|
| ctime | 创立节点时的工夫 |
| mZxid | 最初批改节点时的事务 ID |
| mtime | 最初批改节点时的工夫 |
| pZxid | 示意该节点的子节点列表最初一次批改的事务 ID，增加子节点或删除子节点就会影响子节点列表，然而批改子节点的数据内容则不影响该 ID（留神，只有子节点列表变更了才会变更 pzxid，子节点内容变更不会影响 pzxid） |
| cversion | 子节点版本号，子节点每次批改版本号加 1 |
| dataversion | 数据版本号，数据每次批改该版本号加 1 |
| aclversion | 权限版本号，权限每次批改该版本号加 1 |
| ephemeralOwner | 创立该长期节点的会话的 sessionID。（*_如果该节点是长久节点，那么这个属性值为 0）_* |
| dataLength | 该节点的数据长度 |
| numChildren | 该节点领有子节点的数量 （只统计间接子节点的数量） |
三、监听器原理
- 首先要有一个 main() 线程
- 在 main 线程中创立 Zookeeper 客户端，这时就会创立两个线程，一个负责网络连接通信（connet），一个负责监听（listener）。
- 通过 connect 线程将注册的监听事件发送给 Zookeeper。
- 在 Zookeeper 的注册监听器列表中将注册的监听事件增加到列表中。
- Zookeeper 监听到有数据或门路变动，就会将这个音讯发送给 listener 线程。
- listener 线程外部调用了 process() 办法。
image.png
常见的监听:
- 监听节点数据的变动 get path [watch]
- 监听子节点增减的变动 ls path [watch]
四、选举机制
zookeeper 的 leader 选举存在两个阶段，一个是服务器启动时 leader 选举，另一个是运行过程中 leader 服务器宕机。
4.1 重要的参数。
- 服务器 ID(myid)：编号越大在选举算法中权重越大
- 事务 ID(zxid)：值越大阐明数据越新，权重越大
- 逻辑时钟 (epoch-logicalclock)：同一轮投票过程中的逻辑时钟值是雷同的，每投完一次值会减少
4.2 选举状态：
LOOKING: 竞选状态
FOLLOWING: 随从状态，同步 leader 状态，参加投票
OBSERVING: 察看状态，同步 leader 状态，不参加投票
LEADING: 领导者状态
4.3 服务器启动时的 leader 选举
每个节点启动的时候都 LOOKING 张望状态，接下来就开始进行选举主流程。这里选取三台机器组成的集群为例。第一台服务器 server1 启动时，无奈进行 leader 选举，当第二台服务器 server2 启动时，两台机器能够互相通信，进入 leader 选举过程。
image.png
- 每台 server 收回一个投票，因为是初始状况，server1 和 server2 都将本人作为 leader 服务器进行投票，每次投票蕴含所推举的服务器 myid、zxid、epoch，应用（myid，zxid）示意，此时 server1 投票为（1,0），server2 投票为（2,0），而后将各自投票发送给集群中其余机器。
- 接管来自各个服务器的投票。集群中的每个服务器收到投票后，首先判断该投票的有效性，如查看是否是本轮投票（epoch）、是否来自 LOOKING 状态的服务器。
- 别离解决投票。针对每一次投票，服务器都须要将其余服务器的投票和本人的投票进行比照，比照规定如下：
3.1. 优先比拟 epoch
3.2. 查看 zxid，zxid 比拟大的服务器优先作为 leader
3.3. 如果 zxid 雷同，那么就比拟 myid，myid 较大的服务器作为 leader 服务器 - 统计投票。每次投票后，服务器统计投票信息，判断是否有过半机器接管到雷同的投票信息。server1、server2 都统计出集群中有两台机器承受了（2,0）的投票信息，此时曾经选出了 server2 为 leader 节点。
- 扭转服务器状态。一旦确定了 leader，每个服务器响应更新本人的状态，如果是 follower，那么就变更为 FOLLOWING，如果是 Leader，变更为 LEADING。此时 server3 持续启动，间接退出变更本人为 FOLLOWING。
4.4 运行过程中的 leader 选举
当集群中 leader 服务器呈现宕机或者不可用状况时，整个集群无奈对外提供服务，进入新一轮的 leader 选举。
- 变更状态。leader 挂后，其余非 Oberver 服务器将本身服务器状态变更为 LOOKING。
- 每个 server 收回一个投票。在运行期间，每个服务器上 zxid 可能不同。
- 解决投票。规定同启动过程。
- 统计投票。与启动过程雷同。
- 扭转服务器状态。与启动过程雷同。