引入分布式锁之前，应先判断数据库唯一约束、条件更新或任务分片能否解决问题。锁会增加新的故障模式，并不自动提供业务正确性。

必须明确的五点

  • 锁保护的具体不变量是什么？
  • 持有者暂停超过租期会怎样？
  • 续租失败后任务能否立即停止？
  • 释放锁时如何确认仍是原持有者？
  • 锁服务故障时选择可用还是安全？

锁值应包含唯一持有者标识，释放时通过原子脚本比较并删除。对不能容忍旧持有者继续写入的资源，需要 fencing token：每次获取锁得到递增编号，下游拒绝较旧编号的操作。

分布式锁适合协调，不适合掩盖模糊的状态模型。能用数据层原子操作表达的不变量，通常更容易验证。