做分布式系统最绕不开的一个基础组件就是分布式锁。我见过不少团队在并发量上来之后才发现本地锁根本管不住多实例同时抢资源的问题于是匆忙在 Redis、ZooKeeper、数据库这三个方案里选一个落地。结果选型时只看了一篇表面文章上线后线上锁失效、死锁、锁误删的幺蛾子全来了。这篇博文我会把三种主流实现方案——Redis分布式锁、ZooKeeper临时顺序节点锁、数据库锁——从原理、实现细节到坑点全部拆开讲一遍最后给出一个可以直接抄作业的选型路径。内容偏实战适合正在做微服务拆分、多实例部署、或者准备面试分布式锁相关题目的同学读完之后你至少能回答清楚“为什么这个场景用 Redis、那个场景必须用 ZooKeeper”这个问题。先说一下我对分布式锁的整体判断没有完美的方案只有适合场景的方案。Redis 胜在快但一致性强依赖主节点稳定性ZooKeeper 胜在可靠但性能和运维成本都不低数据库锁最朴素却往往被低估。下面我们逐个拆解。1. 为什么需要分布式锁先搞懂它在解决什么问题1.1 单机锁的局限与分布式场景的并发矛盾在单体应用时代我们处理并发问题最简单的方式就是synchronized或ReentrantLock。JVM 内部维护的锁机制可以保证同一时刻只有一个线程进入临界区这个机制建立在单进程内存共享的基础上。但当应用从单机升级成多实例部署——比如在 K8s 里跑三个副本或者在多台物理机上各起一个服务——情况就变了三个 JVM 进程之间并没有共享内存你加在static对象上的锁在另一个进程里完全不生效。典型场景是库存扣减。你在单机上加锁请求打到三个实例上三个实例同时读到库存剩余 20 件各自扣一单数据库最终只剩 17 件但实际可能已经收到了三笔订单。这就是超卖。分布式锁解决的就是这个“跨进程互斥”的问题。它需要一个所有参与者都能访问的第三方协调者可能是 Redis、ZooKeeper、数据库也可能是一张共享磁盘上的文件核心目标只有一个让多个进程对同一个临界资源的访问串行化。1.2 分布式锁的三个基本要求互斥、防死锁、容错很多人以为分布式锁只要“能加能释放”就行但真正落地时要满足三个基本要求缺一个都会埋雷。第一个要求是互斥性Mutual Exclusion。任意时刻只能有一个客户端持有锁。这个要求看着简单实际做起来最难——尤其是 Redis 主从切换时如果主节点上的锁还没来得及同步到从节点从节点提升为新的主节点后会丢失锁记录另一个客户端就能成功加锁这就破坏了互斥性。第二个要求是防死锁Deadlock Freedom。客户端拿到锁之后崩溃了、被 kill 了、网络断开了它手里的锁必须能被自动释放否则其他客户端永远拿到不锁。Redis 的做法是给锁设置过期时间TTLZooKeeper 的做法是依赖临时节点在会话结束时的自动清理数据库的做法则依赖事务超时或定时任务。第三个要求是容错性Fault Tolerance。只要集群中大部分节点存活客户端就应该能够完成加锁和解锁操作。这一点直接决定了你在选型时要考虑中间件本身的高可用架构而不是只看单节点的多强。把这三个要求放到脑子里后面看三种实现方案时你就会发现每个方案都在做妥协没有一个是全部满足的。2. Redis 实现方案高并发首选但坑也多2.1 正确加锁别再只用 SETNXRedis 实现分布式锁最简单直接的思路是利用SETNX命令——如果 key 不存在则设置成功存在则设置失败。SETNX lock:order:1001 uuid-value这个命令在 Redis 2.6.12 版本之前是“能用但不稳”的因为SETNX跟EXPIRE不是原子操作。你写完SETNX之后还没来得及设置过期时间客户端宕机了这个 key 永远存在死锁就发生了。所以那个年代的经典方案是先SETNX再EXPIRE中间这段非原子窗口期形成了天然缺陷网上很多老教程还在教这个写法千万别学。正确的写法是使用SET命令带上多个参数一次原子完成加锁和过期时间设置SET lock:order:1001 uuid-value NX PX 30000NX表示 key 不存在时才设置成功PX 30000表示锁的自动过期时间为 30 秒value 不是一个固定字符串而是一个全局唯一的客户端标识通常是 UUID这里 value 用 UUID 极其重要它是整个方案安全性的基石。后面的释放锁操作要靠这个 value 来判断“当前这把锁是不是我的”防止出现“A 客户端把 B 客户端的锁删掉了”的经典事故。你可以把 value 理解为钥匙上的指纹只有匹配才能开门。加锁成功后业务代码在临界区里干活防死锁由 PX 过期时间兜底。到这里最简单的 Redis 锁就有了。2.2 释放锁校验持有者与原子删除很多人写释放锁的逻辑时直接一行DEL完事。但这里有个极其隐蔽的问题如果 A 持锁后业务执行时间超过了锁的过期时间锁自动释放了此时 B 快速加锁成功开始执行业务而 A 终于干完活了执行DEL lock——这一删把 B 的锁删掉了。接下来 C 也能加锁成功三个客户端同时进入临界区整个分布式锁形同虚设。所以释放锁的正确流程必须是先检查当前锁的 value 是否等于自己的 UUID等于才允许删除且检查与删除要原子执行。检查与删除是两个操作如果分开执行检查完毕到删除执行之间的窗口期依然有误删风险唯一的解决办法是用 Lua 脚本把两个操作封装成一个原子脚本-- 释放锁的 Lua 脚本 if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end调用方式如下EVAL if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end 1 lock:order:1001 uuid-valueRedis 的 Lua 脚本本身是原子执行的不会被打断因此可以保证 value 校验和 del 的原子性。凡是使用 Redis 分布锁的项目释放锁的代码必须走这个 Lua 脚本没有第二种合法姿势。2.3 续期与看门狗解决业务超时的核心手段Redis 锁的过期时间设多长这是分布式锁面试里必问的细节题。设短了业务没执行完锁就自动释放临界区被第二个线程进入互斥失效设长了客户端崩溃后锁要很久才能被自动清理系统可用性下降。正确的做法是为锁设置一个合理的过期时间同时给锁加上自动续期机制也就是看门狗WatchDog机制。Redisson 是 Java 生态里最成熟的 Redis 分布式锁客户端它的实现思路是这样的默认情况下锁的过期时间是 30 秒但 Redisson 的看门狗每过 10 秒会检查一次锁是否还在持有状态如果还在就自动把过期时间重新刷成 30 秒。这样只要客户端进程活着锁就不会因为业务执行时间过长而过期一旦客户端宕机看门狗也会停止锁在最多 30 秒后自动释放。// Redisson 的典型用法 RLock lock redissonClient.getLock(lock:order:1001); lock.lock(); try { // 这里执行长时间业务逻辑也没关系 // 看门狗会自动续期 doSomething(); } finally { lock.unlock(); }这个小细节直接决定了一个方案能不能用于生产环境。如果不想引入 Redisson至少要自己写一个定时任务做续期否则锁的过期时间就只能按“压测出的最大业务耗时 缓冲余量”来拍脑袋设置线上风险大。2.4 主从切换丢锁与 RedLock 争议Redis 主从模式的分布式锁有一个根深蒂固的问题锁数据在主节点上和从节点上不是强一致的存在同步延迟窗口。客户端 A 在主节点上成功加锁此时主节点宕机从节点提升为主节点但这个从节点上没有 A 的锁数据客户端 B 在这个新的主节点上尝试加锁成功。两个客户端同时持锁互斥性被打破。Redis 官方给出的解决方案是 RedLock 算法。基本思路是不再向单个 Redis 实例加锁而是向按奇数个数部署的多个独立 Redis 实例逐一加锁只有超过半数实例加锁成功才认为整体加锁成功释放锁时向所有实例广播删除命令。RedLock 在某些对一致性要求极高的场景中是推荐的但它在学术和工程界一直有争议。以分布式系统专家 Martin Kleppmann 为代表的观点认为RedLock 依赖系统时钟当时钟发生跳跃时锁依然可能失效。对此 Redis 作者 Antirez 也写了长文回应。这场争论普通人不需要站队你只需要明白一件事绝大多数业务场景用带看门狗的普通 Redis 锁就够了只有资金类、风控类极端场景才值得考虑 RedLock 或直接换 ZooKeeper。2.5 Redis 锁的适用场景和参数建议把 Redis 锁的优缺点摊开来说它的优点是性能极高单实例 QPS 能到十万级别缺点则是它只能保证最终一致严格意义上无法做到绝对互斥。适用场景是并发量高、对一致性要求不是“宗教级别”的核心链路场景——比如秒杀、限时抢购、活动领券、购物车合并、重复提交防护。参数上我个人的习惯是参数建议值说明锁过期时间业务预估耗时 * 2 1000ms给业务留足缓冲宁长勿短看门狗续期间隔锁过期时间的 1/3Redisson 默认 30s 过期、10s 续期重试等待100ms - 500ms加锁失败后随机退避避免惊群自旋上限8 - 10 次超过上限直接返回失败别死磕3. ZooKeeper 实现方案用强一致换可靠3.1 临时顺序节点的工作原理ZooKeeper 实现分布式锁依赖两个底层特性临时节点和顺序节点。临时节点Ephemeral Node随创建它的客户端会话存活。客户端会话结束后ZooKeeper 会自动删除这个节点。这意味着持有锁的进程崩溃了锁会自动释放从机制层面解决死锁问题。顺序节点Sequential Node则是 ZooKeeper 为每个子节点自动分配一个单调递增的序号保证后创建的节点序号更大。两者结合形成一个经典方案——客户端在同一个锁目录下创建临时顺序节点序号最小的节点视为持有锁的客户端。用生活场景类比就是ZooKeeper 做事务叫号机所有人到柜台拿一个号码牌叫到最小的号才能办业务办完离开节点删除叫号机自动叫下一个号。3.2 加锁、监听前驱与羊群效应规避具体加锁流程分四步在锁目录/locks下创建临时顺序节点例如/locks/lock_000001获取/locks下所有子节点排序后判断自己的序号是不是最小的如果是最小序号获得锁执行业务逻辑如果不是最小序号则对前一个节点设置监听Watch前一个节点被删除时当前客户端会收到通知然后重新执行步骤 2这里有一个关键设计监听的对象是前一个节点而不是所有节点。如果在step 4中所有没拿到锁的客户端都去监听它们共同的大哥——序号最小的那个节点会出现什么情况一旦持有锁的最小节点释放锁所有等待的客户端同时被唤醒瞬间全部向 ZooKeeper 发起“我是最小序号吗”的请求。但此时只有一个客户端能成功其他几千个请求全部白扑这就是羊群效应也叫惊群效应。监听前一个节点后每个客户端只依赖前一个节点释放的通知通知链变成线性的既避免了惊群也减少了 ZooKeeper 服务的压力。释放锁时客户端直接删除自己创建的那个节点。如果业务执行完主动删除前一个节点会被后续客户端监听并自动唤醒如果客户端崩溃临时节点在会话超时后也会被自动删除锁依然会被传递下去。用 Curator 客户端的InterProcessMutex可以封装这段复杂的逻辑// Curator 的典型用法 CuratorFramework client CuratorFrameworkFactory.newClient(zookeeper1:2181,zookeeper2:2181,zookeeper3:2181, retryPolicy); InterProcessMutex lock new InterProcessMutex(client, /locks/lock_000001); lock.acquire(); try { // 业务逻辑 } finally { lock.release(); }这里的复杂性全部由 Curator 内部消化创建节点、排序、监听前驱、断线重连后的处理——它会帮你处理好。3.3 会话超时与自动释放的平衡ZooKeeper 天然解决死锁问题靠的是会话机制但这个机制也不是没有副作用。如果客户端没有崩溃只是发生了网络抖动、Full GC 或者长时间停顿客户端与 ZooKeeper 服务端的会话保活请求发不过去ZooKeeper 会在会话超时后判定客户端死亡自动删除临时节点。此时原客户端可能还没丢锁但锁已经被释放给别人——同样会出现两个客户端同时进入临界区的状况。所以 ZooKeeper 方案里会话超时参数的设置非常重要。超时时间过长客户端真正崩溃时锁要等很久才能被释放超时时间过短一次轻微的 GC 停顿就可能造成锁丢失。ZooKeeper 默认会话超时时间是 2 个 tick默认 tickTime 为 2000ms即 4 秒到 20 个 tick40 秒之间这个值可以根据业务容忍度调整并不是越大越好。从我实际使用来看ZooKeeper 锁在锁持有时间长、并发冲突频率低、可靠性要求高的数据同步、离线任务调度场景下非常好用。但它的性能上限低于 Redis创建节点、监听通知的延迟在毫秒级到十几毫秒级不适合超高频抢锁场景。4. 数据库实现方案最朴素但别小看它4.1 悲观锁select ... for update 的用法与约束数据库实现分布式锁最直接的方式是悲观锁。以 MySQL 为例核心是一个带FOR UPDATE的查询语句-- 开启事务 BEGIN; -- 对目标记录加行级排他锁 SELECT * FROM inventory WHERE sku_id 1001 FOR UPDATE; -- 执行库存扣减等业务操作 UPDATE inventory SET stock stock - 1 WHERE sku_id 1001; -- 提交事务释放锁 COMMIT;SELECT ... FOR UPDATE会对命中的行加上排他锁其他事务对这些行的写入会被阻塞直到当前事务提交或回滚。这天然符合分布式锁的互斥语义因为所有实例连的都是同一台数据库行锁由数据库统一管理。但用悲观锁做分布式锁有几条硬性约束每一条都踩过坑必须在事务里执行脱离了事务FOR UPDATE锁会立即释放等于没锁必须走索引如果sku_id没有索引InnoDB 会从行锁升级为表锁整个表的写入全部串行化性能灾难事务别太长长事务会让连接池的连接长时间被占住高并发下很快把数据库连接耗尽注意死锁多个客户端以不同顺序锁定多条记录时可能互相等待触发 InnoDB 死锁检测悲观锁的优点是实现简单与业务事务无缝结合锁的释放完全跟随事务生命周期缺点也很突出——性能上限低且依赖数据库本身的可用性和稳定性。如果数据库是单点数据库一挂锁也挂了系统全面瘫痪。4.2 乐观锁版本号 CAS 的正确打开方式乐观锁并不是传统意义上“加锁”而是用条件更新CAS来保证并发安全。通常的做法是给表加一个version字段每次更新时校验版本号UPDATE inventory SET stock stock - 1, version version 1 WHERE sku_id 1001 AND version 5;这条 SQL 的执行逻辑是只有当数据库里的 version 还是旧客户端读到的 5 时才允许更新成功并把 version 改成 6。如果另一个客户端已经把 version 从 5 改成了 6这条 SQL 影响行数为 0当前客户端拿不到锁需要重新读取最新数据、重试或丢弃操作。在业务中把“影响行数为 0”当作“没抢到锁”的判定标准就构成一个无中心、无额外存储的分布式锁。它的优点是完全不需要引入新的中间件和现有数据库体系无缝集成缺点是它不提供互斥等待能力抢不到锁只能立即重试或失败不适合需要排队等待的强冲突场景。乐观锁适合冲突频率低、重试成本低的业务场景比如后台配置更新、任务状态变更、用户资料编辑等这类场景并发碰撞概率小用乐观锁最省心。4.3 唯一约束插入法能跑但很麻烦除了悲观锁和乐观锁还有一种利用数据库唯一约束的插入法。做法是建一张专门的锁表CREATE TABLE distributed_lock ( lock_key VARCHAR(64) PRIMARY KEY, owner VARCHAR(64) NOT NULL, expire_at DATETIME NOT NULL );获取锁时插入一行记录INSERT INTO distributed_lock (lock_key, owner, expire_at) VALUES (order_1001, instance_uuid, DATE_ADD(NOW(), INTERVAL 30 SECOND));因为lock_key是主键同一时刻只能有一条插入成功插入成功的客户端视为获得锁。释放锁时删除对应行即可DELETE FROM distributed_lock WHERE lock_key order_1001 AND owner instance_uuid;插入法实现最简单但也最麻烦它不会自动超时释放。客户端崩溃后记录永远留在表里必须额外起一个定时任务周期性扫描并清理过期记录这等于手工卷了 Redis TTL 和 ZooKeeper 会话机制的活儿。所以插入法只适合锁持有时间非常短、系统规模非常小的场景我不推荐任何正规项目使用。5. 深度对比与选型指南5.1 一张表看懂三方案的核心指标把前面几个部分的细节收拢做成一张对比表。这张表我建议你保存下来面试前和选型时直接翻对比维度RedisZooKeeper数据库悲观锁性能极高单实例十万级 QPS中等数千到数万 QPS最低受限于数据库连接数互斥性主从切换时有概率失效可靠顺序节点保证了全局序可靠行锁由数据库保证自动释放依赖 TTL 和看门狗会话结束自动删除临时节点长事务/异常时可能留下锁依赖事务机制可重入需要额外设计Redisson 支持Curator 的 InterProcessMutex 支持悲观锁天然不支持公平性不保证抢锁是随机的保证按序号排队不保证看事务到达顺序实现复杂度低到中看是否用 Redisson中高要理解会话和 Watch低但有隐性问题运维成本需保证 Redis 高可用需独立 ZooKeeper 集群复用现有数据库推荐场景高频抢锁、秒杀、缓存更新需要严格互斥、低频但长持锁并发量低、不想引入新组件5.2 从一致性与可用性的天平看选型如果从分布式系统的 CAP 理论角度看这三种方案的本质差异会看得更清楚。Redis 是典型的AP 系统优先保证可用性和分区容忍性在互斥性上做了让步。主从切换时系统还能继续对外服务但锁可能丢失这是以牺牲一致性换来的高可用。ZooKeeper 是典型的CP 系统优先保证一致性集群节点间对数据达成一致才返回成功。一个客户端拿到锁意味着所有 ZooKeeper 节点都认可这个结果互斥性极高但代价是可用性降低——ZooKeeper 集群选举 Leader 期间通常几十秒整个集群不对外提供服务。数据库则更接近 CP行锁的状态由数据库事务机制严格保证但可用性取决于数据库高可用方案的质量。所以选型的本质是在“性能”和“绝对互斥性”之间做权衡。要是有人问你“到底哪个方案好”你可以直接反问他“你的业务能不能容忍一个极端罕见的时间窗口里两个线程同时操作同一份数据能容忍就 Redis不能容忍就用 ZooKeeper——但你也要同时接受 ZooKeeper 的吞吐瓶颈和运维复杂度。”5.3 根据团队场景做选择的决策路径结合我的项目经验选型时可以走一套简单的决策树并发量高上千 QPS 以上且允许极小概率锁失效选 Redis配 Redisson 客户端加锁走SET NX PX释放走 Lua 脚本看门狗自动续期Redis 自身用哨兵或 Cluster 保证高可用。这个组合能覆盖 90% 以上的业务场景。对一致性要求极严格资金、订单状态、强审计类选 ZooKeeper使用 Curator 封装好的InterProcessMutex把锁过期时间控制在十几秒量级同时监控客户端 GC 停顿避免会话超时误判。并发量不大团队不想引入新的中间件选数据库乐观锁加一个 version 字段就够了如果对实时排队要求不高甚至可以容忍偶尔的重试。悲观锁只在并发量真的很低、锁粒度又非常单一的情况下推荐。团队已有强一致元数据服务如果你们已经部署了 etcd直接使用 etcd 的LeaseKey实现分布式锁原理与 ZooKeeper 类似性能更好但这篇不过多展开。有一点我特别想强调不要为了用分布式锁而用分布式锁。很多业务场景其实不需要跨进程锁。比如库存字段可以考虑用数据库自身的原子自减能力UPDATE ... SET stock stock - 1 WHERE stock 0解决幂等性可以由唯一索引解决串行消费可以由消息队列的分区机制解决。分布式锁引入的成本中间件依赖、网络开销、排查难度比想象中高先想清楚是否真的非它不可。6. 实战避坑清单这些坑我基本都踩过6.1 先释放锁还是先提交事务这是使用 Redis 分布式锁时最容易忽略的顺序问题也是我在线上复盘过一次的事故。很多人的代码长这样在方法入口加锁在方法内开一个数据库事务做业务更新事务提交后释放锁。看起来没毛病但如果你把释放锁的代码放在事务提交之前——比如在finally块里释放锁、事务却还没提交——就会产生一个可怕的窗口期锁释放了但事务还没提交新的客户端拿到锁进入临界区此时读到的是旧数据两个客户端实际上还是在并发操作同一条记录。正确的顺序必须是先提交事务再释放锁。用代码来表达就是lock.lock(); try { // 事务提交发生在锁释放之前 transactionService.doUpdate(); } finally { // 此时事务已提交锁才能释放 lock.unlock(); }这个问题的本质是锁的生命周期和事务的生命周期没有对齐。既然选择用 Redis 锁保护数据库临界区就必须让锁的持有时间覆盖事务从开启到提交的完整区间并且在提交之后立刻释放不给下一个线程留读到半成品数据的机会。6.2 锁粒度、过期时间与重试策略锁的粒度直接决定了系统的并发度。把整个用户维度的锁做成lock:user:userId粒度太粗——用户 A 的请求会互相排队明明只是操作不同订单却要等待同一个用户锁粒度太细则可能覆盖不住临界区。一个比较成熟的做法是按资源 ID 拆锁要锁订单就lock:order:orderId要锁库存就lock:sku:skuId让锁的最小单元和业务的最小操作单元对齐。过期时间前面提过宁长勿短是最稳的保守策略。长锁过期时间唯一的风险是客户端崩溃后锁不能快速自动失效但崩溃毕竟是少数而业务超时则是高频事件。设置过期时间时先在压测环境测出业务 P99 耗时然后乘以 2 再加 1 秒余量这样即使偶发 GC 停顿也不会提前丢失锁。加锁失败后的重试动作也有讲究。不要用固定间隔死循环重试那会在 Redis 上加大量无意义的SET请求。推荐的做法是随机退避每次重试的等待时间为 100ms 到 500ms 之间的随机值最多重试 8 到 10 次超过就直接返回失败或走降级逻辑。随机退避可以把竞争请求在时间轴上打散显著降低锁冲突的雪崩概率。6.3 常用组件与最终经验建议如果项目已经引入了 Redis推荐直接在 Redisson 里操作不要再自己封装一套 SETNX Lua。自己实现的方案在续期、可重入、公平锁这些细节上总有覆盖不到的地方而 Redisson 这些能力都是现成的经过了大规模生产环境验证。如果你用的是 ZooKeeper直接使用 Curator它的InterProcessMutex、InterProcessReadWriteLock已经被无数项目验证过别自己去造节点管理、监听注册的轮子。我个人在实际操作中的体会是分布式锁方案选型九成场景落到 Redis一成落到 ZooKeeper数据库锁反而是大多数团队的备选而非首选。你把 Redis 锁的看门狗续期、原子释放脚本、主从切换容忍度这几个点做好了它就能覆盖绝大多数并发场景。只有当业务强一致要求真的上升到了资金审计级别再把 ZooKeeper 请出来对付极端情况。最后再分享一个小技巧无论你采用哪种方案都要在加锁、解锁的关键路径上加上日志和监控指标。统计加锁耗时、等待耗时、锁冲突次数、看门狗续期次数这些数据能在线上锁出问题的时候帮你快速定位到底是业务超时、中间件故障还是 GC 停顿导致的。分布式锁排查起来的难点往往不在于方案本身而在于黑盒状态下你连“锁到底有没有生效”都不知道。有了监控很多疑难问题会变得一目了然。