分布式锁这个话题，几乎每一轮后端面试都会出现。我最近把近两年遇到的、还有身边同事被问到的分布式锁面试题归拢了一下，大概凑了一百道：从最基础的“什么是分布式锁”，一路问到RedLock算法到底靠不靠谱、看门狗续期会不会失效、主从切换丢锁怎么办。这篇不打算把一百道题原封不动列出来——那样看着挺全，但说实话背完也忘得差不多了。我按考点把题目重新归了类，挑出真正会反复问、也最见火候的几个方向展开讲：答案是什么、为什么是这么设计、面试官还没明说的潜台词是什么。先说你最关心的：分布式锁要掌握到什么程度，才能让面试官觉得你是真干过，而不是纯背题。
1. 分布式锁面试考点地图：先知道面试官在考什么
1.1 一百道题背后的实际考点分布
我把那一百道题重新过了一遍，发现很多题其实是同一个考点的不同问法。比如“Redis分布式锁怎么实现”“setnx和set NX EX有什么区别”“为什么不用setnx加锁”这几道，本质都在考Redis加锁这个动作的可靠性。真正需要重点准备的，其实是下面这五个方向。
| 考点方向 | 题目占比 | 典型问题 |
|---|---|---|
| 使用场景与前置判断 | 10% | 什么业务需要分布式锁？单体锁为什么不行？ |
| Redis分布式锁原理 | 30% | set NX EX的细节、过期时间怎么设、解锁为什么用Lua |
| 可靠性边界 | 25% | 主从切换丢锁、锁误删、锁超时、GC停顿 |
| 其他方案（ZK/数据库） | 20% | ZK锁的底层原理、和Redis锁怎么选型 |
| 高阶设计与实战 | 15% | 可重入锁、续期机制、Redisson源码、线上排查 |
这个分布很能说明问题：面试官根本不指望你把分布式锁所有实现都背下来，他真正在意的是“你知不知道这东西会出问题，以及出问题了怎么兜底”。所以后面我会把重点放在可靠性边界和高阶设计上，这两块才是区分“用过”和“会做”的分水岭。
1.2 面试官问分布式锁的三个潜台词
同一个问题，不同水平的候选人给出的答案差别很大。比如“Redis分布式锁怎么实现”，初级回答是“用setnx”，中级的会补上过期时间和Lua脚本解锁，高级的会把主从切换丢锁、RedLock争议、fencing token都说清楚。面试官其实是在用这个问题，探测你对分布式系统的理解深度。
我自己的理解是，分布式锁的考察分成三层。第一层是会不会用API，只要写过代码的人基本都知道Redisson的lock和unlock怎么调。第二层是懂不懂原理，比如为什么加锁命令必须包含过期时间、为什么解锁要校验value。第三层是有没有踩过坑，比如锁到期业务没跑完怎么办、Redis主节点挂了从节点还没同步锁怎么办。绝大多数候选人停在第二层，能讲到第三层的，面试官基本会给正向评价。
所以这篇文章的章节安排，本质上是按这三层来组织的：先讲场景和基础，再深挖Redis原理，接着是ZK和数据库对比，最后是进阶设计和实战排查。你按这个思路去准备，比单纯背题有效得多。
2. 基础题：分布式锁到底在解决什么问题
2.1 单机锁为什么管不住多个服务节点
面试高频开场题就是“你为什么要用分布式锁，单机的synchronized不行吗”。这道题看着简单，其实考的是你对多实例部署的基本认知。建议大家先想清楚一个前提：现在的后端服务为了搞高可用和横向扩容，几乎不会只部署一个实例，而是N个进程一起对外提供服务，前面挂负载均衡把请求分发到不同节点上。
在这种情况下，synchronized和ReentrantLock都锁不住跨进程的共享资源。因为这两把锁是JVM内存层面的，只对当前进程内的线程生效。假设库存数量存在数据库里，同一时间来了两个请求，分别打到服务A和服务B上，A和B各自的synchronized只能锁住自己进程里的线程，两个进程还是会同时读到库存20，然后各自扣减，最终库存只扣了1而不是2。这就是典型的并发超卖。
我面试时喜欢用“小区门禁”来解释这个事。小区只有一个大门，里面每个楼栋还有一个楼栋门，楼栋保险门只能拦住本栋的访客，拦不住从别栋绕过来的人。服务部署多个节点以后，进程级锁就是楼栋门，分布式锁才是小区那扇真正拦住所有人的大门。这个类比在解释给非技术同学听的时候很好用。
2.2 一个合格的分布式锁要满足的五个条件
既然单机锁不行，那分布式锁得长成什么样才合格？面试里经常从这个问题往下引。我总结成五条，每一条背后其实都对应一个具体的坑。
第一是互斥性，同一时刻只能有一个客户端持有锁，这是分布式锁的底线。第二是防死锁，客户端持有锁期间崩了或者网络断了，锁必须能自动释放，否则其他所有客户端都会卡死，这对应Redis里的过期时间。第三是可重入，同一个客户端如果已经持锁，后续再请求锁应该能直接拿到，对应可重入锁的计数逻辑。第四是高可用，获取锁和释放锁的过程不能因为某个节点挂了就完全不可用。第五是性能要好，加锁解锁本身不能太重，否则成为系统瓶颈。
很多人在面试时只说“互斥、防死锁、可重入”三条，其实第四条和第五条才是面试官判断你有没有真实场景经验的分界线。尤其是高可用这一条，后面要讲的主从切换丢锁问题就是冲着它来的。
2.3 高频使用场景：秒杀、定时任务、防重
紧接着基础题的就是“你们业务里哪些地方用了分布式锁”。这道题不准备的话，现场容易想不起来，或者只会说“秒杀扣库存”。实际上分布式锁的典型场景至少能说四类。
第一类就是库存扣减，这也是最经典的一类：秒杀活动的库存总量有限，并发请求大量涌入，必须用锁保证扣减操作的原子性。第二类是定时任务的多节点执行控制，很多系统为了防止定时任务重复执行，干脆配了多个节点都跑同一套任务，这时候需要用分布式锁选出一个执行者，其他节点等着就行。第三类是幂等控制，客户重复提交订单、重复点击按钮时，用分布式锁保证同一个订单的创建过程只跑一次。第四类是分布式系统中的资源协调，比如多个服务要批量处理同一批数据，用锁避免重复消费。
这几类场景本身不难，但面试时最好能补一句“选择分布式锁不代表所有并发都靠锁处理”，可以结合分库分表、幂等键、消息队列削峰等手段综合设计。能说出这层取舍，答案的层次一下就上去了。
3. Redis分布式锁：最高频实现，也是最大的坑
3.1 加锁从setnx到set NX EX的演进，为什么必须带过期时间
Redis分布式锁是面试里绝对的核心，必须先答好“你会怎么实现”。大家最早接触的版本基本是setnx命令，也就是SET if Not eXists：key不存在才设置成功，多个客户端同时执行，只有一个能成功，返回1的拿到锁。这个思路是对的，但老版本写法有个致命问题：这条命令不会自动设置过期时间。
假设客户端A用setnx加锁成功，结果业务执行到一半，程序突然崩了，或者机器宕机了。因为根本没设过期时间，这个key就永远留在Redis里，后面所有客户端都加锁失败，整个链路直接瘫痪。这就是所谓的死锁。所以后来演化成把setnx和expire两条命令分开写：先setnx，再expire设置过期时间。但两条命令不是原子的，第1条刚执行完、第2条还没执行时进程崩了，死锁问题依然存在。
现在大家都用一句话解决：SET key value NX EX 30，也就是set命令带上NX（不存在才设置）和EX（过期时间），这样“判断是否存在+写入值+设置过期时间”就是原子操作。既然有现成的正确写法，面试时就不要再去吹setnx了，直接答“用set命令的NX和EX参数”，再补一句“不管是setnx还是set，核心逻辑都是利用Redis单线程串行执行命令来实现互斥”，这就显得你清楚底层原理。
3.2 解锁为什么必须用Lua脚本，value校验是怎么回事
加锁讲完，面试官必问解锁。很多人想都不想就说“删掉key就行，del lock”，这又是一个坑。假设加锁时设的value是“clientA”，锁key是“order_lock”，业务还没执行完，锁因为过期时间到了自动释放了，这时候另一个线程B拿到锁也开始干活。偏偏A在B拿锁之后也执行完了，A执行del order_lock，等于把B的锁给删了。
这个场景叫锁误删，实线上很常见。解决办法是给每个客户端加锁时生成一个唯一标识作为value，比如UUID；解锁时先判断当前key的value是不是自己生成的那个UUID，是才能删，不是就不删。但这里有个细节：判断和删除是两个动作，如果分开执行，判断完刚准备删，锁又过期被别人拿走了，你还是会把别人的锁删掉。所以这两个动作必须原子地一起执行，Redis里实现原子性的办法就是Lua脚本。
我贴一个标准解锁脚本：
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end把这段脚本通过EVAL指令发给Redis，Redis会保证脚本内的所有操作是原子的，中间不会有其他命令插入。面试时能把value校验和Lua脚本的原子性讲出来，这道题就过关了。
3.3 锁过期时间设多少合适，业务没执行完怎么办
加锁设过期时间看起来简单，实际上是个两难问题。时间设短了，业务还没跑完锁先过期了，其他线程趁虚而入，互斥性被破坏；时间设长了，万一持有锁的节点宕机，其他线程要等很久才能拿到锁，业务上表现为大面积超时。很多团队默认设30秒，但30秒也不是安全的，极端情况下大事务、慢SQL、GC停顿都可能超过这个时间。
解决这个问题的思路不是精确配一个“完美时长”，而是让锁的有效期跟着业务跑，核心机制是续期，也叫看门狗。Redisson这个库里的做法是：加锁成功后起一个后台定时任务，每过大概三分之一锁时长就自动给锁续期一次。比如你设锁30秒失效，后台每10秒续一次，只要业务还在跑，锁就一直续；业务执行完了，显式调用unlock，同时把这个后台续期任务停掉。
面试官如果追问“你们项目里有没有遇到过锁过期导致并发问题”，就可以顺着这个机制答。再说句实在话，绝大多数公司不会自己写续期逻辑，都是用Redisson现成的lock.tryLock()，真正要理解的是它背后的设计思想：锁的超时不能拍脑袋定死，要有动态调整的兜底。
3.4 主从切换丢锁和RedLock，这道题最见功力
如果说前面几道是基础分，那“Redis主从切换的时候锁会丢吗”就是拉开差距的题。Redis为了高可用，通常是主从架构加哨兵或者Cluster模式，写操作在主节点，主节点把数据异步复制给从节点。问题就出在“异步”上：主节点刚写入锁key，还没来得及同步给从节点，主节点就挂了。哨兵把某个从节点提升为新主节点，这个新主节点里并没有这把锁，其他客户端自然就能重新加锁成功。
你想想这个场景有多恐怖：客户端A还在执行订单支付流程，客户端B已经把同一把锁拿到手了，也开始执行支付流程。两个客户端同时觉得自己握着锁，互斥性彻底失效。RedLock算法就是为了解决这个问题提出的。它的思路是把锁同时加在N个独立的Redis节点上（一般建议N取奇数，比如5），只要超过N/2个节点加锁成功，就认为加锁成功；释放锁时对所有节点都释放。
但RedLock争议很大，分布式系统领域的大佬Martin Kleppmann专门写过文章批评它。他的核心观点之一是：即使RedLock在大多数节点上成功了，依然无法抵御长期GC暂停和时钟跳跃带来的失效问题。比如客户端A加锁成功，然后发生一次长达40秒的Full GC，锁过期了，客户端B拿到锁开始干活，A的GC结束后又接着跑之前的业务逻辑，两边就冲突了。你就算把锁加到所有节点上，也扛不住进程自身长时间停滞。面试时能把这个背景讲出来，说明你真的研究过这个问题，而不是只会背结论。
4. 除了Redis，ZooKeeper和数据库也能实现分布式锁
4.1 ZooKeeper临时顺序节点原理，以及为什么不会惊群
Redis锁讲了那么多坑，面试官通常会话锋一转：“你们有没有考虑过用ZooKeeper来实现分布式锁？”这题考察的是你方案选型的能力，不是让你把ZK背得多熟。ZK实现锁的基本思路是利用临时顺序节点。
具体流程是这样的：客户端往指定锁目录下创建一个临时顺序节点，比如/lock/lock_0000000001，然后查一下这个目录下所有子节点，按序号排序。如果自己创建的节点是最小的那个，说明拿到了锁；如果不是最小的，就对自己前一个节点注册一个监听，等它被删掉后再去争抢。因为是顺序节点，所有客户端都在排队，每个客户端只需要盯住自己前一个节点，不用所有人都盯着最大那个节点，这就避免了“羊群效应”，也叫惊群效应。
临时节点还有一个关键特性：客户端和ZK之间断开连接后，节点会自动删除。这意味着持有锁的客户端崩了、网络断了，锁也会自动释放，不需要依赖过期时间，也就没有Redis那种“业务没跑完锁先过期”的问题。面试时可以拿这个点和Redis对比：ZK的锁更偏向CP，能提供线性一致性；Redis锁偏向AP，高并发场景下更轻快。
4.2 数据库悲观锁和乐观锁，面试中的加分项
说完Redis和ZK，面试官有时还会问一句“只用数据库能不能实现分布式锁”。大部分人听到“数据库”就只想到唯一索引，这个方向对，但可以再补充悲观锁和乐观锁两个思路。
悲观锁就是利用SELECT ... FOR UPDATE。比如要操作订单表里id为1001的订单，先执行SELECT * FROM order WHERE id = 1001 FOR UPDATE，把这一行锁住，直到事务提交才释放。数据库锁是天然互斥的，多个事务同时执行这条语句时只有一个能成功，其余全部阻塞等待。优点是实现简单、严格可靠；缺点是并发能力受数据库连接限制，而且如果事务里操作时间长，会占用数据库连接不释放，容易把连接池打满。
乐观锁的思路相反，不锁行，而是靠版本号或者条件更新。比如UPDATE order SET stock = stock - 1 WHERE id=1001 AND stock = 20，只有当库存还是20的时候才更新成功，否则失败重试。这其实不叫“锁”，只是一种防止并发覆盖的手段，但它能解决“超卖”这类问题。乐观锁在秒杀这类读多写少、冲突偶尔发生的场景下性能很好，但冲突率高的场景会大量重试，体验很差。唯一索引方式则适合“防重”场景，比如支付回调只希望处理一次，给业务主键建唯一索引，第二次插入直接报错，比分布式锁更轻量。
4.3 三个方案怎么选，给出你的判断依据
面试里常见的问题是“Redis、ZooKeeper、数据库，分布式锁选哪个”。这题没有标准答案，关键在于你有没有自己的判断逻辑。我的回答思路是分三个维度：一致性要求、性能要求、运维成本。
一致性要求高、对极端并发下的互斥性有强要求，选ZK，它能保证分布式环境下严格的线性一致性。性能要求高、基础设施已经有了Redis，且能接受极小概率的锁失效，选Redis，它最简单、最快，绝大多数业务场景完全够用。数据库方案一般做兜底或者做防重，除非公司里没有Redis也没有ZK，否则不建议用数据库当主力分布式锁，性能和可用性都容易出问题。
面试时如果能加一句“选型要先问你自己的业务底线是什么，能接受什么程度的风险”，而不是直接报一个方案名字，这个答案就比较成熟了。我见过几个候选人都是不说套话、直接举自己团队例子，比如“我们之前用Redis，后来因为主从切换丢过一次锁，讨论过要不要换ZK，最后发现业务可以容忍偶发重复就继续用Redis了”，这种回答明显更有说服力。
5. 进阶设计：可重入锁、续期机制和时钟跳跃
5.1 Redis怎么实现一个可重入锁，底层数据结构是什么
面试题问到“分布式锁怎么处理重入”，很多人的第一反应是用ThreadLocal记录当前线程是否持锁。这个思路能用，但Redisson并不是这么干的。Redis实现可重入锁的经典做法是用Hash结构：key还是锁的名字，hash里的field存客户端/线程的唯一标识，value存一个计数器。
每次加锁时，判断hash里field是否存在。如果不存在，说明是第一次加锁，hset写入field=线程标识，value=1，同时设置过期时间；如果field已经存在且等于当前线程标识，说明是同一个线程重入，就把value加1。释放锁时，先把计数器减1，减到0才真正删除整个key。这样同一个线程多次lock就对应多次计数，只有计数归零锁才真正释放，和JVM里ReentrantLock的思路一模一样，只不过存储状态的地方从内存换成了Redis。
这里有个容易被追问的细节：可重入锁的执行过程由好几个Redis命令组成，比如hset、hexists、hincrby、expire，为什么不会出现并发问题？答案和单线程模型有关：Redis所有命令都是单线程串行执行的，但一串命令之间如果被其他客户端命令插进来，还是会出问题。所以Redisson这些操作全部封装成了一段Lua脚本，脚本整体交给Redis执行，保证不可分割。
5.2 看门狗续期的底层逻辑，以及它解决不了的问题
前面提到看门狗续期，这里把细节讲透。Redisson默认的锁过期时间其实是30秒，也就是leaseTime。加锁成功后会启动一个定时任务，每隔锁时间的三分之一，也就是10秒，检查一次锁是否还被当前线程持有，如果持有就重新设置过期时间到30秒。这个定时任务在unlock之后会被取消，避免锁一直续期不释放。
这个机制确实解决了“业务执行时间超过锁时长”的问题，但它有一个前提：进程本身要正常运行。如果客户端发生了长时间GC停顿，或者宿主机被暂停，看门狗的续期线程一样被冻住，锁过期后依然会被别人抢到。等业务线程从GC中恢复，它自认为仍然持锁，其实锁已经不属于它了。这就是前面说的“GC pause导致锁失效”，属于分布式锁本身无法彻底解决的问题，只能通过fencing token之类的机制从业务层面兜底。
面试时如果把看门狗讲完，再主动提一句“虽然Redisson会自动续期，但极端停顿下锁还是会失效，所以我们线上会接受很小的重复概率，通过幂等处理来兜底”，面试官基本不会再往深处追问了。能接受不一致而且有兜底，这才是大厂分布式系统里真实的处理方式。
5.3 时钟跳跃问题：一个容易被忽略的边界场景
另一道容易被忽略的进阶题是“如果Redis服务器或者客户端服务器时钟发生了跳跃，分布式锁会出现什么问题”。锁的安全性其实依赖于时间判断：节点A加锁成功，锁的过期时间戳是t1；如果这时候Redis服务器的时钟突然往前调了一大段，比如t1直接变成过去时间，锁就可能立刻过期，其他人马上能拿到锁。反过来，如果时钟往后调，锁的有效期又会莫名变长，该释放的锁迟迟不释放。
解决思路有两个层面。第一是运维层面，使用NTP服务保证服务器时钟尽量准确，并配置合适的时间校准策略，避免大幅跳跃。第二是设计层面，不要单纯依赖时间判断，比如引入自增序号、写操作带上递增token，让业务侧能识别出“这个并发请求是不是来自已经过期的锁持有者”。时钟跳跃在实际面试中出现频率不高，但能答出来会显得边界意识很强，因为做分布式系统，最怕的就是默认“大家的时钟都是一样的”。
6. 实战踩坑记录与面试连环追问怎么接
6.1 我线上踩过的四个分布式锁的坑
前面原理讲得多，这里分享几个我真实踩过的坑，面试的时候直接拿来当案例讲，效果比背定义好得多。
第一个坑是锁超时导致同样的逻辑执行了两遍。我们有一次做订单状态回写，A服务加锁处理订单，处理逻辑里有一次很慢的外部HTTP调用，耗时超过了锁的过期时间，锁被自动释放，B服务也拿到锁开始处理同一个订单。两边重复处理，下游收到两条内容一样的回调。这个问题的修复方式很直接：外部调用尽量移出锁内执行，或者把锁时间调大，配合看门狗续期。
第二个坑是锁误删。早期我们加锁只用固定的字符串做value，比如"LOCK"，也写了del，结果两个服务之间会出现互相删锁的事。发现之后把所有加锁请求改成了UUID作为value，解锁统一走Lua脚本。
第三个坑是单点故障。我们把锁加到单个Redis主节点上，有一次主节点宕机，由于没有配置哨兵自动切换，整个业务锁服务对下游完全不可用，所有需要抢锁的接口全部报错。后来加了高可用方案，也在关键路径上做了降级策略。
第四个坑是锁粒度太大。有一段时间我们想省事，把一类订单的整个处理过程都放在同一把锁里，结果所有订单都串行处理，接口RT从几十毫秒涨到几秒。后来改成按订单ID维度加锁，锁粒度细化到单个业务对象。这几个坑在面试里就是活生生的例子，比讲一百遍原理都有说服力。
6.2 面试官连环追问的六个套路
分享几个面试现场高频出现的连环追问，每个都给一个可以直接使用的回答方向。
“Redis是集群模式的话，锁加在主节点还是从节点？”答：Redis Cluster场景下锁会落在某个slot对应的主节点上，主节点同步给从节点，如果主节点挂掉且没有及时同步，理论上锁会失效，这也是RedLock要解决的问题。
“锁的过期时间为什么要设成30秒而不是60秒？”答：没有统一标准。30秒是Redisson的默认值，配合看门狗续期基本够用。如果业务里确实有超过30秒的长事务，要么调大初始值，要么保证续期线程不被阻塞。
“业务代码和unlock之间抛异常了怎么办？”答：把解锁逻辑放在finally里，或者用Redisson自带的lock()方法在注解模式下处理。绝对不能只依赖自动过期，异常路径必须显式释放锁。
“分布式锁和分布式事务是什么关系？”答：两者不是一回事。分布式锁解决的是并发互斥问题，分布式事务解决的是跨节点数据一致性问题。锁只能保证同一时刻一个人操作，不能保证操作结果在多个库之间原子提交。
“你遇到分布式锁失效会怎么排查？”答：先从现象判断是锁没抢到还是抢到了锁但互斥失效，然后看Redis里的key状态、value是不是自己的、TTL还剩多久，再看业务日志里有么有进入临界区的记录，最后结合链路追踪确认是否有锁超时、主从切换等异常事件。
“有没有不用锁的替代方案？”答：有。比如用乐观锁版本号、用队列串行化、用幂等表去重、用唯一约束兜底。分布式锁不是唯一答案，很多场景下用更轻量的方案反而更好。
这几个追问一旦接住，后面基本就是闲聊了。
6.3 一套通用排查思路：分布式锁问题三板斧
整理一个自己常用的排查套路，面试被问到实战题时可以边说边展示思路。
第一板斧是确认锁本身的状态。先查Redis里锁key是否存在、value是不是当前业务实例的标识、TTL还剩多少。如果key没了但业务日志显示已经加锁了，那大概率是锁过期被释放了。
第二板斧是确认业务有没有重复执行。去下游或者数据库里看同一笔业务产生了两次明显记录。如果重复了，把两次操作的时间点和持锁方日志拉出来对比，很容易看到是不是锁超时窗口期内另一个节点进入了临界区。
第三板斧是确认基础设施有没有异常。查一下当时Redis有没有主从切换、节点有没有重启、网络有没有抖动。这三板斧走完，绝大多数分布式锁问题都能定位到原因。面试时把这三步说出来，说明你是真的见过线上事故的人，而不是只会背理论。
最后分享一点个人心得
我从一开始用setnx实现分布式锁，到后来慢慢研究Redisson源码、踩过主从切换丢锁的坑、又回头去读RedLock的争论文章，整个过程最大的体会是：分布式锁不是一个“调API”的问题，而是一个“设计可靠性边界”的问题。面试官不会因为你背下来某个框架的用法就给你高分，真正值钱的是你知道这套机制在什么情况下会失效、失效后会造成什么后果、怎么从业务层面兜底。
如果你正在准备面试，建议把文章里的场景自己捋一遍，试着不用文档也能说清楚：set命令为什么带NX和EX，解锁Lua脚本为什么能防止误删，看门狗续期解决什么问题、解决不了什么问题，ZK临时顺序节点怎么避免惊群，主从切换丢锁时你的业务有没有幂等兜底。把这些串起来，再往里填一两个自己项目的真实案例，这道分布式锁的题就稳了。
