“你还活着吗？” “我没死，只是网卡了！”——来自分布式世界的“生死契约”

租约（Lease） 机制是分布式系统中一种至关重要的协调工具，广泛应用于节点状态判定、领导者选举、分布式锁、资源管理等场景。其核心思想是通过一个带有时间限制的授权（Time-bounded Promise） 来确保在不确定环境下的行为一致性和系统可靠性。Lease 机制的运行逻辑主要包括以下要点。1）Lease 的本质：Lease 是由授权者（Issuer，例如一个中心协调服务或当前 Leader）授予接收方（Holder/Receiver，例如一个工作节点或候选 Leader）的一种承诺。该承诺规定接收方在 Lease 的有效期内拥有特定的权限（如作为 Leader 的权利、访问某资源的权利）。2）授权者的责任：一旦授权者发出了一个 Lease，只要该 Lease 尚未过期，授权者就必须严格遵守其承诺。例如，如果授予了一个 Leader Lease，那么在它过期前，授权者不能再授予给其他节点相同的 Leader Lease。3）接收方的权利与义务：接收方在 Lease 有效期内可以行使其被授予的权限。一旦 Lease 过期，接收方必须主动放弃该权限，并通常需要重新向授权者申请新的 Lease 才能继续。4）Lease 的失效机制：Lease 可通过版本号号（Version）更新、时间周期（Time Period）到期或到达固定时间点（Fixed Timestamp）等方式失效，确保生命周期可控。

基于 Lease 机制确定节点状态

在分布式系统中确定一个节点是否处于正常工作状态是一个困难的问题，由于可能存在网络分化，节点的状态是无法通过网络通信来确定的。最直观的办法是在 Leader 与 Follower 之间维持一个心跳（Heartbeat）。比如节点 Q 作为一个中心节点， A、B、C 作为副本节点，A 作为 Leader，B、C 作为 Follower， 同一时刻只能有一个 Leader 节点。节点 Q 通过与 A、B、C 的心跳来判断节点状态，从而判断 Leader 节点是否需要切换，但如果只通过心跳判断，是有问题的。节点 A、B、C 周期性地向 Q 发送心跳信息，假如超过一段时间，节点 Q 收不到节点 A 的心跳，除了节点 A 本身甚至是节点 Q 的异常外，也有可能是因为节点 Q 与节点 A 之间的网络异常导致的（比如网络拥塞导致的“瞬断”）。假设节点 A 本身工作正常，节点 A 与节点 B、C 之间的网络正常。但此时节点 Q 认为节点 A 异常，重新选择节点 B 作为新的 Leader，并通知节点 A、B、C 新的 Leader 是节点 B。由于节点 Q 的通知消息到达节点 A、B、C 的顺序无法确定，假如先到达节点 B，则在这一时刻，系统中同时存在两个工作中的 Leader，一个是节点 A、另一个是节点 B。假如此时节点 A、B 都接收外部请求并与节点 C 同步数据，会产生严重的数据错误。上述即所谓“双主”问题。

上面的例子中，如果要保证系统的正确性，依赖于对节点状态认知的全局一致性，即一旦节点 Q 认为节点 A 异常，则节点 A 也必须认为自己异常，从而节点 A 停止作为 Leader，避免出现“双主”的问题。下面讨论利用 Lease 机制确定节点状态：1）节点 A、B、C 周期性地发送心跳报告自身状态，节点 Q 收到心跳后发送一个 Lease，表示节点 Q 确认了节点 A、B、C 的状态，并允许节点在 Lease 有效期内正常工作。2）节点 Q 可以给节点 A 一个特殊的 Lease，表示节点 A 可以作为 Leader 工作。一旦节点 Q 希望切换新的 Leader，则只需等前一个 Leader 的 Lease 过期，则可以安全的颁发新的 Lease 给新的 Leader 节点，而不会出现“双主”问题。

Lease 的容错

1）Leader 节点宕机/网络分区： Lease 机制天然容忍这种情况。Leader 无法续约，Lease 过期后其权限自动失效。系统不可用的最长时间（在等待 Lease 过期期间）受 Lease 有效期限制。2）授权者（中心节点）异常： 若颁发 Lease 的单点授权者 Q 宕机，所有节点都无法获取或续约 Lease，系统可能整体不可用。解决方案是使用一个高可用的小集群作为 Lease 的授权者。3）时钟同步问题：授权者和接收者之间的时钟如果存在较大偏差，可能导致 Lease 的实际有效期与预期不符。授权者在计算 Lease 的到期时间时，需要考虑一个安全窗口（Guard Band 或 Clock Drift Bound）来容纳潜在的时钟误差。按照工程经验，Lease 的时间差一般取 1-10s。太短，则太容易回收承诺，抖动频繁。太长，则太不容易回收承诺，可能导致可用性问题。

ETCD Lease 机制

直接在应用中完整实现一套可靠的 Lease 机制相当复杂。幸运的是，像 ETCD、ZooKeeper 这类成熟的分布式协调服务已经内置了高可用的 Lease 功能，应用开发者可以直接使用。

如上图所示，创建了一个 10 秒的 Lease。 如果在创建 Lease 后不进行任何操作，则该租约将在 10 秒后自动过期。 将 key1 和 key2 绑定到前 Lease，以便在 Lease 到期时 ETCD 自动清除 key1 和 key2。如果希望保留 Lease，则需要定期调用 KeyAlive 方法来刷新它。 例如，要检查分布式系统中的某个节点是否处于活动状态，可以在该节点中创建一个 Lease，并定期调用该节点中的 KeepAlive 方法。 如果进程正常，则保留该节点的 Lease。 如果节点崩溃，Lease 将自动到期。但是，如果大量的 Key 需要支持类似的 Lease 机制，并且必须为每个 Key 独立刷新 Lease，这将给 ETCD 带来很大的压力。 因此，ETCD 允许将多个 Key（例如，具有相似过期时间的 Key）绑定到同一个 Lease，这可以大大减少 Lease 刷新的开销并提高 ETCD 性能。

未完待续

很高兴与你相遇！如果你喜欢本文内容，记得关注哦！！！