原文请参考【[置顶] Paxos master选举--PaxosLease算法】

众所周知，为了避免Paxos算法的活锁问题，必须选举唯一的proposor。偏偏在Paxos原论文中，作者L. Lamport不屑于讨论这个问题，因为选举过程中，即使出现多个master共存，也不影响Paxos算法正确性。另一方面，由著名的Fischer-Lynch-Paterson结论可知，不采取超时机制，任何算法都不能保证在有限时间内选举成功。不过这个结论在这里对我们影响不大，我们只要设计一个实际系统中好使的一个算法就行，而且我们希望保证选举过程的”安全性“，任意时刻不允许多个master共存，理由见这里。

为了满足”安全性“，容易想到lease机制，一个lease，就是一个带expire-time的锁。锁的持有者必须在expire-time之前进行续约（延后expire-time），否则time一到锁就自动释放。这样锁的持有者宕机后不会导致资源长时间被锁住，其次，锁的持有者若由于网络原因续约失败，就必须在expire-time到来之前停止对锁住资源的操作，这样其它主机在expire-time到来后获得锁，就不会和原先的锁持有者同时操作锁住的资源，造成数据被破坏。

回到这里的问题，多台机选举一个master，每一台都可能宕机，这个lease肯定不能只存在一台机上，每台机都是对等的，那所有的机器都得存一份lease，容易设计出如下简单的算法：

• 参与选举的机器先启动定时器，超时时间T，然后广播一个获取lease请求，附带上自己机器id。
• 每台机器接收到lease请求后，检查自己的lease状态，若为空或者等于请求机器的id，把lease状态设为此id机器占有，然后也启动定时器，超时时间T（超时时间一到就把lease置空），回复OK。否则回复lease被占用。
• 如果参与选举机器接收到多数派机器回复OK，那么在超时时间T结束，可以确信自己独占lease，这段时间内别的机器无法获取lease。

上述算法的正确性是显而易见的，但是很容易陷入死锁。假设多个候选者同时广播lease请求，分别抢占了一部分机器的lease，但又都达不到多数派的要求，那么就谁也无法获得lease，只能等待每台机器lease超期再次尝试。注意到第二次尝试必须等到lease超期后才能再开始，这是很严重的block状态，所以这里把它称为”死锁“。

如何避免上述的死锁问题？容易想到，在发出占有lease的指令之前，可以先探查一下当前所有机器上lease的状况，如果探查结果超出半数的lease都是空的，那么再广播占有lease的指令，否则的话就过一段时间再探查，因为在这种情况下再去占有剩下的lease，不但获得不了多数派lease，反而会加剧死锁。

这样一来，我们就很容易设计出一个两阶段提交的算法了：

1. prepare request：广播探查lease指令
2. prepare response：回复lease状态
3. propose request： 检查收到的Respond回复，若多数派回复为空，发出Capture lease指令，当然，要附带上本机ID。然后启动定时器，超时时间T
4. propose response：接收Capture Lease，Overwrite原lease状态，回复OK
5. Check & Ack： 若收到多数派的OK回复，那么在超时时间T结束之前，就可以确信自己得到lease了