我们开发中遇到“锁”这个标题时我第一反应是这多半是并发场景下的资源竞争问题。无论是单机多线程、多进程还是微服务架构下多节点协同一旦涉及共享资源的互斥访问锁就是绕不开的核心机制。这篇文章我从分布式锁切入结合我多年用 Redis、ZooKeeper、数据库实现锁的实战经历把方案选型、核心原理、踩坑记录完整拆开讲一遍。适合正在做后端开发、中间件封装或者准备系统学习分布式协同的读者。1. 内容整体设计与思路拆解1.1 锁的本质先想清楚要保护什么很多项目把锁写得很复杂但根源上没想清楚保护对象。锁的本质是“串行化临界区”——让多个执行单元在争夺同一个共享资源时只有一个能进入操作区间其余等待或失败重试。我见过最典型的错误上来就引入 Redis 分布式锁但实际上问题发生在单机 JVM 内部。单进程多线程共享变量时synchronized或ReentrantLock就够了完全不需要跨节点。锁的选型第一步是判断执行单元的数量级只在进程内竞争用本地锁跨进程、跨主机竞争才需要分布式锁。另一个容易忽略的点是锁的保护对象必须是“可被多个执行单元同时触达的共享资源”。比如库存扣减、订单状态流转、缓存重建、定时任务调度这些都是典型的临界区资源。如果资源本身就是隔离的比如每个节点处理自己的数据分片那把锁加在节点之间反而是过度设计会无谓增加延迟和运维复杂度。1.2 分布式锁的三个核心性质互斥、安全、可用任何分布式锁方案都必须满足三个性质互斥性Mutual Exclusion任意时刻只能有一个客户端持有锁。这是锁存在的第一性原理做不到互斥的锁等同于没有锁。安全性Safety锁不会因为异常情况进程崩溃、网络分区、GC停顿被错误释放导致多个客户端同时进入临界区。安全性问题往往比可用性更隐蔽排查成本更高。可用性Availability加锁和释放锁的操作本身要尽量高可用不能让锁服务成为整个系统的单点瓶颈。但注意可用性不能以牺牲安全性为代价——分布式系统的经典教训就是“优先保证安全其次追求可用”。我在设计锁方案时有个习惯先画出最坏情况的时序图。比如客户端 A 持有锁后 GC 停顿了 2 秒锁因为超时被自动释放客户端 B 拿到了锁进入临界区这时候 A 恢复了也进入了临界区——这就是互斥性被破坏的场景。任何方案如果无法对“持有者暂停”导致的重入情况给出合理对策我基本不会采用。2. 方案选型没有最好的锁只有最合适的锁2.1 Redis 锁性能与实现难度的平衡点Redis 分布式锁是当前应用最广的方案核心原因是它足够简单且性能极高。Redis 单实例能支撑每秒十万级以上的 SET 操作对于绝大多数业务场景完全够用。我记得有人用 SET NX EX 一条命令就实现了加锁这个方法确实简洁SET lock_key unique_value NX PX 30000。NX 表示只有 key 不存在时才设置成功PX 设置过期时间unique_value 用来标识锁的持有者防止误删别人的锁。但原生 Redis 锁有两个明显短板单点问题Redis Master 宕机或切换锁可能丢失或重复授予。锁自动过期业务执行时间超过过期时间锁被自动释放其他客户端趁机进入。解决单点问题的经典方案是 Redlock 算法。它的思路是向多个独立的 Redis 节点依次加锁只有超过半数节点加锁成功才算加锁成功。但这个算法本身也存在争议——有分布式系统研究者指出在发生时钟跳跃或 GC 暂停时Redlock 依然无法提供绝对安全的互斥保证。我的观点是如果你的业务允许极小概率的互斥失效比如缓存重建、非资金类操作Redlock 足够用如果业务要求绝对严格互斥资金交易、库存扣减那就不要依赖纯 Redis 方案。2.2 ZooKeeper 锁强一致的代价是高延迟ZooKeeper 分布式锁基于临时顺序节点实现。客户端在锁目录下创建临时顺序节点然后检查自己是否是序号最小的节点如果是则获取锁成功否则监听前一个节点的删除事件等待获得锁。这套机制的好处是临时节点特性客户端崩溃后ZK 会自动删除该节点锁自动释放不需要担心死锁。强一致性ZK 的 ZAB 协议保证了所有节点的数据一致性没有 Redis 主从切换那种锁丢失问题。坏处也很明显写操作的吞吐量上限远低于 Redis而且每次加锁释放都要经历多次网络 RTT往返时间延迟通常在几十毫秒量级。高并发场景下ZK 集群的压力很大不太适合作为高频短临界区的锁服务。我通常在以下场景用 ZK 锁分布式任务的领导者选举、需要在多个节点间严格互斥且写入频率不高的元数据操作、对安全性要求高但对性能要求中等的内部系统。2.3 数据库锁简单直接但上限明显数据库实现分布式锁最原始的方法是建一张锁表加锁就是插入一条记录释放就是删除这条记录利用数据库唯一索引保证互斥。还有一种做法是用SELECT ... FOR UPDATE行级锁事务提交或回滚时释放锁。数据库锁的实现成本最低因为大多数系统本来就依赖数据库不需要额外引入中间件。但它的问题同样突出性能上限低数据库的连接资源本来就宝贵用来做高频锁操作很容易把数据库拖垮同时如果加锁事务长时间不提交会阻塞其他事务甚至引发锁等待超时和死锁。我觉得数据库锁只适合极低频率的互斥操作比如灰度开关的切换、定时任务的单实例调度标记。一旦并发量上来这套方案会最先成为瓶颈。我把三个方案的特点整理成一张对照表方便你在方案选型时直接参考维度Redis 锁ZooKeeper 锁数据库锁性能高单实例十万级 QPS中千级 QPS低依赖数据库连接可靠性依赖持久化与主从配置有锁丢失风险高临时节点 强一致高事务保证实现复杂度低一条命令即可中需要理解 ZK 会话与节点机制低SQL 即可适用场景高频短临界区、缓存重建、幂等控制强互斥要求、领导者选举低频互斥、已有数据库依赖典型风险GC 暂停导致锁过期、主从切换丢锁会话超时可能误删锁长时间持锁阻塞事务、连接耗尽整套方案没有通吃所有场景的银弹选型必须回归业务对互斥性和可用性的容忍度。3. 核心实现手写一把可用的 Redis 分布式锁3.1 加锁一条命令保证原子性加锁的关键在于“检查 key 是否存在”和“设置 value 并设置过期时间”必须是一个原子操作。早期很多人是先GET判断再SET这个分步操作存在竞态窗口两个客户端同时发现 key 不存在然后都设置成功互斥性被破坏。正确做法是用一条命令完成SET lock:order:1001 unique_token NX PX 30000其中lock:order:1001是锁的 key按业务维度设计粒度越细并发能力越高。unique_token是客户端生成的唯一标识一般用 UUID 或业务请求 ID。NX表示只有 key 不存在时才设置。PX 30000表示锁的有效期为 30 秒。我用“试过”这个说法可能不太准确应该是“实测下来”这条命令在 Redis 5.0 之后的官方文档中已经明确是原子操作不需要用 Lua 做额外包装。小提示这里 token 的唯一性很重要。它不仅是锁持有者的身份标识更是释放锁时校验归属的关键不能用固定值否则会出现误删锁的问题。3.2 解锁用 Lua 脚本避免误删解锁阶段最常见的坑是用两步操作先GET拿 value 判断是否是自己持有再DEL删除。这个操作不是原子的存在一个窗口判断通过后但还没执行 DEL 时锁恰好过期了另一个客户端加锁成功这时候你执行 DEL直接把别人的锁删掉了。解决方式是用 Lua 脚本把“校验 删除”合并为原子操作if redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 end调用时统一传入锁 key 和加锁时的 unique_token只有 token 匹配才会删除不匹配则不做任何操作并返回 0。这个脚本在大多数 Redis 客户端中都有现成封装不建议手写字符串拼接调用直接用客户端库提供的eval或unlock方法更稳。精髓在于锁的释放必须“认人”谁加的锁由谁释放不能凭 key 名直接删。3.3 超时续期看门狗机制锁的过期时间和业务执行时间之间是一对矛盾过期时间设短了业务没跑完锁就自动释放互斥被破坏设长了客户端崩溃后锁迟迟无法释放阻塞其他客户端。一种常见思路是设置一个较长的过期时间比如 5 分钟。但这引入了新问题如果持有者真的崩溃了其他客户端要等 5 分钟才能获得锁业务阻塞严重。如果业务平均执行时间只有几秒又拿 5 分钟的过期兜底遇到大量请求时会形成明显的排队积压。更优雅的做法是“看门狗续期”。持有锁的客户端启动一个后台任务周期性检测锁的剩余过期时间如果业务尚未结束就主动延长过期时间。经典实现在 Redisson 中做得比较完整默认锁超时 30 秒通过后台线程每 10 秒检查一次只要锁还被当前客户端持有就把过期时间重置为 30 秒。这样锁既不会因为业务运行时间过长而提前释放也不会在客户端崩溃后长期占用。手动实现看门狗也不复杂核心伪代码如下// 加锁成功后在后台执行续期任务 ScheduledExecutorService executor Executors.newSingleThreadScheduledExecutor(); executor.scheduleWithFixedDelay(() - { if (stillHoldingLock(lockKey, token)) { // 重置过期时间为 30 秒 redisTemplate.expire(lockKey, 30, TimeUnit.SECONDS); } else { // 锁已释放停止续期 cancelRenewal(); } }, 10, 10, TimeUnit.SECONDS);这里的stillHoldingLock同样要用 Lua 脚本检查 key 的 value 是否等于自己的 token避免误续期别人的锁。续期任务必须在“解锁成功”或“锁自动过期”后立即取消否则会产生幽灵续期。3.4 完整实现示例Redis Lua 的可靠锁我整理了一个可以直接落地的方案框架包含加锁、解锁、续期三个核心方法。这个框架我使用过多个项目中具备基本的生产可用性但因为篇幅限制我简化了部分异常处理的分支。参考实现思路以 Java 为例核心逻辑同样适配其他语言public class RedisLock { private static final String LOCK_SUCCESS OK; private static final String UNLOCK_SCRIPT if redis.call(GET, KEYS[1]) ARGV[1] then return redis.call(DEL, KEYS[1]) else return 0 end; private StringRedisTemplate redisTemplate; private String lockKey; private String token; private long expireSeconds; public boolean tryLock(String lockKey, String token, long expireSeconds) { Boolean result redisTemplate.execute( connection - connection.set( lockKey.getBytes(), token.getBytes(), Expiration.seconds(expireSeconds), RedisStringCommands.SetOption.SET_IF_ABSENT ), true ); if (LOCK_SUCCESS.equals(result)) { this.lockKey lockKey; this.token token; this.expireSeconds expireSeconds; startRenewalTask(); return true; } return false; } public void unlock() { stopRenewalTask(); redisTemplate.execute( connection - connection.eval( UNLOCK_SCRIPT.getBytes(), ReturnType.INTEGER, 1, lockKey.getBytes(), token.getBytes() ), true ); } }补充一个我认为很重要的细节业务代码中加锁后应该在finally块中释放锁同时捕捉InterruptedException并恢复中断标志。线程在等待锁的过程中如果被中断应尽快清理锁状态并退出避免锁资源被白白占用。4. 进阶细节锁的可靠性由什么决定4.1 锁粒度按业务资源划分而非按方法划分最容易犯的设计错误是把锁粒度定得过大。比如整个订单模块共用一个锁 keylock:order那么创建订单、支付回调、取消订单全被串行化并发能力几乎归零。正确的做法是锁 key 包含业务实体的 IDlock:order:{orderId}、lock:user:{userId}:points。举个具体例子假设订单支付回调需要扣减用户积分锁 key 设为lock:user:{userId}:points那么同一个用户的不同积分变更会互斥不同用户的积分变更完全无冲突并发度拉满。但同一用户的多个积分变更时就需要排队等待这是业务逻辑本身要求的互斥锁只是执行层面的保障。锁粒度的取舍也是一个“按需精确”的过程锁覆盖的资源范围一定要和临界区操作影响的资源范围对齐包含避免修车时把整条街封了。4.2 可重入嵌套调用场景下的隐藏需求业务方法 A 加锁后内部调用方法 BB 也需要同一把锁这时就遇到了可重入问题。如果实现不支持可重入第二次加锁会因为 key 已存在而失败导致业务异常。Redisson 的锁默认是可重入的它通过 hash 结构记录加锁次数每次重入加锁计数加一对应每次释放减一计数归零时才真正删除 key。如果自己实现锁需要在 value 中记录持有者的标识和重入计数或者用一个 ThreadLocal 维护上下文。我建议锁设计时直接考虑可重入因为业务逻辑随时可能出现多个方法共享同一把锁的场景。理解可重入背后的“持有者身份”概念比记 API 更重要——只有锁的实现能识别“当前加锁者就是锁的持有者”才能安全放行嵌套调用。4.3 主从切换与极端情况分析Redis 主从架构里写入发生在主节点读请求可以分配到从节点。加锁时 SET 命令写到主节点然后主节点异步复制到从节点。如果主节点刚收到加锁请求还没来得及同步就发生故障切换从节点被提升为主节点此时新主节点并没有这条锁记录另一个客户端就能成功加锁。这把分布式锁的互斥性就被破坏了。面对这种问题有几种应对思路如果业务对互斥要求极高使用 ZooKeeper 锁或 etcd 锁替代 Redis 锁。如果坚持用 Redis可以考虑单独部署锁专用 Redis 集群至少 5 个独立节点用 Redlock 算法降低单点故障概率——但如前文所述它依然不是绝对安全的。接受小概率的互斥失效在业务侧做补偿比如库存扣减用乐观锁的版本号校验或在下游做最终一致性对账。复杂度预算有限时我建议明确一个原则分布式锁不解决数据一致性问题它只是在默认网络、存储都正常的条件下提供一种互斥协调手段。真正需要强一致的地方应该靠业务自身的幂等和校验来兜底。5. 实战问题排查实录5.1 锁被提前清除导致并发保护失效现象明明加了锁线上还是出现库存超卖日志里能看到两个线程同时执行了扣减逻辑。排查过程我先确认锁 key 的过期时间发现设置的是 10 秒再看业务代码发现扣减逻辑里包含第三方接口调用耗时波动很大最慢的一次超过了 15 秒。于是锁在业务结束前就自动过期了第二个请求趁虚而入。解决方式有两种一是把业务中耗时的远程调用挪出临界区只保留对共享资源的操作在锁内执行二是引入看门狗续期机制。我个人强烈推荐第一种锁内操作越短越好任何网络 IO 和高延迟操作都应该尽量放到锁外。锁的干净程度直接影响系统的并发天花板上限。5.2 死锁与过期时间设置不当现象某个定时任务连续几次没跑完相关表数据没更新日志里也没有异常堆栈。排查过程发现任务方法内加锁后抛出了一个未捕获的运行时异常finally 块里的解锁代码没执行到锁一直没释放。所幸设置了 60 秒的过期时间锁最终自动清除了但在这段时间内所有依赖该锁的任务全部阻塞。结论是锁的过期时间是最后一道兜底不可省略。同时业务代码里的异常处理必须保证锁资源在finally中释放。我建议团队代码规范里明确加锁和解锁必须在同一个 try-finally 结构内任何分支 return 和 throw 都要经过 finally。5.3 性能瓶颈与锁竞争激烈现象压测时发现某个接口的吞吐量远低于预期平均耗时急剧上升锁等待时间占比很高。排查过程我先用链路追踪查看每个调用的耗时分布发现大量时间浪费在“获取锁”的等待上。再检查锁 key 的设计——最初直接把整个库存表所有商品用一把锁保护相当于把所有用户的购买行为强行串行化。解决方式把锁粒度从全表调整为每个商品 SKU 一个锁 key。调整后不同商品的购买行为完全并行同一商品的购买行为按顺序执行。这个改造基本没有改业务逻辑只是把lock:stock改成了lock:stock:{skuId}效果非常明显。5.4 时间漂移与时钟跳跃问题现象偶发地出现两个客户端同时获得锁的情况但 Redis 的 key 过期时间明显还没到。排查过程我检查了服务器 NTP 时钟发现存在 10 秒级别的时间跳跃。分布式锁的过期机制本质是基于“持有者的绝对时间 本机时钟”的如果机器时钟向前跳锁的剩余时间计算就会失真如果向后跳续期和过期时间的判定也会紊乱。应对方法给 Redis 服务器和所有业务客户端配置可靠的 NTP 时间同步服务并监控时钟跳变告警。借助依赖系统时钟的分布式算法第一步永远是确保整个集群的时钟偏差可控。这不是技巧层面的问题而是基础设施层面的基本要求。我把上述问题整理成速查表方便运维和开发快速对号入座症状可能原因排查方向推荐对策并发保护失效数据异常锁过期早于业务完成检查业务耗时最长链路缩短锁内操作、引入续期死锁任务永久阻塞异常未释放锁检查 finally 块覆盖情况强制 try-finally 释放吞吐量低锁等待严重锁粒度太大检查锁 key 的粒度按业务资源拆分锁 key偶发双客户端持锁主从切换丢锁检查 Redis 集群状态接受小概率并用业务兜底锁过期时间计算异常时钟跳跃检查 NTP 同步状态统一时钟源配置监控6. 项目扩展方向与个人心得6.1 从一把锁走向一套分布式协同体系很多项目只把锁当作一个工具类接入但实际使用中我发现一个完整的分布式锁组件还需要考虑更多配套能力锁的监控指标获取锁耗时、持有时间、等待队列长度、锁的自动降级策略Redis 不可用时切换本地锁还是直接快速失败、锁的调用链路追踪方便排查业务时序问题。更进一步锁可以和分布式事务、幂等控制、限流组件组合逐步演化为一套完整的分布式协同框架。比如结合幂等表保证同一个请求重复提交时只执行一次。结合消息队列消费位点保证同一个消息被多个消费者实例消费时互不重复。结合分布式定时任务保证同一时刻只有一个节点触发任务调度。每走一步代码的抽象层级都在上升但底层核心还是那一把可靠的锁。6.2 什么场景千万别用分布式锁分布式锁不是万能的有些场景引入它反而适得其反单机应用锁定当前可以解决的问题不需要跨进程协调本地锁更轻。操作对象本身就是“无状态”的比如纯计算任务每一个执行单元的输入输出完全独立加锁毫无意义。对性能极端敏感且不允许任何额外延迟这种场景更合适用无锁设计CAS 乐观锁、令牌桶而不是分布式锁。业务系统刚起步并发量和数据量都不大为了“架构先进”引入分布式锁反而增加运维成本。我踩过一次坑某项目早期就把所有写操作都套上 Redis 分布式锁结果并发没多高Redis 反而成了必宕机单点。后来去掉了大部分锁只在真正需要互斥的下单扣库存场景保留系统稳定性和性能都明显提升。锁应该是手术刀式的精准工具而不是所有场景都想撒一遍的胡椒粉。6.3 个人对锁的工程感悟最后分享一点我的真实体会分布式锁写起来几分钟但把它用到不掉链子需要你对业务时序、故障模式、基础设施有足够的敏感度。我常用的一个判断标准是假设这把锁在某一个瞬间彻底失效了系统会怎样如果只是多执行一次缓存重建影响可接受那可以用轻量方案如果会导致资金错账或者数据不可逆损坏那必须用更可靠的方案并且还要在业务侧增加兜底校验。锁的可靠性不是靠一把锁本身实现的而是靠“锁 业务幂等 数据校验”三个层次共同保障。把精力花在理解业务临界区的本质比研究花哨的锁算法更重要。项目里那行“锁.................”的代码背后其实藏着并发控制最核心的思考——你在用一个串行化的代价换取一份数据一致性的确定性。