标准答案
- 每次获得锁或租约时分配单调递增的 fencing token，并把 token 带到所有受保护的写操作。
- 数据库、文件服务或下游资源在写入时校验 token 仍不低于当前版本，旧 token 即使持有本地锁也会被拒绝。
- 锁值中的随机持有者标识只能防止错误释放，不能单独防止旧执行者继续写入。
- 业务仍需处理写入被拒绝、任务取消和最终状态查询。
题目解析
锁服务返回成功只说明某个协调动作发生过，不能证明旧持有者已经停止。进程暂停、网络分区和锁过期后，旧请求仍可能继续执行并到达数据库或文件服务。
fencing token 必须由协调者单调递增，并由真正保存业务状态的资源在写入时校验。随机 token 可以识别持有者，却不能判断哪个持有者更新、更应该被接受。
写入被旧 token 拒绝后，任务要进入可查询的冲突或取消状态，并由新持有者继续或补偿。否则只防住了一次覆盖，却留下永久 running 或丢失任务。
常见误区
- 误区：只校验锁值后直接写数据库。改正：把 fencing token 或版本带到最终写入处，由资源拒绝旧持有者。
- 误区：把 UUID 当作能比较新旧的 fencing token。改正：使用协调服务提供的单调递增序列，随机 ID 只能识别不能排序。
- 误区：旧请求失败后不更新任务状态。改正：记录拒绝原因、当前持有者和恢复路径，避免业务任务卡在 running。