工程师做久了几乎都会遇到一个场景明明线上服务是多实例部署的但某个定时任务、某个资源操作希望同一时刻只有一个节点在跑。一开始大家可能想着用数据库唯一索引、用 synchronized 或者进程内 Lock结果发现一旦流量上来、实例一多这些办法统统不灵。这时候就轮到分布式锁登场了。分布式锁这个东西简单说就是“跨进程、跨机器的互斥”但在实际落地中它远没有“一把锁”听起来那么简单。锁怎么加、怎么解、怎么处理超时、节点突然挂掉怎么办、主从切换锁会不会丢……每一个细节都是坑。而且这些坑不是理论上的我身边就有同事因为锁没设计好凌晨被叫起来处理重复订单。这篇文章就围绕“分布式锁的实现原理”这个主题把我这些年实际用过的方案、踩过的坑、以及面试里最常被追问的细节一次性讲清楚。无论你是刚接触分布式系统的新人还是准备跳槽想巩固基础的老手这篇文章都能给你一些实在的参考。1. 分布式锁的使用场景与核心需求1.1 先搞清楚什么场景才真的需要分布式锁很多人一听到“分布式锁”就觉得高大上但实际工作中真正常见的场景反倒很朴素。我做过的项目里最典型的是这几类定时任务的幂等执行。最常见的例子是每天凌晨跑一次报表统计、清理过期数据、推送营销短信。如果是单机部署Spring 的Scheduled加个锁就完事了。但一旦上了多实例每台机器都会跑一遍同样的任务轻则浪费资源重则重复扣费、重复发消息酿成事故。分布式锁在这里的作用就是保证只有一台机器真正执行其他机器直接跳过。共享资源的互斥修改。比如库存扣减、订单状态流转。有人可能会说库存扣减用数据库乐观锁或者 Redis 原子操作就行这确实没错但有些业务逻辑不是一句 UPDATE 能搞定的。比如一个复杂的“预占-确认-释放”流程中间涉及多次读写如果不加锁两个请求就可能读到同一份中间状态然后互相覆盖。防止缓存击穿和并发穿透。比如某个热点 key 过期瞬间大量请求同时回源数据库。用一个分布式锁让请求排队第一个线程去重建缓存其他线程等待完成后再读取能大幅降低数据库压力。多节点协同中的选举。比如集群里需要选出一个“主节点”来统一调度那也可以用分布式锁来实现简单的 Leader 选举。但我也遇到过一些硬把分布式锁往上套的场景比如纯读操作、单库事务能解决的场景或者压根没有并发压力的接口。这种时候加分布式锁除了把系统变复杂、增加 Redis 或数据库的压力之外没有任何好处。判断的标准其实很简单单机锁搞不定或者部署上做不到单机时才需要考虑分布式锁。1.2 梳理需求一把合格的分布式锁要满足什么条件不管底层用 Redis、ZooKeeper还是数据库一把“合格”的分布式锁从需求角度来说必须满足三个核心条件第一条是互斥性。任何时刻只能有一个客户端持有锁。这是分布式锁的根本如果连互斥都保证不了那把锁就是摆设。第二条是安全性。锁一定要能被正常释放不能因为客户端崩溃、网络超时等原因导致“死锁”。具体来说锁必须设置过期时间持有锁的客户端挂掉之后锁要能自动失效同时释放锁时要保证是持有者本人释放不能把别人持有的锁误删掉。第三条是可用性。加锁和解锁的性能要足够好不能因为加锁这个动作本身变成系统的瓶颈。而且当锁服务节点出现故障时整个系统不能因此瘫掉。这三条是“及格线”再往上走还有两个更难的需求一个是容错性就是在极端情况下比如 Redis 主从切换、ZooKeeper 会话过期锁也不能失效另一个是可重入性就是同一个客户端能否在持锁状态下重复获取同一把锁这个在业务里也非常常见。把需求拆清楚之后再去看各种实现方案就会发现每个方案的取舍其实都很清楚它满足了哪些需求牺牲了哪些需求坑在哪里。下面我把主流的实现方案逐个拆开来讲。2. 三种主流实现方案的选择逻辑2.1 为什么 Redis 成了最主流的方案现在国内团队做分布式锁大部分首选 Redis。原因其实很现实绝大多数互联网公司本来就有 Redis部署和维护成本为零Redis 的SET命令是单线程原子执行的天然适合做互斥单实例 Redis 的 QPS 可以轻松跑到十万甚至更高加锁的耗时基本在亚毫秒级别对业务几乎无感知。但还有一层更深的原因分布式锁这东西在大多数业务里的出现频率并不高但它出现的时候都是关键路径。相比引入一套 ZooKeeper 或者 etcdRedis 的学习成本、运维复杂度都是最低的。很多团队并不是不知道 Redis 锁有瑕疵而是在业务可接受的范围内用最低的成本解决 99% 的问题这是工程上的理性选择。2.2 数据库方案与 ZooKeeper 方案什么时候才会选数据库方案是最原始的自己在数据库建一张锁表通过INSERT唯一键成功与否来判断是否抢到锁。它的优点是绝对可靠、和业务数据同库同事务缺点是性能太差单表几万 QPS 就到头了而且数据库本身也可能成为瓶颈。我一般只在两种情况下会考虑它一是老项目里连 Redis 都没有二是锁的操作必须和业务数据在同一个数据库事务里提交保证强一致。ZooKeeper 方案则是使用临时顺序节点加监听机制实现的“公平锁”它的核心优势是没有锁超时问题客户端崩溃后会话失效节点自动被删除。但代价是每次获取锁都要经历一次网络往返和节点创建性能比 Redis 差一个数量级而且 ZooKeeper 本身的部署复杂度也比 Redis 高很多。所以它只适合对锁的可靠性要求极高、对性能不敏感的场景比如分布式任务调度框架内部的 Leader 选举。3. 分布式锁的核心细节解析3.1 锁的粒度与 Key 设计这里最容易被忽略锁的设计第一步不是选技术而是设计锁的 Key。很多新手拿到需求就去写代码结果锁的 Key 粒度太大导致大量无关请求互相阻塞系统并发能力直线下降。举个例子一个秒杀系统要对商品库存扣减加锁如果锁的 Key 是固定的STOCK_LOCK那所有商品的抢购请求都会串行排队商品 A 的请求会阻塞商品 B 的请求这就白瞎了 Redis 的并发能力。正确的做法是 Key 里带上商品 ID比如STOCK_LOCK:10001这样每个商品各抢各的锁互不影响。锁的粒度可以按业务来定用户级别、订单级别、商品级别甚至精确到某个 SKU原则就是在不产生并发冲突的前提下把锁的粒度做得尽可能小。另外Key 命名要有业务前缀和分隔符方便排查。我见过有的项目锁的 Key 就是不带任何前缀的一串数字线上出了问题时用 Redis 的KEYS命令扫出来一堆不知道属于哪个业务的锁排查成本会高出很多。建议统一按业务模块:资源类型:资源ID的格式命名一目了然。3.2 加锁为什么必须用 SET key value NX EX在 Redis 还没有提供SET扩展参数之前很多人用SETNX加锁再用EXPIRE设置过期时间但这两个操作不是原子的中间如果客户端挂了锁就永远不释放。后来官方推出了SET key value NX EX把“不存在才设置”和“设置过期时间”合并成一个原子操作。这里有一个关键细节value不能随便填。正确的做法是生成一个全局唯一的随机 ID比如 UUID因为后面释放锁时要校验“自己是持有者”否则会出现一种可怕的情况线程 A 的锁因为业务执行时间过长自动过期了线程 B 抢到了锁此时线程 A 执行完毕直接DEL key结果把线程 B 刚拿到的锁删掉了……随后线程 C 又进来了互斥彻底失效。带上唯一标识释放前先判断再删除就能避免这种误删问题。# 加锁key 不存在才设置有效期 30 秒 SET lock:order:12345 uuid_value NX EX 30 # 释放锁Lua 脚本中先校验再删除保证原子性 if redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 end3.3 锁超时是个无解的矛盾业务执行时间超过锁有效期怎么办锁超时可以说是分布式锁设计里最矛盾的一个点。有效期设短了业务还没执行完锁就自动释放了另一个线程进来互斥被打破有效期设长了一旦持有锁的节点真的挂了锁要等很久才能被其他节点获取业务恢复时间被拉长。这个问题没有万能答案常见的有三类解法第一类是评估好最大值设一个相对宽松的过期时间。比如业务最长执行 5 秒锁有效期设成 30 秒给自己留足余量。这是最简单粗暴也最常用的办法缺点是无法应对突发情况比如某次数据库拖慢了业务执行了 40 秒。第二类是看门狗机制自动续期。像 Redisson 的 Watchdog默认有效期为 30 秒每 10 秒检查一次锁是否仍然持有如果持有就续期到 30 秒。这样只要客户端活着锁就永不超时客户端挂了锁最多 30 秒自动释放。第三类是给锁加上业务层面的幂等兜底。比如重复扣费的订单号在数据库里加唯一索引即使锁偶有失效导致重复执行数据库层也会把脏数据拦下来。这个思路很多人忽略但其实是生产环境里最保险的一道防线——不要把所有的安全都寄托在锁上。3.4 可重入问题同一个线程能再次获取同一把锁吗如果没有做可重入设计同一个线程在持锁状态下再次调用lock()会把自己给阻塞住。比如一个方法加了锁内部又调用了另一个也加了同一把锁的方法直接死锁。解决可重入的方案有几种。简单一点的做法是借助 ThreadLocal在加锁时记录线程 ID 和计数如果当前线程已经持锁就回传一个“重入”标记并增加计数每释放一次就减少计数减到 0 才真正删除 Redis 中的锁。复杂一点的可以直接用 Redisson它自带的RLock就是可重入的内部就是通过 ThreadLocal 加 map 维护的。实际项目里如果用的是 Redisson基本不用自己操心这个问题。4. 实操过程一步步实现一个 Redis 分布式锁4.1 锁定技术栈与基础环境先说一个我个人的建议如果公司项目里还没有引入 Redis 客户端封装最好的选择是直接用 Redisson因为它在锁这块已经做得相当成熟如果项目里用的是 Spring Boot那引入 redisson-spring-boot-starter 就行配置也很简单。下面我用原生代码来演示核心逻辑方便看清原理但真正落地时我推荐 Redisson。需要的基础环境是一个可用的 Redis 实例版本最好在 3.2 以上以保证SET扩展参数可用JDK 8 及以上以及一个简单的 Spring Boot 工程。伪代码示例只是为了看清实现思路4.2 基于 SET NX EX 的加锁与 Lua 解锁实现先看最基础的实现。首先是加锁public class RedisLock { private StringRedisTemplate redisTemplate; private static final String LOCK_SUCCESS OK; private static final Long LOCK_RELEASE_SUCCESS 1L; public boolean tryLock(String lockKey, String requestId, long expireSeconds) { Boolean result redisTemplate.opsForValue() .setIfAbsent(lockKey, requestId, expireSeconds, TimeUnit.SECONDS); return LOCK_SUCCESS.equals(result); } public boolean lock(String lockKey, String requestId, long expireSeconds, long waitSeconds) throws InterruptedException { long waitMillis waitSeconds * 1000; long start System.currentTimeMillis(); while (System.currentTimeMillis() - start waitMillis) { if (tryLock(lockKey, requestId, expireSeconds)) { return true; } Thread.sleep(50); // 自旋等待重试间隔不宜过大否则响应慢 } return false; } public boolean unlock(String lockKey, String requestId) { String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; Long result redisTemplate.execute( new DefaultRedisScript(script, Long.class), Collections.singletonList(lockKey), requestId); return LOCK_RELEASE_SUCCESS.equals(result); } }加锁这里我用的是setIfAbsent(key, val, timeout, unit)底层就是SET key value NX EX一个原子操作搞定“不存在才设置”和“过期时间”。解锁的时候用 Lua 脚本先比较 value匹配才删这一步必须保证原子性否则 GET 和 DEL 之间可能出现并发间隙。有一点我要特别提醒自旋重试的时候休眠时间不要太短也不要太长。太短比如 1 毫秒会导致 Redis 被打满稍微有点并发压力就全是无谓的重试太长比如 500 毫秒又会拖慢业务响应。经验值是 20~100 毫秒之间具体可以根据业务对响应时间的要求来调整。4.3 升级版加入自动续期与可重入能力上面这个版本虽然能工作但离生产环境可用的标准还差得远。核心问题有两个过期时间固定业务一慢锁就会失守不可重入嵌套调用的场景直接死锁。我一般会在项目中维护一个带看门狗和重入计数的版本核心思路如下public class RedisLockV2 { private static final ThreadLocalMapString, Integer REENTRANT_MAP new ThreadLocal(); private ScheduledExecutorService watchdogExecutor; public boolean lock(String lockKey, String requestId, long expireSeconds, long waitSeconds) throws InterruptedException { MapString, Integer countMap REENTRANT_MAP.get(); if (countMap null) { countMap new HashMap(); REENTRANT_MAP.set(countMap); } // 可重入判断 if (countMap.containsKey(lockKey) countMap.get(lockKey) 0) { countMap.put(lockKey, countMap.get(lockKey) 1); return true; } // 抢锁失败则循环重试成功才继续 boolean success tryLockWithRetry(lockKey, requestId, expireSeconds, waitSeconds); if (success) { countMap.put(lockKey, 1); startWatchdog(lockKey, requestId, expireSeconds); } return success; } private void startWatchdog(String lockKey, String requestId, long expireSeconds) { watchdogExecutor.scheduleAtFixedRate(() - { // 每 expireSeconds/3 秒执行一次续期 // 通过 Lua 脚本比较 requestId 后刷新过期时间 renewExpire(lockKey, requestId, expireSeconds); }, expireSeconds / 3, expireSeconds / 3, TimeUnit.SECONDS); } public boolean unlock(String lockKey, String requestId) { MapString, Integer countMap REENTRANT_MAP.get(); if (countMap ! null countMap.get(lockKey) ! null) { int count countMap.get(lockKey) - 1; if (count 0) { countMap.put(lockKey, count); return true; } countMap.remove(lockKey); // 这里再执行 Lua 释放锁 return releaseLock(lockKey, requestId); } return releaseLock(lockKey, requestId); } }这个版本其实是把 Redisson 的核心思想简化了一遍实际生产环境没必要自己造轮子直接用 Redisson 就行但理解了这段代码再看 Redisson 源码就会觉得非常亲切。4.4 生产落地直接用 Redisson 封装该配置的全配好如果在真实项目中我强烈建议直接用 Redisson它把上面说的续期、重入、公平锁、红锁这些都内置了。我把生产里常用的写法贴出来Configuration public class RedisLockConfig { Bean public RedissonClient redissonClient() { Config config new Config(); config.useSingleServer() .setAddress(redis://127.0.0.1:6379) .setPassword(your_password) .setConnectionPoolSize(50) .setTimeout(3000); return Redisson.create(config); } }业务里使用Autowired private RedissonClient redissonClient; public void deductStock(Long skuId) { RLock lock redissonClient.getLock(STOCK_LOCK: skuId); try { if (lock.tryLock(3, 30, TimeUnit.SECONDS)) { // 业务逻辑校验库存 - 扣减 - 记录日志 } else { throw new RuntimeException(抢锁超时请稍后重试); } } finally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } } }Redisson 里面有三个参数值得说明一下。waitTime是获取锁的最大等待时间超过直接放弃这个值要根据业务对响应时间的要求来定leaseTime是锁持有的最长有效时间如果传了 -1 则启用看门狗自动续期我个人推荐直接传 -1交给看门狗管理过期时间的默认值是 30 秒看门狗每 10 秒续一次。5. 常见问题与排查技巧实录5.1 锁的“误删”问题别人持有的锁被我删了这个可以说是 Redis 分布式锁最经典的生产事故了。场景复盘一遍线程 A 拿到锁执行时间超过了锁有效期锁自动过期。线程 B 进来拿到了同一把锁开始执行。此时线程 A 终于执行完了调用delete删除锁直接把线程 B 还持有的锁删掉了。接着线程 C 进来了也顺利拿到锁。此时 B 和 C 同时执行业务互斥被打破。解决的方案就是我在前面反复强调的每个线程加锁时value 用全局唯一的 ID。释放锁时必须用 Lua 脚本先校验 value 是否匹配匹配才删。很多团队用 Redisson 就没这个问题因为它内部就是这么实现的但如果自己写原生代码千万把这一步做对。判断的方法很简单删除后看返回值如果 Lua 脚本返回 0说明当前线程不是锁的持有者这个释放是无效的可以打印一条告警日志辅助定位线上异常。5.2 主从切换导致锁丢失这个坑比想象的深再深一层的问题假设 Redis 是标准主从架构线程 A 在主节点上拿到了锁但数据还没来得及同步到从节点主节点挂掉了哨兵完成故障切换从节点升级为新的主节点。此时新的主节点上没有锁数据线程 B 就可以成功获取同一把锁。这就是经典的“锁丢失”问题。Redis 官方给出的答案是 Redlock 算法向集群中多个独立的 master 节点分别加锁超过半数成功才算获取成功释放时向所有节点释放。但业界对这个算法一直有争议因为它在理论上有缺陷比如时钟跳跃会让锁提前失效。我的建议是如果业务能容忍偶发的锁失效单机 Redis 就够用如果完全不能容忍就不要用 Redis 做锁服务直接上 ZooKeeper 或者 etcd。不要在 Redlock 上投入太多精力工程上不划算。5.3 锁的超时设置一个经典的调优案例有一次排查一个接口响应慢的问题前后端都在抱怨我去看代码发现一个定时任务的锁有效期设置成了 30 秒但业务的平均执行时间只有 500 毫秒。问题出在这个接口会被多个节点的定时任务触发每次触发时第二个节点会去抢锁因为锁还没过期所以直接走抢锁失败分支返回——这是正常情况但返回之前它调了tryLock(waitTime)而 waitTime 又设成了 10 秒。排查思路是这样的先看日志里的耗时分布在哪个环节然后发现大量请求阻塞在tryLock上最后把 waitTime 从 10 秒降为 2 秒同时把锁的有效期从 30 秒调整为 5 秒。结果接口的 P99 耗时从原本的 8 秒降到了 1.4 秒。这里给一个经验参数表参数设置建议原因锁有效期业务最长耗时的 3~5 倍给极端情况留余量又不至于影响恢复速度获取锁等待时间不超过接口允许的最大耗时的 50%避免锁等待拖垮响应时间锁粒度按业务资源 ID 拆分减少无关请求的互相等待5.4 监控与问题速查表线上其实还有一种看不见的问题锁相关代码逻辑没问题但 Redis 实例本身出了问题导致整个业务链路卡死。比如 Redis 主节点在进行 RDB 持久化时可能会 fork 子进程如果内存很大fork 会导致秒级停顿请求全部堆积。所以在使用 Redis 分布式锁的系统中Redis 的高可用监控一定要做起来不能等出了问题再去背锅。我把实践中遇到的高频问题和排查思路整理成一张速查表现象可能的根因排查手段抢锁超时锁有效期太短或业务执行太慢查看 Redis 中锁的 TTL、业务执行耗时锁失效后重复执行锁自动过期没有续期检查是否启用了看门狗偶发的互斥失效主从切换导致锁丢失检查哨兵日志、主从切换时间点解锁报异常释放锁时 value 不匹配检查请求 ID 是否全局唯一大量请求阻塞锁粒度太大或 waitTime 太长检查锁 Key 的设计和 waitTime 参数6. 从实现原理到方案总结6.1 Redis、ZooKeeper、数据库三种方案的全面对比到了文章最后我觉得应该站在选型的角度把所有方案放在一起做个对比。这三种方案不是谁取代谁的关系而是适用场景完全不同。维度RedisZooKeeper数据库性能极高万级 QPS中等千级 QPS低百级 QPS可靠性单节点有丢失风险高ZAB 协议保证一致性高取决于数据库自身锁超时必须设置会话超时自动释放必须设置可重入需自行实现或使用 Redisson原生支持需自行实现部署成本低基本都有高需要独立集群最低复用业务库适合场景大多数互联网业务强一致场景、Leader 选举传统单体项目、强一致性场景从这张表能明显看出来Redis 是“性价比最高”的普适方案ZooKeeper 是“最严谨”但最重的方案数据库方案则是一种兜底。我个人在选型时有一个很朴素的原则业务允许偶发重复就选 Redis业务完全不能容忍重复且性能要求不高就选 ZooKeeper没有额外基础设施就选数据库。最后再分享一点我的个人体会经历过几次线上事故之后我的体感是分布式锁的难点从来不在“怎么用”而在于“出了问题怎么兜底”。我见过太多团队把所有的安全性都押在锁上锁失效了业务就彻底崩了。真正稳妥的做法是把锁当成第一道防线而不是唯一防线。核心操作要设计幂等性数据库层面要有唯一约束关键路径上要有日志和监控——这些加起来才能让系统在极端情况下依然能兜得住不至于酿成事故。另外一个建议是如果你们团队准备引入分布式锁优先用成熟的开源组件Redisson 是首选不要自己写。自己写的锁一开始可能没问题到了主从切换、网络抖动、业务超时这些边界情况出现的时候才知道坑有多深。而成熟组件已经把这些问题踩过一遍了该考虑的都考虑了。省下的时间多去梳理业务的幂等和兜底机制性价比高得多。