在分布式系统多节点并发访问共享资源时，提供唯一且可靠的互斥控制，避免数据错乱与重复执行。它的应用场景远不止扣库存，从定时任务防重到缓存击穿防护，选型和落地方式直接决定系统稳定性，本文围绕分布式锁应用场景与最佳实践,给出可直接落地的方案和避坑指南。
分布式锁应用场景有哪些：三个典型战场
秒杀与库存扣减的强一致保障
秒杀系统是分布式锁最经典的练兵场，用户请求经过负载均衡分散到多个应用实例，若每个实例都直接操作数据库库存字段，超卖几乎必然发生，行业共识是，在内存中预扣库存后，使用分布式锁将“检查库存-扣减-回写”三步操作原子化。
实操中，推荐使用Redisson的RLock配合Watchdog自动续期,关键代码路径如下：
- 获取锁：
RLock lock = redissonClient.getLock("stock:sku:1001"); - 尝试加锁：
boolean locked = lock.tryLock(500, 30, TimeUnit.SECONDS); - 业务操作：在锁内执行库存预扣与MQ消息发送。
- 释放锁：
lock.unlock();必须放在finally中。
这里有个极易踩坑的点：锁粒度，如果直接用商品ID做锁key，同一商品的所有SKU会互相阻塞，吞吐量大幅下降，最佳实践是锁key细化为stock:sku:{skuId},让不同SKU并行扣减。
分布式定时任务防重执行
集群环境下，每台机器都会运行同一套定时任务（如每日凌晨的数据对账、报表生成），不加锁会导致重复计算、重复推送短信，传统方案是配置文件里加开关，但只对固定节点数有效,扩缩容后就会失效。
分布式锁解决此问题的标准姿势是：
- 使用Redis的
SET key value NX PX 30000命令获取锁。 - 锁key设为任务名（如
job:data-reconciliation）,value设为当前节点IP与线程ID的组合。 - 任务执行完毕后，通过Lua脚本比对value再删除,防止误删他人锁。
- 若任务超时，锁自动过期，但需在业务代码中处理“上次任务未完成”的情况,可在数据库记录任务执行批次号。
对于执行时间可能超过锁过期时间的任务，务必开启看门狗自动续期，或使用ZooKeeper临时顺序节点锁，后者在会话超时后自动释放,更适合长任务。
缓存击穿与热点数据重建护盾
当某个热点缓存过期，大量请求同时回源数据库，瞬间压力可能打垮DB，分布式锁在此处的作用是：只允许一个线程重建缓存，其他线程等待或直接返回旧值。
具体操作步骤：
- 请求到来时先查缓存,命中则直接返回。
- 未命中则尝试获取锁（key为缓存业务key加锁后缀）。
- 获取成功的线程查数据库，重建缓存,设置过期时间后释放锁。
- 获取失败的线程短眠后重新查缓存,或直接返回降级数据。
这里需要警惕的是“锁内再查缓存”的死循环，建议在锁内先二次确认缓存是否已被其他节点重建,避免无谓的DB查询。
分布式锁场景最佳实践：选型对比与超时设定
Redis锁与ZooKeeper锁怎么选
不同中间件的分布式锁实现各有优劣，直接决定可用性与性能,下表展示核心差异：
| 维度 | Redis（Redisson） | ZooKeeper | etcd |
|---|---|---|---|
| 性能 | 极高，毫秒级 | 中等，数百毫秒级 | 中等 |
| 可靠性 | 主从切换可能丢锁 | 强一致，临时节点可靠 | 强一致，Raft协议 |
| 适用场景 | 高并发、短任务、可容忍极小概率失效 | 金融级强一致、长任务 | 云原生环境、跨数据中心 |
| 实现复杂度 | 低，客户端内置看门狗 | 中，需处理会话超时 | 中，需依赖etd服务 |
业内专家指出，大多数互联网业务场景下，Redis锁配合Redisson客户端已足够，只有在对账、资金操作等极强一致场景,才建议升级为ZooKeeper或etcd。
锁超时时间设置原则
锁超时设置过长，节点宕机后要等很久才能恢复；设置过短，业务没执行完锁就自动释放，其他节点乘虚而入,最佳实践分两步：
- 先估算业务最大耗时，乘以1.5至2倍作为兜底超时时间。
- 再启用看门狗自动续期，每三分之一超时时间续期一次,业务完成后手动释放。
如果不使用看门狗，可采用“锁内任务进度心跳”机制：在锁内定期更新一个短暂过期时间戳，其他节点发现该时间戳仍在刷新，就继续等待,这种方式比单纯设置固定超时更灵活。
锁粒度与锁范围控制
锁粒度太粗，串行化严重；太细则可能产生死锁,遵循以下原则：
- 锁key必须包含业务维度（如订单号、用户ID、商品SKU）,避免全局锁。
- 锁内只包裹需要互斥的临界区代码，数据库查询、远程调用尽量不要放在锁内。
- 跨资源操作时，按固定顺序获取多把锁，并设置总获取超时时间,防止循环等待。
分布式锁的四大经典坑与对应解法
坑一：锁误删
线程A持有锁，因GC或网络延迟超过锁过期时间，锁自动释放，线程B获取同一把锁并开始执行，此时A执行完毕，调用del命令，直接把B的锁删掉，解决方法是value写入唯一标识（UUID或线程ID），删除前用Lua脚本比对,匹配才删除。
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
坑二：主从切换导致锁丢失
Redis主节点宕机，从节点晋升为主，但锁数据尚未同步，导致锁丢失，Redisson的RedLock算法可缓解，但业界对其争议较大，实现复杂且在三节点以上集群才有意义，更务实的做法是：对锁丢失容忍度极低的场景，直接切换ZooKeeper,不要过度设计Redis方案。
坑三：可重入性与非重入混用
同一个线程在同一把锁内嵌套加锁，若锁实现不支持可重入，则直接死锁，Redisson默认支持可重入，但原生Redis命令实现需要自己维护计数器，建议统一使用Redisson的getLock，其内部通过Hash结构记录重入次数，释放时递减,归零才真正删除。
坑四：等待锁时的队列阻塞
当大量线程同时等待同一把锁，Redis客户端会阻塞等待或频繁轮询，Redisson内部使用信号量和发布订阅机制，锁释放时通知等待线程，避免无意义轮询，但若业务代码中设置过长的tryLock等待时间，依然可能拖垮线程池，最佳实践是
等待时间不超过500毫秒,超时后直接返回失败或走降级逻辑。
高并发下的分布式锁优化策略
分段加锁提升吞吐
热门商品库存有1000件，若只锁整个库存，并发最多1，拆分为10个段，每段100件，锁key为stock:sku:1001:segment:{0-9}，请求随机落到某一段，吞吐量提升近10倍，多段库存扣减后，需额外处理段间余量转移，逻辑稍复杂,但收益明显。
本地锁与分布式锁结合
在同一实例内，多个线程访问同一资源时，先获取本地锁（如ConcurrentHashMap中的ReentrantLock），再获取分布式锁，这样能减少Redis的锁请求压力，同时避免同一实例内多个线程互相竞争分布式锁，注意本地锁的失效时间要略短于分布式锁,防止本地锁释放后分布式锁未获取导致的不一致。
锁内减少RPC调用
每次Redis锁的获取和释放都是一次网络往返，若锁内再调用远程服务，锁持有时间会不可控地拉长，优化方案是：在锁内只做本地内存操作和状态标记，异步发送MQ触发后续流程，例如秒杀场景中，锁内只预扣库存并写入待支付订单,实际库存扣减由MQ消费者完成。
分布式锁常见问题解答
分布式锁和数据库唯一索引有什么区别
数据库唯一索引（如订单号唯一约束）也能防止重复插入，但无法处理“先查后写”的复合操作，且对数据库压力较大，分布式锁适用于任意分布式资源互斥，数据库唯一索引更适合强约束的幂等场景,两者可互补使用。
Redis分布式锁在集群模式下可靠吗
Redis在单机模式下可靠，在主从或Cluster模式下，极端情况（主节点宕机、锁未同步）可能失效，若要强可靠，选择ZooKeeper或etcd，大多数业务场景下，Redis锁的可靠性已足够，因为锁丢失只是极小概率事件,且业务侧通常有数据库兜底或幂等校验。
分布式锁的key过期时间设多长合适
没有通用标准值，取决于业务最大耗时，建议先压测获取P99耗时，再设置为P99耗时的两倍加上缓冲时间，同时主动使用看门狗续期，让锁不会提前失效，对于不确定的任务，优先采用ZooKeeper临时节点锁，会话断开自动释放,无需预估时间。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/567251.html
