分布式系统或组件一般都包含Leader选举的过程，比如ZooKeeper的Leader节点选举，Redis Sentinel的领头节点选举，Redis Cluster中主节点的选举等。
术语
节点状态：所有节点具有3种状态：Leader, Follower, Candidate。
自定义术语
Leader选举根据是否按照节点状态/数据选举，分成等价选举和择优选举
- 等价选举：Candidate完全等价，没有优劣之分。比如Redis Sentinel
- 择优选举：Candidate根据不同的状态，存在不同优先级。比如ZooKeeper
Leader通用算法
对比多个分布式组件，发现他们都存在一个通用的算法模式（本质上是Raft算法）：
进入选举状态
当系统进入选举状态时，节点本身的状态是Candidate。
- Follower: Follower节点如果与Leader断开超过设定值则会进入Candidate；
- Leader: 如果没有超过半数的Follower与Leader保持连接，Leader也会进入Candidate；
- 新节点：自动进入Candidate。
投票
不同的组件的选举算法中，最大的差别就体现在投票这个环节
- 投票周期加1
- Candidate选举自己，并要求所有其他节点都选举自己
- 选举节点首先对比选举周期(logical clock/term/epoch)，首先拒绝选举周期比较小的Candidate。在最大的选举周期中再按照规则选择（这里的玄机就比较多了，后面有投票规则的简单列举）
投票规则
先到先得：这个是最简单的规则，适合等价选举。比如Redis Sentinel， Redis Cluster。
ZooKeeper：对比事务ID和服务器ID的组合(zxid, sid)，选择值最大的组合。简单地说，通常哪台服务器上的数据越新，那么越有可能成为Leader，也就能够保证数据的恢复。
注意：虽然Redis Cluster中从节点是有数据的，但是选择主节点并不考虑从节点的数据，所以这里是Redis Cluster数据不一致的原因之一。
选票统计
- 如果某一个Candidate得票超过半数，则选举为Leader。
- 如果没有则再次进入投票阶段
有的算法会让各个节点随机等待一段时间后再进入投票阶段，比如Redis Sentinel选举领头的算法
修改服务器状态
Leader选举完成后，各个节点会更新自己的状态，Leader选举完成。
注意点：ZooKeeper Leader选举算法会在Leader选举后还会等待一小段时间（默认200ms），以防会有更优的Leader产生
等价选举vs择优选举
两者在投票过程中存在部分差异
投票PK
- 等价选举，一般按照先来先得，而且在同一个投票周期内不再修改；择优选举，会进行选票PK，最终得到规则下优先级最高的选票。
- 在一轮周期内选举失败，等价选举中各个节点会等待一个随机时间，减少选举冲突，提高选举成功率；择优选举不需要等待随机时间。
投票方式
等价选举：一般使用的是询问式，Candidate直接向其他节点索要选票，根据最后拿到的选票判断是否被选举为Leader。
择优选举：使用广播选票的方式，Candidate选择自己，并向所有其他节点广播自己的投票。 如果收到Candidate广播过来的选票，节点需要PK后，择优选择，如果发生变更则广播新的投票。因为可能存在同一个目标节点对多个投票请求都回复“同意”。
常见疑问
为什么需要引入选举周期(logical clock/term/epoch)？
等价选举：先到先得选举，在一轮投票汇中可能不会产生多数派结果，所以需要重新进入一轮新的选举，也就是选举周期。
择优选举：这一点我也有疑问，因为择优选举中，各个节点可以一直PK，直到Leader选举成功，这是可以收敛的。所以我认为也可以不引入选举周期。（搜索了很多资料、书籍、百度、谷歌、谷歌英文等都没有找到引入选举周期的答案，也有人跟我有相同的疑惑http://zookeeper-user.578899.n2.nabble.com/FastLeaderElection-td2616674.html）
PS：如果您有好的解释，还请指教，不胜感激！如何在网络较差的情况下，所有节点对选举结果达成一致？是否存在可能，一个节点确认了多数投票结果，但是其它节点还没有确认？
这个问题不存在，因为Leader选举完成，并不是形成多数节点选举结果就结束。还需要最后各个节点之间完成确认和状态切换，比如准Leader必须跟大多数节点建立心跳，而且这些节点也要进入Follower状态。
改进点
- 设置只有部分节点才可以成为Leader（比如ZooKeeper中的observer节点就不可以）
欢迎讨论，本人承诺非假日期间两小时内回复
