Fencing令牌与过期持有者

超时可以让协调服务另选一个人，却不能叫停旧人的CPU，更不能收回网络中已经发出的写。旧进程可能在垃圾回收、调度暂停或断网后恢复，仍拿着旧锁句柄办事。Fencing把最后一道判断放在真正产生效果的资源处。

“新leader认为自己赢了”和“存储已经拒绝旧leader”之间也隔着消息。代际不是会自动传播的全局事实；只有资源见到较新代际并稳定保存，它的拒绝边界才向前推进。

41号迟到，42号先到 ​

资源R初始highestEpoch=40,value=0。P取得41，准备写value=8却暂停。协调服务后来把42授给Q。Q先在R执行Activate(42)并收到成功，再写value=9，资源保持水位42。P恢复后发送41号写，资源比较41<42而拒绝，值仍为9。

若去掉资源端比较，P的迟到写会把9覆盖成8。即使P发写前再次向协调服务询问“我还持锁吗”，也存在它收到肯定、随后暂停、Q获得新锁、最后P执行写的窗口；检查和外部效果之间的时间差没有消失。

新授权尚未传播的空档 ​

Q已经取得42，但Activate(42)还在路上，R的水位仍为41。P的41号写此时到达会被接受。这不违反最小fencing性质，因为资源尚未接受42；却反驳“协调服务发新锁就立即撤销所有旧写”的更强说法。把上层交接完成点移到激活确认之后，才使合同与资源的事实对齐。

检查和写分开会漏过旧人 ​

错误实现让P先读水位41并通过检查，然后释放资源锁。Q将水位提升为42并把值写成9。P再按先前检查结果把值写成8，即使数据库里最终水位为42，也已经产生旧代写。应在一项条件事务或等强原子操作里比较和修改，不能只把检查代码摆在写代码前面。

资源重启也必须保留水位42。若余额持久化、水位回到0，旧41就会重新通过；若资源分片只在部分副本检查代际、另有绕过接口，同样不能建立全资源保证。

不变量highestEpoch单调，且每次有效操作的代际不小于操作前水位。按资源端串行转移归纳：一次更高代操作把水位抬升；后续低代请求必被拒绝；同代请求不改变这个结论。原子持久恢复保证崩溃不会把已确认水位降回去。这份证明依赖资源端，而不是租约时钟准确或持有者配合停止。

同代请求仍可重复。41号同一扣款被送两次，在没有42介入时两次都满足e>=highestEpoch。Fencing隔离旧持有者，请求身份与结果表理路复制会话、请求序号与结果去重Replicated client session · Request deduplication · Session sequence number用显式注册会话、严格请求序号和同前缀结果表处理重试，复算响应丢失、乱序、结果回收及会话过期边界。限制重复业务；二者是不同轴。一个服务常同时需要(resource,epoch,requestId)，并明确每个字段的作用域。

若一任期内leader可多次交出并重新获得资源，单用Raft term可能不够；需要每次授权都严格递增的代际。跨集群重建后从1重新编号也不安全。可用持久计数或不可重复的集群代际加局部计数，但资源必须比较完整有序身份，且旧集群令牌永不重新有效。

单资源的水位存储为O(1)个编号，另计其位长；每次检查可为常数次比较，却通常还需资源的串行事务和持久化成本。编号无限递增不是固定宽度永不溢出；工程实现需在耗尽前拒绝新授权或安全换代。若目标只提供无条件写、不能验证令牌，也没有代理能把检查与写原子绑定，就不能靠客户端库补出这项保证。