前言

在分布式系统中，多个节点同时访问或修改同一资源时，如何保证一致性和避免冲突是一个核心问题。传统的锁机制在高延迟和故障环境下难以保证可靠性，因此出现了一种更适合分布式环境的机制 —— Lease（租约）。

Lease 机制通过“时间约束的授权”方式，在分布式场景中广泛应用，如 Master 选举、缓存一致性控制、元数据服务等。

定义

wiki 定义如下：

A lease is a time-based contract granting temporary exclusive access or permission to a resource.

一句话：Lease 是一种带过期时间的分布式锁，用于控制对资源的独占访问。

工作原理

一句话：通过分配一个带有有效期的访问权（lease）给某个节点，确保在 lease 期间该节点对资源的独占访问。

典型流程如下：

  1. 节点向协调者申请资源的 lease；
  2. 协调者颁发 lease，记录颁发时间与 lease 期限；
  3. lease 到期前，节点可以续约（renew）或释放（release）；
  4. lease 到期后，其他节点可以竞争获取。

此机制确保即使出现网络分区或节点失败，系统也能基于时间超时恢复资源控制权。

属性与指标

关注的 lease 属性与指标包括：

  1. Lease Duration（租约时间） 控制访问权的有效期，过短会频繁续约，过长可能影响恢复。

  2. Clock Drift Tolerance（时钟漂移容忍） 时钟一致性对 lease 协议至关重要，需防止偏差造成误判。

  3. Renewal Policy（续约策略） 主动续约机制，确保 lease 不会意外中断。

  4. Failure Recovery Time（故障恢复时间） 节点故障后，其他节点多久可感知并夺回 lease。

  5. Fencing Token（防越权令牌） 防止过期 lease 持有者在网络恢复后继续写入。

类型

基于 lease 的协议类型

  1. 时间戳 lease（timestamp-based） 依赖节点时钟，简单高效，但要求时钟同步精度高。

  2. 逻辑 lease（logical lease） 使用递增计数作为 lease version，结合 fencing token 使用。

  3. 租约+版本号组合 每次 lease 更新生成唯一版本号，用于防止写穿。

应用场景类型

  1. 分布式主节点选举（Leader Election） 通过 lease 控制某个节点在一段时间内拥有主控权。如 etcd。

  2. 缓存一致性控制（Cache Invalidation） 客户端持有资源缓存时，使用 lease 控制缓存有效期。

  3. 分布式锁服务 比如基于 Zookeeper/etcd 实现的临时节点锁机制。

  4. 分布式文件系统元数据管理 如 GFS 中的 Master 使用 lease 控制 chunkserver 权限。

lease 与程序关系

Lease 与程序的集成方式主要有两种：

  1. Client Embedded Lease 管理 客户端负责 lease 获取、续约与回收逻辑，适合逻辑简单场景。

  2. External Lease Manager 外部系统如 etcd/Zookeeper 提供集中 lease 管理能力，客户端调用接口申请/续约。

程序设计要点：

  • 使用 fencing token 防止“旧主节点”继续访问资源；
  • 避免因 lease 未及时续约造成服务中断；
  • 针对时钟不一致场景应使用对称轮询或 NTP 校准。

常用 lease 产品/机制

  1. etcd lease 支持 TTL、自动续约、watch、过期通知等能力。

  2. Zookeeper ephemeral nodes 基于会话存在实现的隐式 lease，节点断连即释放。

  3. Google GFS master lease 用于控制 chunkserver 对数据块的访问权限。

  4. Consul Session lease 支持 lock、session TTL、健康检查等 lease 特性。

  5. Apache Helix Lease Management 用于任务协调与资源抢占。