一 ZAB协议（Zookeeper在用）
Zab协议有四个阶段
Leader election
Discovery (E#epoch establish)
Synchronization (5X#sync with followers)
Broadcast
比如3个节点选举leader：编号为1、2、3。1先启动，先投票给自己zxId=1，然后2启动首先也投自己一票zxId=2，然后广播给其他server，节点1收到zxId=2请求大于自己的（ziId相同就比较编号，编号大的为leader），就投票给节点2，所以1、2都选择2为leader，然后3启动发现1，2已经协商好且数量过半，于是3也选择2为leader，leader选举结束。
二 Raft协议
1.定义
Raft是工程上使用较为广泛的强一致、去中心化、高可用的分布式协议。是一种共识算法。
2.选主流程
Raft算法定义了三种角色：
Leader（领导者）
Follower（追随者）
Candidate（候选者）
初始状态下集群所有节点都是Follower，每一个节点都有自己的计时器，当计时达到了超时时间（Election Timeout），该节点会转变为Candidate，成为Candidate的节点.会首先给自己投票，然后向集群中其他所有的节点发起请求，要求大家都给自己投票，其他收到投票请求且还未投票的Follower节点会向发起者投票，发起者收到反馈通知后，票数增加。
得票数超过了集群节点数量的一半，该节点晋升为Leader节点。Leader节点会立刻向其他节点发出通知，告诉大家自己是领导者。收到通知的节点全部变为Follower，并且各自的计时器清零。如果发现有节点票数相同，那么会随机休息一段时间，再次发起投票，由于时间是随机，所以避免再次票数相同的概率
选出 Leader 后，Leader 通过定期向所有 Follower 发送心跳信息维持其统治。若 Follower 一段时间未收到 Leader 的心跳则认为 Leader 可能已经挂了再次发起选主过程
3.数据同步
1.由客户端提交数据到Leader节点
2.Leader 节点接收到的数据处于未提交状态（Uncommitted）
3.由Leader节点把数据复制到集群内所有的Follower节点
4.Follower节点们接收到复制的数据，会反馈给Leader节点
5.如果Leader节点接收到超过半数的Follower反馈，表明复制成功，向 Client 确认数据已接收
6.一旦向 Client 发出数据接收 Ack 响应后，表明此时数据状态进入已提交（Committed）
7.再由Leader节点通知集群内所有的Follower节点提交数据，从而完成数据同步流程
三 常见选主缺点
3.1 脑裂及解决方法
1.Quorums（法定人数），过半机制：默认方式， 比如3个节点的集群，Quorums = 2, 也就是说集群可以容忍1个节点失效，这时候还能选举出1个leader，集群还可用。比如4个节点的集群，它的Quorums = 3，Quorums要超过3，相当于集群的容忍度还是1，如果2个节点失效，那么整个集群还是无效的。
2.冗余通信：采用多种通信方式，避免因一种通信终端导致脑裂。
3.智能磁盘锁：正在服务一方锁住共享磁盘，"裂脑"发生时，让对方完全"抢不走"共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动"解锁"，另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了"智能"锁。即正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了。
4.设置仲裁机制：例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下 参考IP，不通则表明断点就出在本端，不仅"心跳"、还兼对外"服务"的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。
3.2 羊群效应
宕机的那个Broker上的Partition比较多， 会造成多个Watch被触发，造成集群内大量的调整，导致大量网络阻塞
3.3 zookeeper负载过重
每个Replica都要为此在ZooKeeper上注册一个Watch，当集群规模增加到几千个Partition时 ZooKeeper负载会过重
