乐趣区

关于zookeeper:zookeeper结构和选举-雨中散步撒哈拉

jiezi

一、节点类型二、构造体三、监听器原理四、选举机制 4.1 重要的参数。4.2 选举状态：4.3 服务器启动时的 leader 选举 4.4 运行过程中的 leader 选举

作   者：雨中散步撒哈拉
来   源：https://liudongdong.top
公众号：雨中散步撒哈拉
备   注：欢送关注公众号，学习技术，一起成长！

一、节点类型

image.png

  1. 长久（Persistent）：客户端和服务器端断开连接后，创立的节点不删除
    1.1. 长久化目录节点：客户端与 Zookeeper 断开连接后，该节点仍旧存在
    1.2. 长久化程序编号目录节点：客户端与 Zookeeper 断开连接后，该节点仍旧存在，只是 Zookeeper 给该节点名称进行程序编号
  2. 短暂（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 该节点领有子节点的数量 （只统计间接子节点的数量）

三、监听器原理

  1. 首先要有一个 main() 线程
  2. 在 main 线程中创立 Zookeeper 客户端，这时就会创立两个线程，一个负责网络连接通信（connet），一个负责监听（listener）。
  3. 通过 connect 线程将注册的监听事件发送给 Zookeeper。
  4. 在 Zookeeper 的注册监听器列表中将注册的监听事件增加到列表中。
  5. Zookeeper 监听到有数据或门路变动，就会将这个音讯发送给 listener 线程。
  6. listener 线程外部调用了 process() 办法。

image.png

常见的监听:

  1. 监听节点数据的变动 get path [watch]
  2. 监听子节点增减的变动 ls path [watch]

四、选举机制

zookeeper 的 leader 选举存在两个阶段，一个是服务器启动时 leader 选举，另一个是运行过程中 leader 服务器宕机。

4.1 重要的参数。

  1. 服务器 ID(myid)：编号越大在选举算法中权重越大
  2. 事务 ID(zxid)：值越大阐明数据越新，权重越大
  3. 逻辑时钟 (epoch-logicalclock)：同一轮投票过程中的逻辑时钟值是雷同的，每投完一次值会减少

4.2 选举状态：

LOOKING: 竞选状态
FOLLOWING: 随从状态，同步 leader 状态，参加投票
OBSERVING: 察看状态，同步 leader 状态，不参加投票
LEADING: 领导者状态

4.3 服务器启动时的 leader 选举

每个节点启动的时候都 LOOKING 张望状态，接下来就开始进行选举主流程。这里选取三台机器组成的集群为例。第一台服务器 server1 启动时，无奈进行 leader 选举，当第二台服务器 server2 启动时，两台机器能够互相通信，进入 leader 选举过程。

image.png

  1. 每台 server 收回一个投票，因为是初始状况，server1 和 server2 都将本人作为 leader 服务器进行投票，每次投票蕴含所推举的服务器 myid、zxid、epoch，应用（myid，zxid）示意，此时 server1 投票为（1,0），server2 投票为（2,0），而后将各自投票发送给集群中其余机器。
  2. 接管来自各个服务器的投票。集群中的每个服务器收到投票后，首先判断该投票的有效性，如查看是否是本轮投票（epoch）、是否来自 LOOKING 状态的服务器。
  3. 别离解决投票。针对每一次投票，服务器都须要将其余服务器的投票和本人的投票进行比照，比照规定如下：
    3.1. 优先比拟 epoch
    3.2. 查看 zxid，zxid 比拟大的服务器优先作为 leader
    3.3. 如果 zxid 雷同，那么就比拟 myid，myid 较大的服务器作为 leader 服务器
  4. 统计投票。每次投票后，服务器统计投票信息，判断是否有过半机器接管到雷同的投票信息。server1、server2 都统计出集群中有两台机器承受了（2,0）的投票信息，此时曾经选出了 server2 为 leader 节点。
  5. 扭转服务器状态。一旦确定了 leader，每个服务器响应更新本人的状态，如果是 follower，那么就变更为 FOLLOWING，如果是 Leader，变更为 LEADING。此时 server3 持续启动，间接退出变更本人为 FOLLOWING。

4.4 运行过程中的 leader 选举

当集群中 leader 服务器呈现宕机或者不可用状况时，整个集群无奈对外提供服务，进入新一轮的 leader 选举。

  1. 变更状态。leader 挂后，其余非 Oberver 服务器将本身服务器状态变更为 LOOKING。
  2. 每个 server 收回一个投票。在运行期间，每个服务器上 zxid 可能不同。
  3. 解决投票。规定同启动过程。
  4. 统计投票。与启动过程雷同。
  5. 扭转服务器状态。与启动过程雷同。
退出移动版