参考：https://blog.csdn.net/qq_21125183/article/details/86484213
ZK系列文章：https://blog.csdn.net/qq_21125183/category_8609552.html
zk基础看这里： https://blog.csdn.net/wypblog/article/details/103268246
Zookeeper中的角色主要有以下三类，如下表所示：
zookeeper本身支持单机部署和集群部署，生产环境建议使用集群部署，因为集群部署不存在单点故障问题，并且zookeeper建议部署的节点个数为奇数个，只有超过一半的机器不可用整个zk集群才不可用。zookeeper集群中主要有两个角色leader和flower，每个客户端可以连接集群中的任何一个zookeeper节点，同时从其上面read信息，但是针对write操作，flower节点会转发给leader，由leader负责原子广播，从而保证集群中各个节点的数据一致性，zookeeper中规定只有当多余一半的节点同步完成整个write操作才算完成。也就是说可能会有少于一半的数据不是新数据，因此zookeeper中不是强一致性而是实现的最终一致性。但是客户端可以使用sync来强制读取最新的数据。
最终一致性：读数据时，有可能会脏读。比较推荐watch的方式，实现数据的及时生效。
zk是 leader -follower机制，所有的写操作是leader广播通知到所有follower，有一半确认即可。那么广播肯定是不可靠的，万一有的follower没有操作本地数据，所有打到这台follower的请求读到的不是脏数据了吗？
1、zk保证的是顺序一致性，短时间是会有脏读的产生。leader会为每一个follower创建一个广播队列，保证消息的顺序性。folower端：在下一个消息到来时，必已经顺序操作之前的消息了。
2、如果一个客户端将Znode z的值更新为a，在之后的操作中，它又将z的值更新为b，则没有客户端能够在看到z的值是b之后再看到值a；因为客户端也会保存一个它见过的最大的 zxid，如果读取的时候，如果客户端发现 本地 zxid 比 server 端的最大 zxid 大，则拒绝，client 会自动重连到其他server。所以client可能会读到脏数据，但不会读到实时数据后，还会再读到脏数据。
3、如果是广播同步数据的过程中，集群崩溃了。集群会进入投票状态，会通过投票机制选出一个commit最高（数据最新）的zk节点，然后其他follower 都会同步数据到最高commit（数据最新）。
zk基础看这里： https://blog.csdn.net/wypblog/article/details/103268246