1.1 节点类型1.2 Stat结构体
(1)czxid-创建节点的事务zxid
每次修改Zookeeper状态时,都会收到zxid形式的时间戳,即Zookeeeper事务ID。
事务ID是Zookeper中所有修改的总顺序。每个修改都有唯一的zxid。如果zxid1小于zxid2,那么zxid1发生在zxid2之前。
(2)ctime - znode创建的毫秒数(从1970年开始)
(3)mzxid - zxidide最终更新的事务
(4)mtime - znode最终修改的毫秒数(从1970年开始)
(5)pZxid-zznode最终更新的子节点zxid
(6)cversion - znode子节点变化号,znode子节点修改次数
(7)dataversion - znode数据变化号
(8)aclVersion - znode访问控制列表的变化号
(9)ephemeralOwner- 如果是临时节点,这是znode所有者的sessionn id。若不是临时节点,则为0。
(10)dataLength- znode的数据长度
(11)numChildren - znode子节点数量1.3 监听器原理
1.4 选举机制
(1)半数机制:集群中一半以上的机器存活,集群可用。因此,Zookeeper适用于安装奇数服务器。
(2)虽然Zookeper在配置文件中没有指定Master和Slave。然而,当Zookeper工作时,有一个节点是Leader,另一个节点是Follower。Leader是通过内部选举机制临时生成的。
(3)以简单的例子解释整个选举过程。
假设Zookeper集群由五个服务器组成,它们的id从1-5开始,它们都是最新的,也就是说,没有历史数据,存储数据量是一样的。假设这些服务器按顺序启动,看看会发生什么。
Zookeeper的选举机制
(1)服务器1启动并发起选举。服务器1投票给自己。此时,服务器1票不到半数(3票),选举无法完成,服务器1保持LOOKING状态;
(2)服务器2启动,重新开始选举。服务器1和2投票交换选票信息:此时服务器1发现服务器2的ID比目前投票推荐的(服务器1)大,选票更改为推荐服务器2。此时服务器1票0票,服务器2票2票,没有超过一半的结果,选举无法完成,服务器1、2保持LOKING状态
(3)服务器3启动并发起选举。此时,服务器1和2将将选票更改为服务器3。投票结果:服务器10票,服务器20票,服务器33票。此时,服务器3的投票已超过一半,服务器3当选为Leader。服务器1和2更改为FOLLOWING,服务器3更改为LEADING;
(4)服务器4启动,发起选举。此时服务器1、2、3不再处于LOOKING状态,选票信息也不会改变。交换选票信息结果:服务器33票,服务器41票。此时服务器4服从多数,将选票信息更改为服务器3,状态更改为FOLOWING。;
(5)服务器5启动,像4一样当弟弟。1.5 写数据流程