目录
选主原理
1. zookeeper的集群角色
leader
leader是zookeeper集群的核心。
1 事务请求的唯一调度的矗立着，他需要保证事务处理的顺序性
2 集群内部各个服务器的调度者
follower
1 处理客户端非事务请求以及转发事务请求给leader服务器
2 参与事务请求提议的proposal投票 【客户端的一个事务请求需要半数服务投票通过才能通知leader commit，leader会发起一个提案，要求follower投票】
3 参与leader选举的投票
observer
1 观察zookeeper集群中最新状态的变化，并且把这些状态同步到observer服务器上。
2 增加observer不影响集群事务处理能力，同时能提升集群的非事务处理能力。
2. zookeeper的事务流程
zookeeper的集群组成
zookeeper一般是由2n+1台服务器组成
leader选举
1）leaderElection
2）AuthFastLeaderElection
3）FastLeaderElection
serverID ：配置server集群的时候给定服务器的标识id myid
zxid：服务器它运行时产生的数据ID，zxid值越大，标识数据越新
Epoch：选举轮次 sid
server的状态：Looking，Following，Observering，Leading
leader选举
1）leaderElection
2）AuthFastLeaderElection
3）FastLeaderElection
serverID ：配置server集群的时候给定服务器的标识id myid
zxid：服务器它运行时产生的数据ID，zxid值越大，标识数据越新
Epoch：选举轮次 sid
server的状态：Looking，Following，Observering，Leading
如上图，在zookeeper中，客户端会随机向zookeeper中的某个几点发起请求，如果是读请求，就直接从当前节点中读取数据，如果是写请求，那么这个request会被转发给leader提交事务，然后leader会广播此事务，向所有的follower发起proposal，只要超过半数的返回ack即响应，那么leader就会commit这个写的事务。
通常 zookeeper 是由 2n+1 台 server 组成，每个 server 都知道彼此的存在。对于 2n+1 台 server，只要有 n+1 台（大多数）server 可用，整个系统保持可用。我们已经了解到，一个 zookeeper 集群如果要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信，基于这个特性，如果向搭建一个能够允许 F 台机器down 掉的集群，那么就要部署 2*F+1 台服务器构成的zookeeper 集群。因此 3 台机器构成的 zookeeper 集群，能够在挂掉一台机器后依然正常工作。一个 5 台机器集群的服务，能够对 2 台机器down掉的情况下进行容灾。如果一台由 6 台服务构成的集群，同样只能挂掉 2 台机器。因此，5 台和 6 台在容灾能力上并没有明显优势，反而增加了网络通信负担。系统启动时，集群中的 server 会选举出一台server 为 Leader，其它的就作为 follower（这里先不考虑observer 角色）。
之所以要满足这样一个等式，是因为一个节点要成为集群中的 leader，需要有超过及群众过半数的节点支持，这个涉及到 leader 选举算法。同时也涉及到事务请求的提交投票。
所有事务请求必须由一个全局唯一的服务器来协调处理，这个服务器就是 Leader 服务器，其他的服务器就是follower。leader 服务器把客户端的失去请求转化成一个事务 Proposal（提议），并把这个 Proposal 分发给集群中的所有 Follower 服务器。之后 Leader 服务器需要等待所有Follower 服务器的反馈，一旦超过半数的 Follower 服务器进行了正确的反馈，那么 Leader 就会再次向所有的Follower 服务器发送 Commit 消息，要求各个 follower 节点对前面的一个 Proposal 进行提交;
3. ZAB协议
ZAB（Zookeeper Atomic Broadcast） 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。ZAB 协议包含两种基本模式，分别是
1） 奔溃恢复
2）原子广播
当整个集群在启动时，或者当 leader 节点出现网络中断、崩溃等情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader，当 leader 服务器选举出来后，并且集群中有过半的机器和该 leader 节点完成数据同步后（同步指的是数据同步，用来保证集群中过半的机器能够和 leader 服务器的数据状态保持一致），ZAB 协议就会退出恢复模式。当集群中已经有过半的 Follower 节点完成了和 Leader 状态同步以后，那么整个集群就进入了消息广播模式。这个时候，在 Leader 节点正常工作时，启动一台新的服务器加入到集群，那这个服务器会直接进入数据恢复模式，和 leader 节点进行数据同步。同步完成后即可正常对外提供非事务请求的处理。