546、Zookeeper详细入门教程系列 -【Zookeeper内部原理】 2022.11.06
目录
-
- 一、Zookeeper内部原理
-
- 1.1 节点类型（Znode）
- 1.2 Stat结构体
- 1.3 监听器原理
- 1.4 选举机制
- 1.5 写数据流程
- 二、最后
- 三、参考链接
一、Zookeeper内部原理
1.1 节点类型（Znode）
持久：客户端和服务器断开后，创建的节点不删除。
1）普通持久节点
2）带序号的持久节点（序号zookeeper自己维护）
短暂：客户端和服务器断开连接后，创建的节点自己删除。
1）普通短暂节点
2）带序号的短暂节点（序号zookeeper自己维护）
1.2 Stat结构体
描述每个ZNode的状态信息
[zk: localhost:2181(CONNECTED) 12] stat /zookeeper
cZxid = 0x0
ctime = Thu Jan 01 08:00:00 CST 1970
mZxid = 0x0
mtime = Thu Jan 01 08:00:00 CST 1970
pZxid = 0x0
cversion = -2
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 0
numChildren = 2
（1）czxid-创建节点的事务zxid
每次修改ZooKeeper状态都会收到一个zxid形式的时间戳，也就是ZooKeeper事务ID。
事务ID是ZooKeeper中所有修改总的次序。每个修改都有唯一的zxid，如果zxid1小于zxid2，那么zxid1在zxid2之前发生。
（2）ctime - znode被创建的毫秒数(从1970年开始)
（3）mzxid - znode最后更新的事务zxid
（4）mtime - znode最后修改的毫秒数(从1970年开始)
（5）pZxid-znode最后更新的子节点zxid
（6）cversion - znode子节点变化号，znode子节点修改次数
（7）dataversion - znode数据变化号
（8）aclVersion - znode访问控制列表的变化号
（9）ephemeralOwner- 如果是临时节点，这个是znode拥有者的session id。如果不是临时节点则是0。
（10）dataLength- znode的数据长度
（11）numChildren - znode子节点数量
1.3 监听器原理
1、原理
首先要有一个main（）线程
在main线程中创建zookeeper客户端，这时就会创建两个线程，一个负责网络连接通信（connect），一个负责监听（listener）
通过connect线程将注册的监听事件发送给zookeeper
在zookeeper的注册监听列表中将注册的监听事件添加到列表中
zookeeper监听到有数据或路径变化，就会把这个消息发送
listener线程内部调用了process（）方法
2、常见的监听
监听节点数据的变化：get path
监听子节点增减的变化：ls path
1.4 选举机制
1.4.1 ZAB协议：
ZAB 协议是为分布式协调服务 zookeeper 专门设计的一种支持崩溃恢复的原子广播协议。ZAB 协议包括两种基本的模式：崩溃恢复 和 消息广播。
当集群刚启动时，会先选举 leader。然后集群中的 follower 服务器开始与新的 leader 服务器进行数据同步，当集群中超过一般机器与该 leader 服务器完成数据同步之后，推出恢复模式到广播模式。此时开始接收客户端的消息处理。
基于消息传递且保证数据一致性的一种算法（协议）
协议目标：
1、没有leader的情况下选举leader
2、有leader的情况，去尽可能保证数据一致。
1.4.2 zj集群
（1）半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。
（2）Zookeeper 虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。
1.4.3 机制概念
1、Serverid： 服务器id
比如有三台服务器，编号分别是1，2，3
2、Zxid：数据ID
服务器中存放的最大数据ID ：值越大说明数据越新，在选举算法中数据越新权重越大。
3、Epoch：逻辑时钟
或者叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到返回的投票信息的数值相比，根据不同的值做出不同的判断。
4、Server状态：选举状态
- LOOKing：竞选
- FOLLOWING：随从状态
- OBSERVING：观察状态，
- LESDING：领导者状态。
1.4.4选举过程
假设有五台服务器组成的Zookeeper 集群，它们的id从1-5 ，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这点上，都是一样的。
投票原则：
自私原则（服务器刚注册的时候都会投自己一票）
墙头草随风倒原则：（发现有其他服务器比自己厉害，就投其他服务器）比较的东西可以为zxid 时间戳，哪个服务器有最新的数据就投它。
过程：
（1）服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING；
（2）服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的ID比自己目前投票推举的（服务器1）大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING
（3）服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；
（4）服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；
（5）服务器5启动，同4一样当小弟。
1.4.5 leader故障后选举
当集群工作中，leader故障后，只要剩下的机器数大于半数，集群能够正常工作，但是需要重新选举leader。选举的过程还是进行投票，因为集群是在工作中，因此每台机器的id有可能不同。那么每次投出的票（myid，zxid），先比较zxid，再比较myid，因此集群中剩余的机器中zxid最大的当选leader，如果zxid都一样，理论情况下myid最大的胜出。
zxid 时间戳，最新的数据。某种意义上，可以表示当前机器中存储的数据完整度。
1.5 写数据流程
1）客户端连接zk集群的任意一台机器，发送写请求
2）如果客户端连接的zk集群部署leader，则当前这台机器会将客户端的写请求转发给leadet
3）当leader接收到写请求后，会将当次的写操作构造成一个事务，对应一个zxid
4）每个follower接收到写操作后，先将写操作存入队列中，并向leader反馈
5）当leader接收到集群中半数以上的follower的反馈，则代表本次写操作可以正常进行，
leader会再次广播给各个follower，让follower将写操作进行commit（真正写数据）
二、最后
有关zookeeper的内容还远不止这些，这篇更多的是介绍一些zookeeper的概念，少许客户端的命令操作就每放上来了，今天我们知道zookeeper的存储节点和监听机制，就可以实现很多功能。目前阶段了解这些就够了，有机会再深入的话，会写后续的文章来介绍。
三、参考链接
[01] 一文入门Zookeeper