lease 的有效期时间选择

Lease 的有效期虽然是一个确定的时间点，当颁发者在发布 lease 时通常都是将当前时间加上一 个固定的时长从而计算出lease 的有效期。如何选择 Lease 的时长在工程实践中是一个值得讨论的问 题。如果lease 的时长太短，例如 1s，一旦出现网络抖动 lease 很容易丢失，从而造成节点失去 lease，

使得依赖lease 的服务停止；如果 lease 的时长太大，例如 1 分钟，则一旦接受者异常，颁发者需要 过长的时间收回lease 承诺。例如，使用 lease 确定节点状态时，若 lease 时间过短，有可能造成网络 瞬断时节点收不到lease 从而引起服务不稳定，若 lease 时间过长，则一旦某节点宕机异常，需要较 大的时间等待lease 过期才能发现节点异常。工程中，常选择的 lease 时长是 10 秒级别，这是一个经 过验证的经验值，实践中可以作为参考并综合选择合适的时长。

2.3.5 工程投影

本节介绍几个典型分布式系统中的运用Lease 机制的情况。

2.3.5.1 GFS 中的 Lease

GFS 中使用 Lease 确定 Chuck 的 Primary 副本。Lease 由 Master 节点颁发给 primary 副本，持有 Lease 的副本成为 primary 副本。Primary 副本控制该 chuck 的数据更新流量，确定并发更新操作在 chuck 上的执行顺序。GFS 中的 Lease 信息由 Master 在响应各个节点的 HeartBeat 时附带传递

（piggyback）。对于每一个 chuck，其上的并发更新操作的顺序在各个副本上是一致的，首先 master 选择primary 的顺序，即颁发 Lease 的顺序，在每一任的 primary 任期内，每个 primary 决定并发更 新的顺序，从而更新操作的顺序最终全局一致。当GFS 的 master 失去某个节点的 HeartBeat 时，只

需待该节点上的primary chuck 的 Lease 超时，就可以为这些 chuck 重新选择 primary 副本并颁发 lease。

2.3.5.2 Niobe 中的 Lease

Niobe 中虽然没有明确说明使用了 Lease 机制，但是通过分析可以发现，这是一个 Lease 机制。

Niobe 协议中的 Lease 与常见的由中间节点 Master 颁发给 primary 不太相同。Niobe 协议中，也是通 过Lease 机制维持 Primary 副本的选择，不同的是 Niobe 中的 Lease 是由 Secondary 节点向 Primary 节点发送。

在Niobe 协议中，有一个高可用的全局元数据服务节点称为 GSM（global state manager）。GSM 上的元信息有唯一地址的版本号（称为epoch），每次更新该元信息都必须附带提交之前读取到的版 本号，并进行condition-write，即 GSM 会检验客户节点提交的版本号是否与当前的版本号相同，如 果相同则允许提交更新操作，并递增版本号，否则更新失败，从而实现了元信息更新的全局顺序一 致。

在Niobe 协议中，每个 Secondary 副本都会给 Primary 副本发送 Lease，这个 Lease 的含义是：

在 Lease 时间内，本副本承认你是 Primary 节点。在 Niobe 协议中，一旦出现 primary 失去了某个 secondary 的 lease，此时 primary 和 secondary 都会尝试去 kill 对方，secondary 在 kill 对方的同时还 会尝试成为新的primary。当 primary 失去某个 secondary 的 lease 后，primary 会立刻尝试修改 GSM 中的元信息，将secondary 在元信息中标记为“不可用”，从而 kill 掉该 secondary，被 kill 掉的 secondary 只有重新与 primary 同步后才会被重新标记为“可用”并提供服务。而当某个 secondary 因不能与 primary 通信，造成无法给 primary 发送 lease 后，在 lease 超时后，也会尝试修改 GSM 中，将 primary 标记为“不可用”且将primary 设置为自己。由于在 GSM 上更新操作靠 epoch 实现全局一致。Primary 与secondary 相互 kill 对方的操作有且仅有一个会成功，失败的那个副本需要重新读取 GSM 上的元 数据后才能发起新的更新元数据的操作，而如果被对方 kill，那么重新读取元数据时会发现自己已 经被设置为“不可用”从而无法再kill 对方。

从这里我们可以看到，niobe 中的 lease 含义也可以理解为：“我承诺在接下来 lease 时间内，我 不会kill 你”。这确实是一种另类的 lease 含义。

2.3.5.3 Chubby 与 Zookeeper 中的 Lease

Chubby 中有两处使用到 Lease 机制。

我们知道chubby 通过 paxos 协议实现去中心化的选择 primary 节点（见 2.8.6 ）。一旦某个节点 获得了超过半数的节点认可，该节点成为 primary 节点，其余节点成为 secondary 节点。Secondary 节点向primary 节点发送 lease，该 lease 的含义是：“承诺在lease 时间内，不选举其他节点成为 primary 节点”。只要primary 节点持有超过半数节点的 lease，那么剩余的节点就不能选举出新的 primary。

一旦primary 宕机，剩余的 secondary 节点由于不能向 primary 节点发送 lease，将发起新的一轮 paxos 选举，选举出新的primary 节点。这种由 secondary 向 primary 发送 lease 的形式与 niobe 的 lease 形 式有些类似。

除了secondary 与 primary 之间的 lease，在 chubby 中，primary 节点也会向每个 client 节点颁发 lease。该 lease 的含义是用来判断 client 的死活状态，一个 client 节点只有只有合法的 lease，才能与 chubby 中的 primary 进行读写操作。一个 client 如果占有 chubby 中的一个节点锁后 lease 超时，那 么这个client 占有的 chubby 锁会被自动释放，从而实现了利用 chubby 对节点状态进行监控的功能。

另外，chubby 中 client 中保存有数据的 cache，故此 chubby 的 primary 为 cache 的数据颁发 cache lease，

该过程与2.3.1 中介绍的基于 lease 的 cahce 机制完全类似。虽然相关文献上没有直接说明，但笔者 认为，chubby 的 cache lease 与 primary 用于判断 client 死活状态的 lease 是可以合并为同一个 lease 的，从而可以简化系统的逻辑。

与Chubby 不同，Zookeeper 中的 secondary 节点（在 zookeeper 中称之为 follower）并不向 primary 节点（在zookeeper 中称之为 leader）发送 lease，zookeeper 中的 secondary 节点如果发现没有 primary 节点则发起新的 paxos 选举，只要 primary 与 secondary 工作正常，新发起的选举由于缺乏多数 secondary 的参与而不会成功。与 Chubby 类似的是，Zookeeper 的 primary 节点也会向 client 颁发 lease，

lease 的时间正是 zookeeper 中的 session 时间。在 Zookeeper 中，临时节点是与 session 的生命期绑定 的，当一个client 的 session 超时，那么这个 client 创建的临时节点会被 zookeeper 自动删除。通过监 控临时节点的状态，也可以很容易的实现对节点状态的监控。在这一点上，zookeeper 和 chubby 完 全是异曲同工。

2.3.5.4 间接使用 Lease

笔者很难想象，如何在工程上既不使用Lease 而又实现一个一致性较高的系统。直接实现 lease 机制的确会对增加系统设计的复杂度。然而，由于有类似 Zookeeper 这样的开源的高可用系统，在 工程中完全可以间接使用Lease。借助 zookeeper，我们可以简单的实现高效的、无单点选主、状态 监控、分布式锁、分布式消息队列等功能，而实际上，这些功能的实现都是依赖于背后 zookeeper 与client 之间的 Lease 的。