分布式租约机制

1.什么是租约

租约（lease）在分布式中一般描述如下：

• Lease 是由授权者授予的在一段时间内的承诺。
• 授权者一旦发出 lease，则无论接受方是否收到，也无论后续接收方处于何种状态，只要 lease 不过期，授权者一定遵守承诺，按承诺的时间、内容执行。
• 接收方在有效期内可以使用颁发者的承诺，只要 lease 过期，接收方放弃授权，不再继续执行，要重新申请Lease。
• 可以通过版本号、时间周期，或者到某个固定时间点认为Lease证书失效

1.1 Lease机制容错能力

• 通过引入有效期，Lease 机制有非常好的容错网络异常。 Lease 颁发过程只依赖于网络可以单向通信，即使接收方无法向颁发者发送消息，也不影响 lease的颁发。由于 lease 的有效期是一个确定的时间点，lease 的语义与发送 lease 的具体时间无关，所以同一个 lease 可以被颁发者不断重复向接受方发送。即使颁发者偶尔发送 lease 失败，颁发者也可以简单的通过重发的办法解决。一旦 lease 被接收方成功接受，后续 lease 机制不再依赖于网络通信，即使网络完全中断 lease 机制也不受影响。

• Lease 机制能较好的容错节点宕机。如果颁发者宕机，则宕机的颁发者通常无法改变之前的承诺，不会影响 lease 的正确性。在颁发者机恢复后，如果颁发者恢复出了之前的 lease 信息，颁发者可以继续遵守 lease 的承诺。如果颁发者无法恢复 lease信息，则只需等待一个最大的 lease 超时时间就可以使得所有的 lease 都失效，从而不破坏 lease 机制。例如上节中的 cache 系统的例子中，一旦服务器宕机，肯定不会修改元数据，重新恢复后，只需等待一个最大的 lease 超时时间，所有节点上的缓存信息都将被清空。对于接受方宕机的情况，颁发者不需要做更多的容错处理，只需等待 lease 过期失效，就可以收回承诺，实践中也就是收回之前赋予的权限、身份等。

• lease 机制不依赖于存储。颁发者可以持久化颁发过的 lease 信息，从而在宕机恢复后可以使得在有效期的 lease 继续有效。但这对于 lease 机制只是一个优化，如之前的分析，即使颁发者没有持久化 lease 信息，也可以通过等待一个最大的 lease 时间的方式使得之前所有颁发的 lease 失效，从而保证机制继续有效。

1.2 lease服务中时钟同步问题

如果颁发者的时钟比接收者的时钟慢，则当接收者认为 lease 已经过期的时候，颁发者依旧认为 lease 有效。接收者可以用在 lease 到期前申请新的 lease 的方式解决这个问题。

如果颁发者的时钟比接收者的时钟快，则当颁发者认为 lease 已经过期的时候，接收者依旧认为 lease 有效，颁发者可能将 lease颁发给其他节点，造成承诺失效，影响系统的正确性。对于这种时钟不同步，实践中的通常做法是将颁发者的有效期设置得比接收者的略大，只需大过时钟误差就可以避免对 lease 的有效性的影响。

2.租约在分布式系统中的应用

2.1 租约机制保证缓存的一致性

服务器发出Lease后，会保证在Lease的有效期内不改变数据。这样收到Lease的Client在有效期内可以放心地使用数据。在这个有效期内，Client缓存的数据和服务器上的数据是一致的。

存在的问题和解决办法：

1)服务器修改元数据时，需要阻塞所有的读请求，此时服务器不能发出新的Lease。以防止新发出的Lease保证的数据与服务器刚才修改的数据不一致。

解决方法：读请求到来时，直接返回数据，不颁发Lease

2)服务器需要等待直至所有的Client的Lease都过期后，再才颁发新“修改”后的Lease。因此，此时服务器上的数据修改了，生成了一个新的Lease版本，需要等到Client上所有的老Lease过期后，该新Lease版本才能颁布给Client。

解决方法：服务器主动通知持久Lease的Client放弃当前的Lease，并请求新Lease

2.2 租约机制确定节点的状态

通过一个例子来讨论这个问题：在一个 primary-secondary 架构的系统中，有三个节点 A、B、C 互为副本，其中有一个节点为 primary，且同一时刻只能有一个 primary 节点。另有一个节点 Q 负责判断节点 A、B、C的状态，一旦 Q 发现 primary 异常，节点 Q 将选择另一个节点作为 primary。假设最开始时节点 A为 primary，B、C 为 secondary。节点 Q 需要判断节点 A、B、C 的状态是否正常。

2.2.1 通过心跳无法很好判断节点状态

节点 A、B、C 可以周期性的向 Q 发送心跳信息，如果节点 Q 超过一段时间收不到某个节点的心跳则认为这个节点异常。这种方法的问题是假如节点 Q 收不到节点 A 的心跳，除了节点 A 本身的异常外，也有可能是因为节点 Q 与节点 A 之间的网络中断导致的。在工程实践中，更大的可能性不是网络中断，而是节点 Q 与节点 A 之间的网络拥塞造成的所谓“闪断”，“闪断”往往很快可以恢复。另一种原因甚至是节点 Q 的机器异常，以至于处理节点 A 的心跳被延迟了，以至于节点 Q 认为节点 A 没有发送心跳。假设节点 A 本身工作正常，但 Q 与节点 A 之间的网络暂时中断，节点 A 与节点 B、C 之间的网络正常。此时节点 Q 认为节点 A 异常，重新选择节点 B 作为新的 primary，并通知节点 A、B、C 新的 primary 是节点 B。由于节点 Q 的通知消息到达节点 A、B、C 的顺序无法确定，假如先到达 B，则在这一时刻，系统中同时存在两个工作中的 primary，一个是 A、另一个是 B。假如此时 A、B 都接收外部请求并与 C 同步数据，会产生严重的数据错误。上述即所谓“双主”问题。

2.2.2 双主问题的解决

由中心节点向其他节点发送 lease，若某个节点持有有效的 lease，则认为该节点正常可以提供服务。如节点 A、 B、 C 依然周期性的发送 heart beat 报告自身状态，节点 Q 收到 heart beat后发送一个 lease，表示节点 Q 确认了节点 A、B、C 的状态，并允许节点在 lease 有效期内正常工作。节点 Q 可以给 primary 节点一个特殊的 lease，表示节点可以作为 primary 工作。一旦节点 Q 希望切换新的 primary，则只需等前一个 primary 的 lease 过期，则就可以安全的颁发新的 lease 给新的primary 节点，而不会出现“双主”问题。

3.总结

本文将Lease机制的本质及在分布式系统中的主要应用梳理出来了，希望对读者在分布式系统中使用lease机制有帮助。