一、为什么需要分布式锁——从单机到分布式的必然选择1.1 单机锁的局限性在传统单体架构中我们习惯使用synchronized、ReentrantLock等同步机制来控制并发访问。但这些锁机制存在致命缺陷仅限于单 JVM只能锁住同一个 Java 虚拟机内的线程无法跨进程当服务部署在多台服务器上时每台机器都有独立的锁实例无法跨网络不同服务实例之间无法感知彼此的锁状态1.2 真实业务场景的痛点电商秒杀场景库存只有 10 件商品但成千上万的用户同时下单。在分布式部署架构下服务 A 实例扣减库存到 5 件服务 B 实例同时读取库存还是 10 件也扣减到 5 件最终库存变成 0但实际只卖出了 10 件却扣减了 20 件库存支付对账场景多个对账任务同时执行都需要更新对账状态表如果没有分布式锁可能导致状态错乱。1.3 分布式锁的核心价值跨进程互斥保证同一时刻只有一个客户端能执行关键代码数据一致性避免多个服务实例同时修改共享资源导致的数据不一致业务可靠性确保关键业务逻辑的原子性和完整性二、分布式锁的六大必备条件——生产环境的底线要求一个真正可用的分布式锁必须满足以下核心条件条件说明重要性互斥性任意时刻只有一个客户端能持有锁⭐⭐⭐⭐⭐防死锁锁持有者崩溃时锁能自动释放如设置超时时间⭐⭐⭐⭐⭐容错性锁服务本身高可用部分节点故障不影响整体功能⭐⭐⭐⭐可重入性同一线程可重复获取已持有的锁避免自己阻塞自己⭐⭐⭐高性能加锁、解锁操作要快延迟低避免成为系统瓶颈⭐⭐⭐⭐公平性按照请求顺序获取锁避免饥饿现象可选但重要⭐⭐⭐重点强调在生产环境中互斥性和防死锁是绝对不能妥协的底线要求三、分布式锁的常见实现方案——技术选型指南3.1 主流方案对比实现方式核心原理优点缺点适用场景数据库乐观锁版本号或唯一键约束简单无需额外组件性能差易死锁不适合高并发低并发、快速验证场景 Redis 方案 SETNX 过期时间 Lua 脚本高性能实现简单生态成熟依赖时钟主从切换可能丢锁高并发、允许极少量不一致的场景 ZooKeeper 方案临时顺序节点 Watch 机制强一致性无死锁风险天然公平性能相对较低运维成本高金融级、强一致性要求场景 Etcd 方案 Raft 共识 Lease Revision 强一致云原生友好生态相对小众 Kubernetes实现方式核心原理优点缺点适用场景数据库乐观锁版本号或唯一键约束简单无需额外组件性能差易死锁不适合高并发低并发、快速验证场景Redis方案SETNX 过期时间 Lua脚本高性能实现简单生态成熟依赖时钟主从切换可能丢锁高并发、允许极少量不一致的场景ZooKeeper方案临时顺序节点 Watch机制强一致性无死锁风险天然公平性能相对较低运维成本高金融级、强一致性要求场景Etcd方案Raft共识 Lease Revision强一致云原生友好生态相对小众Kubernetes环境、云原生架构环境、云原生架构3.2 方案选型建议首选 Redis90% 的业务场景特别是高并发、低延迟要求的场景金融级场景选 ZooKeeper/Etcd对数据一致性要求极高的场景如资金转账、库存扣减避免自研除非有特殊需求否则优先使用成熟框架如 Redisson、Curator四、Redis 分布式锁实战——高性能方案详解4.1 核心原理深度剖析基础命令SET lock_key unique_value NX PX 30000NXOnly set the key if it does not already exist保证互斥PXSet the expiration time in milliseconds防死锁unique_valueUUID 等唯一标识安全释放锁释放锁的原子性问题-- Lua 脚本保证原子性 if Redis.call(「get」, KEYS[1]) ARGV[1] then return Redis.call(「del」, KEYS[1]) else return 0 end为什么要用 Lua 脚本因为”判断 value 是否匹配”和”删除 key”是两个操作如果不原子执行可能出现客户端 A 判断 value 匹配锁恰好过期客户端 B 获取到新锁客户端 A 删除了客户端 B 的锁4.2 Spring Boot 完整实现生产级4.2.1 基础依赖配置dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-Redis/artifactId /dependency dependency groupIdorg.redisson/groupId artifactIdredisson-spring-boot-starter/artifactId version3.27.0/version /dependency4.2.2 Redisson 配置Configuration public class RedissonConfig { Value(「${spring.Redis.host}」) private String redisHost; Value(「${spring.Redis.port}」) private int redisPort; Bean(destroyMethod 「shutdown」) public RedissonClient redissonClient() { Config config new Config(); config.useSingleServer() .setAddress(「Redis://」 redisHost 「:」 redisPort) .setConnectionPoolSize(10) .setConnectionMinimumIdleSize(5) .setRetryAttempts(3) .setRetryInterval(1000); return Redisson.create(config); } }4.2.3 业务代码示例Service public class OrderService { Autowired private RedissonClient redissonClient; Autowired private InventoryService inventoryService; /** * 创建订单带分布式锁 * / public Order createOrder(String userId, String productId, int quantity) { // 锁 key订单创建锁 产品 ID String lockKey 「order:create:」 productId; // 获取锁看门狗自动续期 RLock lock redissonClient.getLock(lockKey); try { // 尝试获取锁最多等待 10 秒锁自动释放时间 30 秒 boolean locked lock.tryLock(10, 30, TimeUnit.SECONDS); if (!locked) { throw new BusinessException(「系统繁忙请稍后重试」); } // 检查库存 if (!inventoryService.checkStock(productId, quantity)) { throw new BusinessException(「库存不足」); } // 扣减库存并创建订单 inventoryService.deductStock(productId, quantity); return orderRepository.save(new Order(userId, productId, quantity)); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new BusinessException(「获取锁被中断」); } finally { // 释放锁 if (lock.isLocked() lock.isHeldByCurrentThread()) { lock.unlock(); } } } }4.3 Redisson 实现原理揭秘看门狗Watchdog机制当锁未指定 leaseTimeout 时默认 30 秒过期后台启动定时任务每 10 秒检查一次如果客户端仍持有锁自动重置过期时间为 30 秒业务完成后手动释放锁取消看门狗优势无需手动设置过期时间避免业务执行时间过长导致锁提前释放自动续期保证业务完整性五、ZooKeeper 分布式锁实战——强一致性方案5.1 核心原理深度解析ZooKeeper 节点类型持久节点客户端断开后依然存在临时节点客户端会话结束自动删除关键顺序节点父节点下自动生成递增序号加锁流程公平锁所有客户端在/locks/order下创建临时顺序节点获取所有子节点判断自己创建的节点序号是否最小如果是最小获取锁成功如果不是最小监听前一个序号节点的删除事件前一个节点删除后重新判断释放锁删除临时节点或会话断开自动删除优势强一致性ZAB 协议保证数据一致性无死锁临时节点自动释放天然公平按创建顺序获取锁5.2 Spring Boot 完整实现Curator 框架5.2.1 依赖配置dependency groupIdorg.apache.curator/groupId artifactIdcurator-recipes/artifactId version5.5.0/version /dependency dependency groupIdorg.apache.curator/groupId artifactIdcurator-framework/artifactId version5.5.0/version /dependency5.2.2 Curator 客户端配置Configuration public class ZookeeperConfig { Value(「${zookeeper.address}」) private String zkAddress; Value(「${zookeeper.sessionTimeout}」) private int sessionTimeout 30000; Value(「${zookeeper.connectionTimeout}」) private int connectionTimeout 15000; Bean(initMethod 「start」, destroyMethod 「close」) public CuratorFramework curatorFramework() { // 重试策略指数退避初始 1 秒最多 3 次 RetryPolicy retryPolicy new ExponentialBackoffRetry(1000, 3); return CuratorFrameworkFactory.builder() .connectString(zkAddress) .sessionTimeoutMs(sessionTimeout) .connectionTimeoutMs(connectionTimeout) .retryPolicy(retryPolicy) .build(); } }5.2.3 业务代码示例Service public class PaymentService { Autowired private CuratorFramework curatorFramework; Autowired private AccountService accountService; /** * 转账操作强一致性要求 * / public boolean transfer(String fromAccount, String toAccount, BigDecimal amount) { // 锁路径/locks/transfer/{fromAccount} String lockPath 「/locks/transfer/」 fromAccount; InterProcessMutex lock new InterProcessMutex(curatorFramework, lockPath); try { // 尝试获取锁最多等待 15 秒 if (!lock.acquire(15, TimeUnit.SECONDS)) { throw new BusinessException(「获取锁超时请稍后重试」); } // 检查余额 BigDecimal balance accountService.getBalance(fromAccount); if (balance.compareTo(amount) 0) { throw new BusinessException(「余额不足」); } // 执行转账强一致性要求 accountService.deduct(fromAccount, amount); accountService.add(toAccount, amount); return true; } catch (Exception e) { log.error(「转账失败」, e); throw new BusinessException(「转账失败」 e.getMessage()); } finally { try { // 释放锁 if (lock.isAcquiredInThisProcess()) { lock.release(); } } catch (Exception e) { log.error(「释放锁失败」, e); } } } }5.3 ZooKeeper vs Redis 深度对比维度 ZooKeeperRedis 一致性强一致性ZAB 协议最终一致性主从异步性能较低涉及磁盘写入极高内存操作可靠性无单点风险自动故障转移依赖哨兵/集群主从切换可能丢锁实现复杂度较高需要维护 ZK 集群较低Redis维度ZooKeeperRedis一致性强一致性ZAB协议最终一致性主从异步性能较低涉及磁盘写入极高内存操作可靠性无单点风险自动故障转移依赖哨兵/集群主从切换可能丢锁实现复杂度较高需要维护ZK集群较低Redis部署简单适用场景金融级、强一致性要求高并发、允许极少量不一致部署简单适用场景金融级、强一致性要求高并发、允许极少量不一致六、生产环境最佳实践——避坑指南6.1 Redis 方案注意事项避免锁过期问题业务执行时间可能超过锁过期时间使用 Redisson 看门狗自动续期业务拆分避免长事务主从切换风险单机 Redis 哨兵架构足够应对大多数场景极端重要场景考虑 Redlock 算法争议较大性能优化使用连接池合理设置超时时间避免在锁内执行 IO 操作6.2 ZooKeeper 方案注意事项会话超时设置合理配置 sessionTimeout避免网络抖动导致频繁释放锁一般设置为 30-60 秒连接管理使用连接池处理连接断开重连监控 ZK 集群状态节点路径设计避免创建过多节点合理设计节点层级定期清理无用节点6.3 通用最佳实践锁粒度尽量细粒度锁避免大范围锁竞争超时机制必须设置获取锁的超时时间避免无限等待异常处理完善的异常处理和日志记录监控告警监控锁的获取时间、持有时间、失败率降级策略当锁服务不可用时有降级方案七、总结与选型决策树7.1 技术选型决策树7.2 核心结论90% 场景选 Redis性能高、实现简单、生态成熟10% 关键场景选 ZooKeeper强一致性、无死锁风险、金融级要求永远不要自研除非有特殊需求否则优先使用成熟框架锁是最后手段优先考虑无锁化设计如分库分表、消息队列