我们开发中遇到“锁”这个标题时，我第一反应是：这多半是并发场景下的资源竞争问题。无论是单机多线程、多进程，还是微服务架构下多节点协同，一旦涉及共享资源的互斥访问，锁就是绕不开的核心机制。这篇文章我从分布式锁切入，结合我多年用 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 包含业务实体的 ID：lock:order:{orderId}、lock:user:{userId}:points。
举个具体例子，假设订单支付回调需要扣减用户积分，锁 key 设为lock:user:{userId}:points，那么同一个用户的不同积分变更会互斥，不同用户的积分变更完全无冲突，并发度拉满。但同一用户的多个积分变更时，就需要排队等待，这是业务逻辑本身要求的互斥，锁只是执行层面的保障。
锁粒度的取舍也是一个“按需精确”的过程：锁覆盖的资源范围一定要和临界区操作影响的资源范围对齐，包含避免修车时把整条街封了。
4.2 可重入：嵌套调用场景下的隐藏需求
业务方法 A 加锁后，内部调用方法 B，B 也需要同一把锁，这时就遇到了可重入问题。如果实现不支持可重入，第二次加锁会因为 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 个人对锁的工程感悟
最后分享一点我的真实体会：分布式锁写起来几分钟，但把它用到不掉链子，需要你对业务时序、故障模式、基础设施有足够的敏感度。
我常用的一个判断标准是：假设这把锁在某一个瞬间彻底失效了，系统会怎样？如果只是多执行一次缓存重建，影响可接受，那可以用轻量方案；如果会导致资金错账或者数据不可逆损坏，那必须用更可靠的方案，并且还要在业务侧增加兜底校验。
锁的可靠性不是靠一把锁本身实现的，而是靠“锁 + 业务幂等 + 数据校验”三个层次共同保障。把精力花在理解业务临界区的本质，比研究花哨的锁算法更重要。项目里那行“锁.................”的代码，背后其实藏着并发控制最核心的思考——你在用一个串行化的代价，换取一份数据一致性的确定性。
