Leader Election 选举算法

今天讲一讲分布式系统中必不可少的选举算法。
leader 就是一堆服务器中的协调者，某一个时刻只能有一个leader且全部服务器都认可这个leader. leader election就是在一组进程中，选举一个leader且让该组的进程都赞成这个leader.

假设有N个process, 每一个process都有个能够比较的ID，能够提出选举。
leader election算法要知足两点：

• safety: 每个进程要么不知道结果，要么知道正确的结果（不会选错leader）。
• liveness: 选举算法总会结束，每个进程都知道告终果。

Ring leader election 环算法

processes组成了一个环，第i个 process p_i 能够和 p_(i+1)modN通讯。

若是进程i发现原来的leader挂了，它就会发起选举，发送一个包含本身ID a_i “Election”的信息。而后当某个进程j收到了这个信息的时候，会将这个a_i与本身的ID a_j比，若是a_i>a_j, 继续转发这条消息，若是a_i<a_j且它以前没有转发过消息,就把a_i取代掉而后把消息发送出去。若是发现收到的标识符和本身的同样，表明本身成为leader，而后把本身当选的信息发送出去。

最坏状况分析：一个进程发起选举，若是它的上一个进程具备最大标识符，则选举消息到达上一个进程须要（N—1）次传递，而后消息又要N次才能宣布它当选，最后须要N个消息告诉你们它当选了，因此须要（3N-1）个消息。最好状况就是发起选举的进程就是leader，只须要（2N）个消息。若是有多个进程同时发起选举，那么只有具备最大ID的进程会完成选举。

可是环算法实用价值不多，由于在选举过程当中若是有进程崩溃，选举就没法完成，不符合liveness的要求。

实际生产中的Leader Election

用Paxos-like (Paxos是解决一致性问题的一种方法) 来选举。

Google Chubby

A system for locking

每一个process最多选举一次，获得最多选票且大于某一数值的process当选。

Apache Zookeeper

Centralized service for maintaining configuration information

Paxos的变种Zab(Zookeeper Atomic Broadcast)。必须始终保持有leader。

每一个进程都向ZK文件系统中写入本身的ID,只要保证写入是原子性的，就把最大ID的进程选为leader.

每一个进程都监视着正比如本身ID高的进程，若是那个进程是leader而后挂掉了，那么它就成为新的leader.

Bully Algorithm 霸道算法

假设系统是同步的，全部进程均可以互相通讯。当某一进程发现leader挂掉，若是本身ID最大，就宣布本身是leader，不然向ID比本身高的进程发起选举。发起选举若是没有收到回应，就宣布本身是leader，收到了回应就等待比本身ID大的进程宣布结果。
当一个进程收到从ID比本身低的进程发来的选举消息时，就向更高的进程发起选举。

最坏时间复杂度分析：只需5个消息传递时间

1. 最小ID进程发起选举
2. 第二大ID进程回应
3. 第二大ID进程向最大ID进程发起选举
4. 最大ID进程无回应，timtout
5. 第二大ID进程宣布当选