本地锁管不住跨进程竞争。本文厘清何时需要分布式锁、锁该具备什么语义，以及哪些场景其实用 DB 条件更新或幂等就能解决，避免锁滥用拖垮吞吐。

要解决什么问题

秒杀库存、定时任务互斥、分布式资源协调等场景，多个服务实例同时修改共享资源。JVM 内 synchronized 无法跨进程，可能出现超卖或 cron 重复执行。若只锁”查询库存”而不锁”扣减+写订单”整段临界区，仍然会在并发写路径上出错。

核心原理

分布式锁把互斥状态存到所有进程可访问的外部系统（Redis/ZK/DB/etcd）。基本条件：互斥、高可用防死锁（TTL/会话）、安全释放（只删自己的锁）。进阶语义包括可重入、阻塞/tryLock 语义、看门狗续约，以及 Fencing Token——下游存储只接受更大 token 的写，拦截锁过期后的迟到写。锁与 Leader 选举、Quorum 同属协调问题家族。

方案权衡

锁降低并发度，能用 DB 条件更新（where count>0）、唯一索引、乐观锁、MQ 串行消费的场景不必上锁。Redis 锁高性能适合短临界区；ZK/etcd 会话语义更强但吞吐和延迟成本更高。务必记住：锁≠事务，只保证互斥进入临界区，不保证跨库提交原子性。

落地要点

lock key 按资源粒度设计如 stock:{skuId}，避免全局大锁；TTL 结合 P99 执行时间，必要时 Redisson 看门狗续约；释放用 Lua 校验 owner；金融级场景下游配合 monotonic fencing token。临界区尽量短，避免锁内 RPC 或长 SQL；获取锁失败要有退避和上限，防止活锁。

常见误区

误区：只锁读路径；TTL 过短导致双持有；无限 wait 阻塞线程池；把 Redlock 当绝对可靠而忽视业务幂等。另一个常见错误是锁粒度太粗，一个 activity 一把锁导致无关 SKU 也互斥等待。