以下基于小白理解，如果有错误，请指正：
1、约定
Leader:领导者 Follower:跟随者 oberserver:观察者
CAP理论：
2、原理
zk基础数据结构是DataTree（先不研究底层数据结构），核心思想就是基于Zab协议（Leader选举）+ 二段式分布式事务。
1、Leader选举 ： 客户端发送了一个请求，zk集群里所有节点启动，进入Leader选举（a、比较各个节点里的事务id(zxid)，最大的就是Leader；如果各个节点里的zxid一致的情况，则比较serverid（myid），最大的就是Leader）。
2 、ACK ：当从Follower里选举出Leader后，Leader将会将请求转化为全局唯一的事务请求（二段式事务开启），然后将请求广播给所有Follwer，等待响应（ACK）。
3、Commit ： 只有当Leader得到超过半数Follower的响应情况下，才会提交事务，同时将通知所有的Follower提交事务。
3、开发中遇到的问题
当往已经选举出Leader的zk集群里动态添加一个节点，此时整个集群是不会重新进入Leader选举的，得重启进入恢复模式。
Leader选举选举发生在（Zab协议中恢复模式）：
1、集群启动
2、Leader挂掉
3、Follower挂掉后，Leader发现已经没有过半的Follower投票给自己，此时整个zk集群宕机，不能对外提供服务。
4、zk脑裂（split-brain）
当因为整个zk集群在选举过程中通信出现问题，而分裂为多个zk集群，此时各个zk集群会各自选举出自己的Leader，一旦通信恢复，这个集群将会出现多个Leader。
解决方法：Leader的过半选举已经解决了这个问题，只有超过过半机器存活的情况下，才会进行选举。
当整个zk集群脑裂成两个zk集群，因为两个集群里的节点都不会超过原先过半机器存活，所以这两个zk集群实际是不会进行选举的。
实际上啥都不用做，别用太老的zk版本就好了。
大佬分析博客，在下佩服：