直接回答：租约是“带过期时间的授权”：协调者授予节点某角色（主节点、锁持有者、缓存写权），持有者在有效期内行使权力，到期不续即自动失效——解决“持有者失联后权限如何收回”的问题，避免每次操作都问协调者的开销。典型应用：GFS/ChunkServer 的主副本租约、分布式锁、K8s node lease 心跳。
展开解析：时钟假设的坑：租约安全依赖“各方的有效期判断近似同步”——持有者认为没过期继续行使权力，协调者认为已过期把权力授给别人，双主窗口出现。失效模式具体而残酷：进程 GC 停顿 30 秒，醒来时租约实际已过期但本地时钟显示还在期内，继续写共享资源——Martin Kleppmann 对 Redlock 的批评就是这个场景。防御组合：fencing token——租约颁发时带单调递增令牌，下游资源（存储、数据库）记录见过的最大令牌，拒绝陈旧令牌的写——把裁决从“持有者的时钟”移到“资源方”，时钟不同步也安全，这是最强防线；保守续租——持有者在工作完成前提前很久续租（TTL 1/3 处）、写路径上每次关键操作前校验剩余租约余量是否大于操作最坏耗时；协调者侧保守——旧租约到期后等一个 grace period 再颁发新租约，吸收时钟偏差；硬件兜底——共享存储场景的 SCSI reservation 这类资源级 fencing。理解层次：纯租约=性能优化加“大概率正确”；租约+fencing token=正确性保证。选型建议：能用共识（etcd 事务带 lease 加 compare-and-swap）就别手写租约逻辑——etcd 的 lease 加 revision 检查已经把 fencing token 模式内建。
追问方向：为什么 fencing token 必须由资源方校验？NTP 时钟回拨对租约的影响？
（约 490 字）