本文介绍下分布式框架实现的选举流程，分为Redis和Zookeeper。
1. 分布式系统选举机制
还是围绕CAP理论来说，假如实现的CP，保证数据强一致性的话，那么整个系统只会有一个Leader节点，当这个节点挂了的话，为了保证数据强一致性，那就需要选出节点后再提供服务。注意，这里整个系统都是不提供服务的。
假如实现的是AP，保证系统可用性，那么整个系统会有多个主节点，每一个主节点又可以对应2、3个从节点，这样一组一组的组成一个整体，那么如果某一组的主节点挂了，这时候客户端访问这个节点只能是失败，导致数据丢失。但对于整个集群来说，可以对外提供服务。
2. Redis选举机制
当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的master。由于挂掉的master可能会有多个slave，从而存在多个slave竞争成为master节点的过程，
其过程如下：
- slave发现自己的master变为FAIL
- 将自己记录的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST信息
- 其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack
- 尝试failover的slave收集master返回的FAILOVER_AUTH_ACK
- slave收到超过半数master的ack后变成新Master(这里解释了集群为什么至少需要三个主节点，如果只有两个，当其中一个挂了，只剩一个主节点是不能选举成功的)
- slave广播Pong消息通知其他集群节点。
3. Zookeeper选举机制
首先先介绍下ZAB协议。
3.1 ZAB协议
zookeeper实现数据一致性的核心是==ZAB协议==（Zookeeper原子消息广播协议）。该协议需要做到以下几点：
- （1）集群在半数以下节点宕机的情况下，能正常对外提供服务；
- （2）客户端的写请求全部转交给leader来处理，leader需确保写变更能实时同步给所有follower及observer；
- （3）leader宕机或整个集群重启时，需要确保那些已经在leader服务器上提交的事务最终被所有服务器都提交，确保丢弃那些只在leader服务器上被提出的事务，并保证集群能快速恢复到故障前的状态。
3.2 选举流程
选举阶段，集群间互传的消息称为投票，投票Vote主要包括二个维度的信息：ID、ZXID
- ID 被推举的leader的服务器ID，集群中的每个zk节点启动前就要配置好这个全局唯一的ID。
- ZXID 被推举的leader的事务ID ，该值是从机器DataTree内存中取的，即事务已经在机器上被commit过了。
假设有两个节点myid = 1 和myid = 2,选举流程如下:
- myid = 1的机器，投出去(1,0)
- myid = 2的机器, 投出去(2,0)，这里默认都是先投自己一票
- myid = 1的机器收到的票是(2,0)，将收到的票和自己投出去的票对比，优先选择zxid大的为leader，zxid大的机器包含的数据是罪行的，如果zxid一样，就选myid大的，这里推荐(2,0)称为leader
- myid = 2的机器投出去是(2,0)收到的是(1,0)，会推荐(2,0)称为leader
- myid = 1的机器投出去(2,0)
- myid = 2的机器投出去(2,0)
- myid = 1和机器和myid = 2的机器，收到的票都是(2,0)，超过集群的半数，此时选举结束，确定myid = 2的机器是leader
