选举机制

• 半数机制：至少半数的服务器存活zookeeper集群才算运行成功
• leader机制：虽然没有配置master与slaver，但选举机制选出一个leader。
• 选举机制：投票+myid最大

1. 首先每次每个server投票时投自己，
2. 若当前没有leader选出来时，并发现有id大于自己的，就重新将票投给最大myid的节点
3. 直到有半数的服务器投票了，就选举当前票数最多的服务器为leader（实际为当前myid最大的服务器节点）。
4. 此后再加入的服务器节点的myid无论再怎么大，也无法竞争leader，因为leader已经有了。

节点类型

• 持久型

  ：客户端和服务端断开连接后，创建的节点不删除

  • 持久化目录节点：客户端zookeeper断开连接后，该节点依旧存在
  • 持久化顺序编号目录节点：客户端与zookeeper断开连接后，该节点依旧存在，但zookeeper给该节点名称进行了顺序编号

• 短暂型

  ：一旦断掉连接，就节点自己删除

  • 临时目录节点：客户端与zookeeper断开后该节点被删除
  • 临时顺序编号目录节点：客户端与zookeeper断开后该节点被删除，但zookeeper给该节点名称进行了顺序编号
    

节点结构体

zookeeper中存储的每一个节点都会有信息，其节点信息为一个结构体，具体内容如下：

1. czxid ：创建节点的事务zxid

• 每次修改ZooKeeper状态都会收到一个zxid形式的时间戳,也就是ZooKeeper,事务ID。v事务ID是ZooKeeper 中所有修改总的次序。每个修改都有唯一的zxid，如果 zxid1小于zxid2，那么zxid1在zxid2之前发生。

1. ctime ：znode,被创建的毫秒数(从1970年开始)
2. mzxid ：znode最后更新的事务zxid
3. mtime ：znode最后修改的毫秒数(从1970年开始)
4. pZxid ：znode最后更新的子节点zxid
5. cversion ： znode子节点变化号，znode子节点修改次数,7) dataversion - znode数据变化号。
6. aclVersion ： znode 访问控制列表的变化号,
7. ephemeralOwner ：如果是临时节点，这个是 znode,拥有者的session id。如果不是临时节点则是0。
8. dataLength ： znode的数据长度
9. numChildren ： znode子节点数量

写数据流程

每次客户端向zookeeper集群的服务器写数据时，其主要的流程如下图：

1. 客户端向zookeeper上一个服务器节点server1发送写请求
2. server1如果不是leader，会把请求转发给leader
3. leader会将写请求广播给集群各个服务器节点
4. 当leader收到一半以上节点写成功，就会告诉server1写成功
5. server1返回给客户端写成功
   

监听器原理

在zookeeper常用的功能就是客户端想zookeeper注册监听某数据，那么这个监听的原理如下：

1. 首先有一个main()线程
2. 在main线程中创建zookeeper客户端，就会有connet通信与监听listener的两个线程
3. 通过connet线程将注册的监听事件发送给zookeeper
4. zookeeper的注册监听器列表中将注册的监听时间添加到列表
5. zookeeper监听到数据路径有变化，就会将消息发送给listener线程
6. listener线程内部进行需要的处理程序（外部实现）
   

• 常用监听命令：
  • 监听节点数据变化get path [watch]
  • 监听子节点增减变化ls path [watch]