分布式锁听起来像个老生常谈的技术点，但面试挂在这上面的人一抓一大把。早几年我做电商订单系统的时候，库存扣减和防重复支付两件事就把我折腾得不轻：服务从单体拆成多实例部署之后，原来顺手好用的synchronized和ReentrantLock突然全部失灵，超卖、重复回调该出现还是出现。后来把分布式锁的原理彻底吃透，我才意识到，大多数人翻车不是因为不会用某一种方案，而是根本没理解分布式环境下锁到底缺了什么、补什么才真正可靠。这篇文章就从原理到实战，把分布式锁从头到尾扒一遍，适合正在做微服务改造的开发者，也适合准备面试想把这题答得有深度的同学。
1. 为什么要写分布式锁——场景与痛点拆解
1.1 从单体到分布式的并发困局
先回到最初的问题：单体应用里，多个线程要争抢同一个资源（比如扣库存、领优惠券），我们怎么做？很简单，加一把JVM锁，像synchronized或者ReentrantLock。因为所有线程都跑在同一个进程里，共享同一块内存，锁状态放在内存中就够了，大家都能看见、都能遵守。
但是微服务化之后，情况变了。同一个服务可能部署了3个实例，每个实例都有自己的JVM和内存。线程A在实例1里拿到了内存锁，线程B在实例2里根本看不到这把锁，照样冲进来执行临界区代码。说白了，JVM锁的作用域是一个进程，而分布式场景需要锁的作用域跨越多个进程、多台机器。
这时候就需要一个所有实例都能访问的"第三方裁判"，所有实例都到这个裁判那里登记：我先来，我占了，你们等着。这个裁判就是Redis、ZooKeeper、数据库这类具备"全局可见"能力的中间件。分布式锁的本质，就是把内存中的锁状态，挪到一个大家都能访问的外部存储上。
1.2 分布式锁的典型使用场景
很多人觉得分布式锁就是面试题，实际项目里用不上，这是误解。但凡你的系统是集群部署，又存在跨实例的共享资源写入，就逃不掉分布式锁。几个最常见的场景：
库存扣减与秒杀。订单系统最典型的场景。用户同时下单，要扣减同一个商品的库存。如果每个服务实例各自扣各自的，库存数据必然对不上。用分布式锁保证同一时刻只有一个请求在扣减某个商品的库存，其他请求排队。
防止重复支付与幂等控制。支付回调往往不保证只调用一次，同一个订单的回调可能到达多次。用分布式锁保证同一个订单的支付处理逻辑同一时刻只执行一次。这个场景对锁的要求还特别高，宁可锁多等一会，不能出现并发处理同一笔订单。
定时任务的集群互斥执行。集群里的每个实例都会启动定时任务，如果不同步，同一个报表会被生成三份，同一个奖励会被发放多次。给任务名加一把分布式锁，谁抢到锁谁执行。
分布式缓存重建。缓存过期瞬间大量请求同时回源查数据库，这就是缓存击穿。用分布式锁让只有一个请求去重建缓存，其他请求等待或者直接返回旧值。
分布式事务中的资源锁定。跨服务调用链路上，需要对某个业务实体先加锁再做一系列操作，防止其他链路同时修改。
可见，分布式锁解决的是分布式系统里"多个执行体抢同一份资源"的同步问题，是保证数据一致性的底层基础组件。你在面试里能把场景说到这个粒度，再结合自己项目里的具体例子，说服力是远大于背定义的。
2. 分布式锁的设计模型：三要素与两条铁律
2.1 锁的本质——互斥、可重入与自动释放
不管用什么中间件实现，分布式锁在功能上都要满足几个基本性质。
首先是互斥性。这是锁存在的唯一理由：任意时刻，只能有一个客户端持有锁。这句话说起来简单，实现的时候反而是最容易出问题的。比如Redis主从切换导致锁丢失，就可能出现两个客户端同时持有锁，互斥性被破坏。
其次是可重入性。同一个客户端在已经持有锁的情况下，再次请求同一把锁，应该直接成功。这个在业务代码里很常见：A方法加了锁，内部又调用了B方法，B方法也加了同一把锁。如果锁不支持可重入，就会把自己锁死。Redis的分布式锁默认不直接支持可重入，需要在value里记录持有者信息和重入次数，或者用ThreadLocal记录，大家经常忽略这个细节。
然后是自动释放。持有锁的客户端崩溃了，锁也必须能释放掉，否则其他客户端永远等下去。这就引出分布式锁设计中最重要的一个机制——超时时间。不管是Redis的EXPIRE过期时间、ZooKeeper的会话超时，还是数据库的事务超时，本质上都是给锁加上"保底释放"的能力。
2.2 分布式锁必须满足的可靠性红线
基础性质之上，工程上还有几条可靠性要求，面试里能不能拿高分就看对这些线的理解。
死锁不可出现。只要客户端崩溃，锁必须自动释放。这里要特别注意的是，不能把释放动作完全寄托在客户端代码上——你代码里写了finally里释放锁，可如果Redis连接断了呢？如果进程被强制kill了呢？所以必须有中间件侧的兜底过期机制。
互斥性尽量不被破坏。这是最难的一条。Redis主从切换、ZooKeeper会话假超时，都可能让两个客户端同时认为自己是锁的主人。严格来说，任何分布式系统里都存在这种不确定性的窗口，分布式锁只能尽量缩小这个窗口，不能绝对消除。比如Redlock算法就是为了缩小这个窗口而设计的，但代价是复杂度上升。
高可用与低延迟。锁服务本身不能成为系统的单点。Redis挂了锁服务就不可用，那就需要主从、哨兵、集群。延迟方面，锁的获取与释放必须足够快，不然就是抢锁5毫秒、业务执行50毫秒，整体接口性能就被拖垮了。
2.3 三类实现方案的横向对比
目前主流的分布式锁实现方案就三套：Redis方案、ZooKeeper方案、数据库方案。每种方案各有侧重，没有银弹，关键看业务场景更在意什么。
| 方案 | 性能 | 可靠性 | 复杂度 | 典型实现 |
|---|---|---|---|---|
| Redis | 极高，纯内存操作 | 中等，主从切换可能丢锁 | 低，接入简单 | SETNX + Lua、Redlock |
| ZooKeeper | 中等，磁盘与ZAB协议开销 | 高，顺序节点天然可靠 | 中，需引入ZK组件 | 临时顺序节点 |
| 数据库 | 低，行锁与事务开销大 | 高，依赖数据库ACID | 低，不用引入新组件 | SELECT FOR UPDATE、乐观锁version |
单从性能看，Redis是压倒性优势，所以实际落地中Redis方案用得最多。ZooKeeper胜在可靠性，适合对一致性要求极其严苛的场景。数据库方案最大的价值是"不需要额外引中间件"，在架构比较轻、不想引入新组件的小项目里可以临时顶一顶，但性能瓶颈在那里摆着，并发大一点就撑不住。
3. Redis分布式锁：从入门到实战
3.1 最简版本：SETNX + EXPIRE 的经典组合与隐患
很多人学Redis分布式锁，第一条代码就是SETNX配合EXPIRE。逻辑上很简单：SETNX表示"如果key不存在才设置成功"，谁设置成功谁就拿到锁；拿到锁之后再用EXPIRE给key加一个过期时间，防止持有者崩溃导致死锁。
伪代码如下：
# 获取锁 SETNX lock_key client_id EXPIRE lock_key 30 # 执行业务 # 释放锁 DELETE lock_key这个版本看着能用，问题却致命：SETNX和EXPIRE是两条命令，非原子操作。如果SETNX执行成功了，客户端刚准备执行EXPIRE时突然宕机，key就没有过期时间，这把锁永远不会释放，其他客户端全部卡死。这个bug在真实环境里出现得相当频繁，尤其是网络抖动或进程被kill的时候。
另一个坑是释放锁时直接用DELETE。假设客户端A的锁到期没执行完，客户端B抢到了锁；这时A终于执行完了，一个DELETE就把B的锁删了，C又趁机进来……锁的互斥性完全失效。
所以这个"最简版本"只适合在单机Redis且业务极短的测试环境里玩玩，千万别上生产。
3.2 标准版本：SET 原子命令 + Lua 释放锁
正确打法是把获取锁的原子性交给Redis官方建议的SET key value NX EX命令，一条命令同时完成"不存在才设置"和"设置过期时间"两个动作：
SET lock_key client_id NX EX 30NX保证只有key不存在时才设置成功，EX 30指定30秒过期。这样一来，获取锁是原子的，不存在半路崩溃留死锁的问题。
这里有个很容易被忽略的细节：value必须是全局唯一的客户端标识，一般用UUID或者"业务ID + 线程ID"拼接。为什么要唯一？因为释放锁的时候要校验"这把锁是不是我持有的"。
释放锁的逻辑不能直接用DELETE，要先比对value是否等于自己的client_id，等于才删。两个操作必须原子执行，于是要借助Lua脚本：
-- 释放锁的Lua脚本 if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 endJava里用Redisson调用的话，大致长这样：
// 获取锁 RLock lock = redisson.getLock("order:" + orderId); // 尝试加锁，最多等待10秒，锁30秒自动释放 boolean locked = lock.tryLock(10, 30, TimeUnit.SECONDS); try { if (locked) { // 业务处理 } } finally { if (locked) { lock.unlock(); } }这套方案相比最简版本，把"获取锁"和"释放锁"两个关键路径都做成了原子操作，已经可以应对绝大多数业务场景。我做过不少订单系统的防重复处理，直接落地这套方案，稳定性是够用的。
3.3 Redlock 多节点锁的原理与争议
标准版本还有一个隐藏问题：它只依赖单个Redis主节点。如果这个节点发生主从切换，从节点还没同步锁数据就被提升为主节点，另一个客户端过来加锁，就会成功，于是两个客户端同时持有锁。这在很多场景下不可接受。
Redis作者Antirez提出了Redlock算法来解决这个问题。思路是：不依赖单个Redis实例，而是部署N个独立的Redis节点（官方建议N=5），客户端依次向所有节点执行加锁操作，只有当超过半数（N/2+1）节点加锁成功，并且加锁总耗时小于锁的有效期，才算加锁成功。释放锁时，向所有节点发起释放。
Redlock的核心思想是"少数节点不可用不影响整体锁的判定"。比如5个节点里有2个宕机，你还能在3个节点上加锁成功，这个锁依然是有效的。即使某个节点出了bug，因为多数节点正常，两个客户端同时拿到锁的概率被大幅压低。
但Redlock并不完美，业界争论很大。著名分布式系统专家Martin Kleppmann专门写过文章质疑，核心问题有两个：
一是GC停顿。Java客户端的垃圾回收会造成长时间停顿，比如暂停了30秒。客户端在GC前申请到了锁，GC期间锁过期了，另一个客户端拿到锁执行完并释放，然后第一个客户端才苏醒，继续执行临界区代码，此时它以为自己还拿着锁，其实锁已经换主人了。Redlock无法解决这个问题。
二是时钟漂移。Redlock假设各个Redis节点的时钟是一致的，但服务器时钟可能被NTP校准，出现时间跳跃。一个节点上的锁提前过期了，其他节点还没过期，导致客户端觉得自己在多数节点上拿到了锁，实际上锁的有效期已经不足。Antirez和Martin来回辩论了好几轮，结论是：满足一定条件下（节点时钟步调基本一致、没有长时间GC），Redlock能提供很强的互斥性，但不能在绝对意义上保证。
我在生产环境一般用Redisson的RedissonLock，它的底层就是改良版的Redlock思路。但在设计业务的时候，我会额外留一手：即使锁出现极端的双持有情况，业务侧的数据幂等校验也能兜住。比如防重复支付，在支付回调里先查订单当前状态，已经是"已支付"就直接返回，这层防护和分布式锁是互补关系，而不是把安全完全押在锁上。
3.4 续约机制：看门狗是怎么解决锁过期的
锁过期问题比想象中更隐蔽。假设你设置锁30秒过期，但某次业务执行需要40秒——执行到25秒时锁自动过期了，另一个客户端B拿到锁进来，两个客户端同时处理同一笔业务。这是标准的"锁提前过期"事故。
解决办法是续约（watchdog）。Redisson的实现思路是：加锁成功后，启动一个后台定时任务，每隔锁有效期三分之一的时长（默认锁30秒，就每10秒续一次）检查锁是否还被当前线程持有，持有则把过期时间重新设置为30秒。业务执行完毕，显式释放锁，后台任务随之取消。
这个机制保证了：只要客户端进程还活着、业务还在跑，锁就不会因为时间到期而提前释放。只有当进程崩溃，心跳停止，watchdog不再续约，锁才会在一定时间后自动释放。这正好命中分布式锁"既要自动释放防止死锁，又不能提前释放破坏互斥"的两个要求。
不过续约也不是万能的。如果业务线程发生了长时间GC暂停，watchdog线程本身也可能被暂停，无法及时续约，锁照样过期。这也是任何分布式锁方案里都无法绝对消除的窗口，遇到这种极端情况，还是得靠业务层的幂等逻辑兜底。
4. ZooKeeper 与数据库实现方案深挖
4.1 ZooKeeper 临时顺序节点的实现思路
ZooKeeper方案在可靠性上通常被认为优于Redis。核心是借助ZK的两种节点特性：临时节点（Ephemeral）和顺序节点（Sequential）。
具体做法是这样的：
- 客户端在锁路径下创建一个临时顺序节点，比如
/locks/order_1001/下面创建子节点，ZK会自动编号：_c_0000000001、_c_0000000002。 - 客户端获取当前路径下所有子节点，按序号排序，判断自己创建的节点是不是序号最小的那个。
- 如果序号最小，说明自己抢到了锁；否则，监听前一个序号节点的删除事件，然后进入等待。
- 持有锁的客户端处理完业务，删除自己的临时节点；或者客户端崩溃，ZK检测到会话超时，自动删除临时节点。
- 监听到前一个节点被删除的客户端被唤醒，再次确认自己是不是序号最小，如果是，就获得锁。
这个方案的可靠性来自ZK的ZAB协议：所有节点的数据是强一致的，同一个路径下子节点的创建顺序全局唯一，不会出现Redis那种主从切换丢锁的问题。临时节点和会话绑定，客户端挂了，会话结束，节点消失，锁自动释放，不需要额外设置超时时间。
性能上，ZK方案肯定比Redis慢，因为写节点要经过ZAB协议的半数确认，涉及磁盘持久化。但在对一致性要求极高、并发量不算大的场景（比如分布式任务调度、配置管理），ZK依然是很合适的方案。
4.2 数据库悲观锁方案：SELECT FOR UPDATE
数据库方案最大的好处是"不引入新组件"，用已有的业务数据库就能实现。最典型的悲观锁实现就是SELECT ... FOR UPDATE：
-- 在事务里执行 BEGIN; SELECT * FROM order_lock WHERE biz_key = 'order:1001' FOR UPDATE; -- 执行业务逻辑 -- 提交事务，行锁自动释放 COMMIT;原理是FOR UPDATE会对命中的行加排他锁，其他事务想再对这一行加锁时会被阻塞，直到当前事务提交或回滚。这实际上就是分布式锁——所有服务实例都通过同一个数据库的行锁来互斥。
优点是实现极其简单，还天然支持可重入，同一个事务里多次SELECT FOR UPDATE不会锁死自己。缺点是性能天花板很低。数据库的行锁竞争、事务间的阻塞等待、连接长时间占用，这些都是瓶颈。另外，还要小心事务超时和死锁的问题——FOR UPDATE的事务执行时间一旦超过数据库的innodb_lock_wait_timeout，锁等待会被中断，抛异常。
这个方案适合一小类场景：业务表本身就在数据库里，并发量不高，比如后台管理系统的操作锁、低频的批处理任务互斥。如果是为了电商秒杀这种高并发场景，数据库锁基本顶不住。
4.3 数据库乐观锁方案：version 字段
悲观锁之外，数据库还有一条更轻量级的路线——乐观锁。核心思想是：不加锁，更新时校验版本号对不对，不对就放弃。
实现方式是给数据表加一个version字段：
UPDATE inventory SET stock = stock - 1, version = version + 1 WHERE product_id = 1001 AND version = 3;UPDATE影响行数为1，说明version匹配成功，库存扣减生效；影响行数为0，说明version已经被其他事务改掉了，当前更新失败，需要重试。
乐观锁的本质是利用数据库行更新的原子性来保证"读取-判断-写入"的原子性，它没有显式的锁等待，不会阻塞其他事务，性能比悲观锁好不少。但它只适合"单个资源更新"这种简单场景。一旦临界区是多条记录的复杂操作，或者必须保证读操作的绝对一致性，乐观锁就会显得力不从心。
我自己的经验是：乐观锁最适合库存扣减这种单行更新的场景，尤其适合并发冲突概率低的业务。冲突频繁时，大量更新失败重试反而加大了数据库压力，反而不如悲观锁或者Redis锁。面试里提到乐观锁，能说出"适合读多写少、冲突少"这个边界，比单纯报答案有用得多。
4.4 三类方案选型的关键判断依据
聊这么多，最后落到选型上，个人建议按三个维度来判断。
第一个维度：并发量。每秒几千以上的抢锁请求，直接选Redis。ZK和数据库方案在高压下要么性能不足，要么连接被占满。
第二个维度：一致性要求。如果锁被重复持有，会产生资金损失、数据严重错乱，那就往ZooKeeper方向靠。如果只是防止重复操作，偶尔的极小概率并发可通过幂等兜底，Redis已经完全够用。
第三个维度：基础设施现状。项目里已经有Redis，就优先Redis；ZooKeeper也已经是集群的一部分，那就用ZK；啥中间件都不想加，并且并发低，数据库方案最省事。
没有绝对的最优，只有结合场景的最合适。
5. 高频面试题与线上故障排查实录
5.1 分布式锁高频面试题与答题框架
分布式锁是面试高频题，问法通常从浅到深，我把几个典型问题和答题框架整理出来。
"分布式锁有哪些实现方式？"列出Redis、ZooKeeper、数据库三种，分别说一句核心原理和优缺点。注意顺序：先说Redis，因为它最常用；再说ZK，突出可靠性；最后补数据库，说明适用低并发场景。
"Redis分布式锁怎么防止死锁？"关键答出两点：加锁时设置过期时间，并且加锁动作要原子（SET key value NX EX）；释放锁用Lua脚本校验value后删除。再补一句：生产环境用Redisson的watchdog自动续约，防止业务未结束锁先过期。
"为什么释放锁之前要判断value？"核心是为了防止误删别人的锁。场景复述：线程A的锁到期，线程B拿到锁，A执行完后直接DELETE会把B的锁删掉。所以value必须是全局唯一标识，释放时先比对再删除，并且整个过程用Lua保证原子。
"锁过期了线程A还在执行，怎么办？"答题框架：第一层，watchdog定时续约；第二层，业务上加幂等校验兜底；第三层，尽量缩短业务执行时间，把锁粒度放细。
"Redlock解决了什么问题？有什么缺点？"答出"多节点+半数以上加锁成功"的思路，再说GC停顿和时钟漂移两个缺陷。能提一句"Redlock提供的是概率意义上的强互斥"就更有深度。
"ZK实现的分布式锁和Redisson有什么区别？"核心差异在锁的释放机制和一致性：ZK基于临时顺序节点，客户端会话自动释放锁，一致性由ZAB协议保证；Redis基于过期时间和Lua释放，一致性在主从切换时可能被破坏。性能上Redis快一个数量级。
"分布式锁的数据结构怎么设计？value里放什么？"Redis的value放客户端唯一标识，可以扩展成"业务标识:线程标识:重入次数"来支持可重入；key一般按业务维度命名，如lock:stock:1001。
"怎么测试分布式锁是否有效？"写并发测试脚本模拟多线程同时抢锁，统计是否所有临界区代码都被串行执行；再模拟持有锁的实例宕机，确认锁能否在过期时间后自动释放；还可以做一次主从切换测试，观察是否出现双持有。这个实操思路面试亮出来很加分。
5.2 一次线上故障排查实录：锁被误删
之前带团队做过一个优惠券发放系统，上线后监控到偶发的"同一用户重复领券"。查日志发现两位用户在同一毫秒级各自领了同一张券，明显是分布式锁失效。排查过程值得分享。
第一层排查，先看Redis里锁的存活状态，发现锁存在且有过期时间，初步排除死锁。第二层排查，把加锁和释放锁的日志打上时间戳，发现线程A释放锁的时刻晚于线程B获取锁的时刻——这说明A释放锁时删掉的其实是B的锁。再往深看，A加锁时设置过期时间10秒，业务里还嵌了一个第三方接口调用，偶尔响应超过10秒，锁到期了业务没结束，B就拿到锁了。
根因确认：锁过期 + 未校验value直接DELETE。修复做了三件事：升级Redisson，开启watchdog续约；释放锁脚本加上value校验；给第三方接口设置超时熔断，阻断响应过长拖垮业务。
这个案例的核心经验是：锁的每个环节都要闭环测试，不能只在正常路径上模拟。线上真正出问题的，几乎都是异常路径：网络抖动、接口超时、GC停顿、节点故障，这些在开发和测试环境很难触发，但在生产环境永远存在。
5.3 避坑清单与最后一点心得
最后把我这几年踩过的坑整理成一个速查清单，方便大家对照自查：
| 坑点 | 问题描述 | 规避措施 |
|---|---|---|
| SETNX与EXPIRE分离 | 非原子，半路宕机导致死锁 | 使用SET key value NX EX原子命令 |
| 释放不校验value | 误删他人锁，互斥失效 | Lua脚本比对value后再DEL |
| 锁过期业务未结束 | 两个线程同时执行临界区 | Redisson watchdog自动续约 + 业务幂等兜底 |
| 主从切换丢锁 | 从节点未同步锁数据即提升为主 | 多节点Redlock方案 |
| 锁粒度太大 | 高并发下大量请求排队等待，吞吐暴跌 | 按业务维度拆细key，如按商品ID、用户ID |
| 不支持可重入 | 同线程加锁后递归调用自己死锁 | value记录线程标识与重入次数，或使用可重入封装 |
| 监听ZK羊群效应 | 大量客户端同时监听同一节点，释放时惊群 | 只监听前一个顺序节点 |
分布式锁这东西，接口就那么几个方法，原理也不复杂，难点全在极端场景下的可靠性。我的体会是：设计阶段多花十分钟想清楚"如果这个锁失效，业务会发生什么"，比上线后排查几个小时有价值得多。后续如果你想深入，可以再看看Redisson源码里watchdog的实现方式，以及ZK客户端的会话重连机制，把底层原理啃透，面试和实战都会从容很多。
