首页 > 代码库 > 【转】PaxosLease算法--2PC看Paxos选主

【转】PaxosLease算法--2PC看Paxos选主

2024-07-16 06:02:01   222人阅读

原文请参考【[置顶] 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了
注意第四步，是Overwrite原lease状态，还有第三部，若多数派回复为空条件不成立，就要回到第一步重新开始。图示如下：
 
脑子快的童鞋们，看到这里可能就隐隐约约感觉到有问题了。问题在哪呢?
 
如果多个候选者，串行的执行步骤1~4，也就是说，机器A执行1~4，完了后才轮到机器B执行1~4（当然很可能这时执行到第三步就没下文了），这么串行的来执行的话，这个算法是完全正确的，因为任意两个多数派必有一个交集，这个约束使得任两台机不可能都成功的执行1~4步骤（在lease过期时间内）。但关键在于，这个”串行化“是难以实现的。而一旦串行化被破坏以后，结果也就错了，比如，A先探查到全部lease为空，然后B也查到相同结果，然后A占领所有lease成功，A认为自己获得lease。然后B也占领所有lease（overwrite），B同时也认为自己得到lease。
 
怎么办呢？可以效仿Paxos算法的Proposal编号机制，一旦串行化被破坏，编号低的proposor的propose request请求就会被拒绝掉，那么这个proposor也就得不到lease了，必须用一个更高的编号再从第一步开始，具体怎么做，参照Paxos算法，这里就不废话了。
 
还有一个问题，replica宕机重启后，需要等待M>T的时间才能有资格开始竞选master，这也是为了安全性的保证。因为replica并不保存lease相关状态，这是一个diskless的算法。
 
既然是lease，master就得在lease到期之前续约，续约的步骤和上边的5步类似，就是第三步，原本是检查是否有多数派lease为空，改为检查是否有多数派lease或者为空，或者等于自己的ID。
 
这个选举算法，叫做PaxosLease算法，但是本质上和Paxos算法是完全不同的，只不过也用了Paxos算法的两阶段提交形式，同时为了保证两阶段提交的原子性，加入编号机制。但它同样有Paxos算法的活锁问题。但是，和最开始提出的简单的选举算法比，”死锁“问题已经完全消除了。这个算法在一个开源的分布式数据库KeySpace中得到了应用，Google Chubby估计用的也是这种算法，不过相关的论文却语焉不详，或许Google的人觉得这问题过于简单不屑于详述吧。


联系
我们