1. 分布式锁的核心概念与必要性在分布式系统中多个服务实例需要协调对共享资源的访问时传统的单机锁机制如synchronized或ReentrantLock就完全失效了。我曾经在一个电商秒杀系统中深刻体会过这一点——当10个节点同时尝试扣减库存时单纯依靠数据库事务根本无法阻止超卖现象。分布式锁的本质是通过一个所有节点都能访问的第三方系统实现对临界资源的互斥访问。它必须满足三个核心特性互斥性这是最基本的要求任意时刻只能有一个客户端持有锁。我在实际项目中见过因互斥性失效导致的资金重复结算事故后果非常严重。避免死锁必须设置合理的超时机制防止因客户端崩溃导致的锁无法释放。但这也带来了新的挑战——如何平衡超时时间设置。容错性当锁服务部分节点故障时整个系统仍应能正常工作。这一点在Redis集群模式下尤为重要。2. 主流实现方案对比与选型2.1 基于数据库的实现MySQL的实现方案看似简单但在实际生产环境中存在严重性能瓶颈。我曾经在压测中发现使用SELECT FOR UPDATE时QPS很难超过2000。其核心问题在于-- 关键SQL语句 BEGIN; SELECT * FROM distributed_lock WHERE lock_keyresource_1 FOR UPDATE; -- 业务处理... COMMIT;重要提示WHERE条件必须使用索引列否则会升级为表锁。我曾因此导致过整个系统卡死。适用场景适合并发量低1000QPS、对一致性要求极高的金融交易类业务。优点是实现简单不需要引入新组件。2.2 基于Zookeeper的实现Zookeeper通过临时顺序节点和Watch机制实现分布式锁其典型代码如下// 使用Curator客户端示例 InterProcessMutex lock new InterProcessMutex(client, /locks/order); try { if (lock.acquire(30, TimeUnit.SECONDS)) { // 业务处理 } } finally { lock.release(); }实战经验节点路径建议按业务划分如/locks/payment默认会话超时为60秒需要根据业务调整网络分区时可能出现羊群效应需要合理设置重试策略性能数据在3节点ZK集群上实测锁操作平均耗时约15ms适合中等并发场景。2.3 基于Redis的实现Redis因其高性能成为分布式锁的首选方案但实现一个健壮的Redis锁需要处理多个细节问题基础实现方案// 错误示范 - 非原子操作 String result jedis.set(lockKey, requestId); jedis.expire(lockKey, expireTime); // 正确写法 - 原子操作 String result jedis.set(lockKey, requestId, NX, PX, expireTime);关键参数说明NX仅当key不存在时设置PX设置过期时间毫秒requestId必须使用唯一标识通常用UUID高级问题解决方案锁续期问题通过守护线程定期检查private void scheduleExpirationRenewal() { Thread renewalThread new Thread(() - { while (!Thread.currentThread().isInterrupted()) { jedis.expire(lockKey, expireTime); Thread.sleep(expireTime / 3); } }); renewalThread.setDaemon(true); renewalThread.start(); }集群模式下的RedLock算法依次向N个Redis节点获取锁当获取到大多数N/21节点锁时才算成功总耗时必须小于锁有效期3. Redisson生产级解决方案经过多个项目的验证Redisson提供了最完善的分布式锁实现。其核心优势在于看门狗机制自动续期默认每10秒检查一次可重入锁支持同一线程多次加锁多种锁类型包括公平锁、联锁等3.1 配置示例Config config new Config(); config.useSingleServer() .setAddress(redis://127.0.0.1:6379) .setPassword(password) .setDatabase(0); RedissonClient redisson Redisson.create(config); RLock lock redisson.getLock(orderLock);3.2 最佳实践锁命名规范建议使用业务域:资源标识格式如inventory:sku_12345超时设置默认30秒可通过lockWatchdogTimeout参数调整异常处理必须放在finally块中释放锁try { lock.lock(); // 业务处理 } finally { if (lock.isLocked() lock.isHeldByCurrentThread()) { lock.unlock(); } }4. 性能优化与问题排查4.1 压测数据对比方案QPS平均耗时适用场景MySQL1,50050ms低并发强一致Zookeeper5,00015ms中并发可靠场景Redis单机50,0002ms高并发最终一致Redis集群30,0005ms高可用场景4.2 常见问题排查指南锁无法释放检查是否忘记调用unlock()确认没有异常导致代码未执行到unlock使用lock.isHeldByCurrentThread()判断性能突然下降Redis连接池是否耗尽Zookeeper是否出现GC停顿数据库锁等待超时锁被误删确保每个客户端使用唯一标识实现删除前的值校验if (redis.get(lockKey).equals(requestId)) { redis.del(lockKey); }5. 架构设计建议对于关键业务系统我建议采用多级锁策略第一层本地缓存锁Caffeine第二层分布式锁Redisson第三层数据库乐观锁version字段这种设计在保证一致性的同时能极大提升系统吞吐量。在最近的一个支付系统中我们通过这种方案将TPS从800提升到了12,000。对于锁的监控也至关重要建议记录每个锁的获取耗时监控锁等待队列长度设置锁竞争告警阈值分布式锁看似简单但要实现一个生产级可用的方案需要考虑诸多细节。经过多个项目的实践我认为Redisson是目前Java生态中最完善的解决方案值得作为首选方案。 
长河君 · 2026/11/2 17:00:25 · 阅读 1.2k 分布式锁实现方案对比与Redisson最佳实践
1. 分布式锁的核心概念与必要性在分布式系统中多个服务实例需要协调对共享资源的访问时传统的单机锁机制如synchronized或ReentrantLock就完全失效了。我曾经在一个电商秒杀系统中深刻体会过这一点——当10个节点同时尝试扣减库存时单纯依靠数据库事务根本无法阻止超卖现象。分布式锁的本质是通过一个所有节点都能访问的第三方系统实现对临界资源的互斥访问。它必须满足三个核心特性互斥性这是最基本的要求任意时刻只能有一个客户端持有锁。我在实际项目中见过因互斥性失效导致的资金重复结算事故后果非常严重。避免死锁必须设置合理的超时机制防止因客户端崩溃导致的锁无法释放。但这也带来了新的挑战——如何平衡超时时间设置。容错性当锁服务部分节点故障时整个系统仍应能正常工作。这一点在Redis集群模式下尤为重要。2. 主流实现方案对比与选型2.1 基于数据库的实现MySQL的实现方案看似简单但在实际生产环境中存在严重性能瓶颈。我曾经在压测中发现使用SELECT FOR UPDATE时QPS很难超过2000。其核心问题在于-- 关键SQL语句 BEGIN; SELECT * FROM distributed_lock WHERE lock_keyresource_1 FOR UPDATE; -- 业务处理... COMMIT;重要提示WHERE条件必须使用索引列否则会升级为表锁。我曾因此导致过整个系统卡死。适用场景适合并发量低1000QPS、对一致性要求极高的金融交易类业务。优点是实现简单不需要引入新组件。2.2 基于Zookeeper的实现Zookeeper通过临时顺序节点和Watch机制实现分布式锁其典型代码如下// 使用Curator客户端示例 InterProcessMutex lock new InterProcessMutex(client, /locks/order); try { if (lock.acquire(30, TimeUnit.SECONDS)) { // 业务处理 } } finally { lock.release(); }实战经验节点路径建议按业务划分如/locks/payment默认会话超时为60秒需要根据业务调整网络分区时可能出现羊群效应需要合理设置重试策略性能数据在3节点ZK集群上实测锁操作平均耗时约15ms适合中等并发场景。2.3 基于Redis的实现Redis因其高性能成为分布式锁的首选方案但实现一个健壮的Redis锁需要处理多个细节问题基础实现方案// 错误示范 - 非原子操作 String result jedis.set(lockKey, requestId); jedis.expire(lockKey, expireTime); // 正确写法 - 原子操作 String result jedis.set(lockKey, requestId, NX, PX, expireTime);关键参数说明NX仅当key不存在时设置PX设置过期时间毫秒requestId必须使用唯一标识通常用UUID高级问题解决方案锁续期问题通过守护线程定期检查private void scheduleExpirationRenewal() { Thread renewalThread new Thread(() - { while (!Thread.currentThread().isInterrupted()) { jedis.expire(lockKey, expireTime); Thread.sleep(expireTime / 3); } }); renewalThread.setDaemon(true); renewalThread.start(); }集群模式下的RedLock算法依次向N个Redis节点获取锁当获取到大多数N/21节点锁时才算成功总耗时必须小于锁有效期3. Redisson生产级解决方案经过多个项目的验证Redisson提供了最完善的分布式锁实现。其核心优势在于看门狗机制自动续期默认每10秒检查一次可重入锁支持同一线程多次加锁多种锁类型包括公平锁、联锁等3.1 配置示例Config config new Config(); config.useSingleServer() .setAddress(redis://127.0.0.1:6379) .setPassword(password) .setDatabase(0); RedissonClient redisson Redisson.create(config); RLock lock redisson.getLock(orderLock);3.2 最佳实践锁命名规范建议使用业务域:资源标识格式如inventory:sku_12345超时设置默认30秒可通过lockWatchdogTimeout参数调整异常处理必须放在finally块中释放锁try { lock.lock(); // 业务处理 } finally { if (lock.isLocked() lock.isHeldByCurrentThread()) { lock.unlock(); } }4. 性能优化与问题排查4.1 压测数据对比方案QPS平均耗时适用场景MySQL1,50050ms低并发强一致Zookeeper5,00015ms中并发可靠场景Redis单机50,0002ms高并发最终一致Redis集群30,0005ms高可用场景4.2 常见问题排查指南锁无法释放检查是否忘记调用unlock()确认没有异常导致代码未执行到unlock使用lock.isHeldByCurrentThread()判断性能突然下降Redis连接池是否耗尽Zookeeper是否出现GC停顿数据库锁等待超时锁被误删确保每个客户端使用唯一标识实现删除前的值校验if (redis.get(lockKey).equals(requestId)) { redis.del(lockKey); }5. 架构设计建议对于关键业务系统我建议采用多级锁策略第一层本地缓存锁Caffeine第二层分布式锁Redisson第三层数据库乐观锁version字段这种设计在保证一致性的同时能极大提升系统吞吐量。在最近的一个支付系统中我们通过这种方案将TPS从800提升到了12,000。对于锁的监控也至关重要建议记录每个锁的获取耗时监控锁等待队列长度设置锁竞争告警阈值分布式锁看似简单但要实现一个生产级可用的方案需要考虑诸多细节。经过多个项目的实践我认为Redisson是目前Java生态中最完善的解决方案值得作为首选方案。