这次我们来看分布式锁。在分布式系统中当多个服务实例需要协调访问共享资源时分布式锁是确保数据一致性和避免并发冲突的核心工具。它不是某个具体的软件而是一套设计模式和实现方案的总称。对于开发者而言理解分布式锁的关键不在于背诵概念而在于能否在实际项目中正确选型、稳定部署和有效排查问题。本文将直接切入核心分布式锁解决了什么问题主流实现方式有哪些各自的优缺点和适用场景是什么如何从零搭建一个可用的分布式锁服务以及在生产环境中如何避坑。如果你关心微服务架构下的数据一致性、高并发场景的资源争用或者正在准备相关的技术面试这篇文章可以直接收藏。我们将从原理到实践重点分析基于Redis、ZooKeeper等组件的实现并探讨Redisson客户端的最佳实践。1. 核心能力速览分布式锁本身不是“启动”或“部署”的单一服务而是一种能力集成。下表概括了其核心特性和实现考量能力项说明与考量核心目标在分布式系统中实现对共享资源的互斥访问保证操作的原子性与一致性。主流实现基于数据库、基于Redis、基于ZooKeeper/Etcd等。可靠性要求互斥性唯一持有、防死锁自动释放、容错性服务宕机锁能释放、高性能。客户端/工具RedissonRedis、CuratorZooKeeper等提供了开箱即用的高级API。适合场景秒杀库存扣减、分布式任务调度、防止重复提交、核心配置更新等。不适合场景对性能要求极端苛刻需评估锁粒度单机应用使用本地锁即可。2. 适用场景与使用边界分布式锁并非银弹它的引入会带来一定的性能开销和复杂度。明确其适用边界是正确使用的第一步。典型适用场景库存扣减与秒杀防止超卖。多个订单服务实例同时查询并修改同一商品库存时必须加锁。分布式任务调度确保多个调度器实例中同一时刻只有一个能触发定时任务执行。防止重复操作如用户连续点击提交订单通过锁确保订单创建逻辑只执行一次。全局配置更新在集群中更新一个共享配置时需要加锁防止更新过程中其他服务读取到不一致的中间状态。使用边界与注意事项性能损耗获取锁、释放锁涉及网络通信比本地锁慢。应尽量减小锁的粒度锁定特定资源ID而非全局和持有时间。复杂度提升需要引入额外的中间件如Redis、ZooKeeper并处理其可用性问题。错误使用风险锁未正确释放死锁、锁被误释放释放了其他客户端的锁、锁过期时间设置不当业务未执行完锁已释放是常见陷阱。并非替代事务分布式锁用于控制并发流程不能替代数据库事务的ACID特性。通常需要与事务结合使用。3. 环境准备与前置条件在动手实现或测试分布式锁之前需要准备好相应的基础设施和开发环境。1. 中间件服务任选其一或多种Redis: 推荐版本 5.0。需要部署Redis单机、哨兵或集群。这是目前最流行的分布式锁实现载体。ZooKeeper: 推荐版本 3.6。需要部署ZooKeeper集群通常奇数个节点如3台。数据库: 任何支持事务和唯一约束的关系型数据库如MySQL 5.7 PostgreSQL。2. 开发环境Java开发JDK 8 Maven或Gradle。我们将以Java/Spring Boot环境为例进行演示。依赖管理根据选择的中间件引入对应客户端。Redis:spring-boot-starter-data-redis或redisson-spring-boot-starter。ZooKeeper:curator-recipes。数据库: 对应的JDBC驱动如mysql-connector-java。3. 测试工具API测试Postman或cURL用于模拟并发请求。压力测试JMeter或编写多线程测试代码验证锁在高并发下的正确性。4. 实现方案对比与选型分布式锁主要有三种实现思路各有优劣。4.1 基于数据库的实现原理利用数据库的唯一约束或乐观锁版本号实现。唯一索引法创建一张锁表resource_name资源标识字段加唯一索引。获取锁即插入一条记录释放锁即删除该记录。利用数据库的唯一性保证互斥。乐观锁法为数据增加版本号字段更新时带版本号条件。优点实现简单依赖少仅需数据库。缺点性能差数据库连接和IO开销大。有死锁风险如客户端崩溃未删除记录。对数据库压力大不适合高并发。结论仅适用于并发量很低、且已有数据库依赖的简单场景不推荐作为主流方案。4.2 基于Redis的实现原理利用Redis的SET key value NX PX milliseconds命令。NX仅当key不存在时设置保证互斥性。PX设置key的过期时间毫秒防止死锁。value需设置为全局唯一值如UUID确保客户端只能释放自己持有的锁。优点性能极高Redis内存操作速度快。实现相对简单社区成熟如Redisson。支持可重入锁、公平锁、读写锁等多种锁类型。缺点可靠性挑战在Redis主从异步复制架构下主节点宕机可能导致锁丢失锁信息未同步到从节点从节点晋升后无锁记录。RedLock算法试图解决但仍有争议。需要处理锁续期WatchDog问题。结论目前最主流的选择适用于绝大多数对性能要求高、允许极小概率锁失效的场景。使用Redisson客户端可以规避很多底层问题。4.3 基于ZooKeeper的实现原理利用ZooKeeper的临时有序节点Ephemeral Sequential Node。每个客户端尝试在某个父节点下创建临时有序子节点。判断自己创建的节点是否是最小序号的节点如果是则获取锁。监听比自己序号小的前一个节点的删除事件一旦被删除则自己获得锁。会话结束客户端断开时临时节点自动删除锁释放。优点可靠性高基于ZooKeeper的CP特性和临时节点机制锁严格互斥无过期时间概念不会出现锁被误释放。具备公平锁特性按申请顺序获得锁。缺点性能比Redis差因为每次创建、删除节点都需要在集群中达成一致。部署和运维复杂度高于Redis。客户端需要处理连接断开和会话过期。结论适用于对锁的强一致性要求极高、并发量不是极端高的场景如金融核心交易。选型建议速查表场景需求推荐方案关键理由高并发允许极低概率失效如秒杀Redis Redisson性能为王Redisson封装完善。强一致性不允许锁失效如选主ZooKeeper/Etcd基于CP模型可靠性绝对优先。快速验证并发极低不想引入新组件数据库不推荐用于生产利用现有设施快速验证逻辑。5. 基于Redisson的Redis分布式锁实战鉴于Redis方案的普及性我们以Spring Boot集成Redisson为例展示一个完整的可落地实现。5.1 项目初始化与依赖引入首先创建一个Spring Boot项目并添加Redisson依赖。!-- pom.xml -- dependency groupIdorg.redisson/groupId artifactIdredisson-spring-boot-starter/artifactId version3.27.0/version !-- 请使用最新稳定版 -- /dependency5.2 Redisson配置在application.yml中配置Redis连接。这里以单机模式为例。# application.yml spring: redis: host: 127.0.0.1 port: 6379 # password: yourpassword # 如果有密码 database: 0 # Redisson特定配置可选通常默认即可 redisson: # 单节点配置 single-server-config: idle-connection-timeout: 10000 connect-timeout: 10000 timeout: 3000 retry-attempts: 3 retry-interval: 15005.3 编写锁工具类与服务创建一个锁工具类封装常用的加锁逻辑。import org.redisson.api.RLock; import org.redisson.api.RedissonClient; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Component; import java.util.concurrent.TimeUnit; Component public class DistributedLockHelper { Autowired private RedissonClient redissonClient; /** * 尝试加锁指定等待时间和锁持有时间 * param lockKey 锁的键通常为业务标识如 order:lock:1001 * param waitTime 最大等待锁时间秒 * param leaseTime 锁自动释放时间秒-1表示启用看门狗自动续期 * return 是否成功获取锁 */ public boolean tryLock(String lockKey, long waitTime, long leaseTime) { RLock lock redissonClient.getLock(lockKey); try { // 尝试获取锁 return lock.tryLock(waitTime, leaseTime, TimeUnit.SECONDS); } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 恢复中断状态 return false; } } /** * 释放锁 * param lockKey 锁的键 */ public void unlock(String lockKey) { RLock lock redissonClient.getLock(lockKey); if (lock.isHeldByCurrentThread()) { // 重要检查是否当前线程持有锁 lock.unlock(); } } /** * 可重入锁示例同一个线程可以多次获取同一把锁 */ public void reentrantLockDemo(String lockKey) { RLock lock redissonClient.getLock(lockKey); lock.lock(); // 第一次加锁 try { // ... 业务逻辑 ... innerMethod(lockKey); // 内部方法再次获取同一把锁 } finally { lock.unlock(); } } private void innerMethod(String lockKey) { RLock lock redissonClient.getLock(lockKey); lock.lock(); // 可重入计数器1不会阻塞 try { // ... 内部业务逻辑 ... } finally { lock.unlock(); // 计数器-1 } } }5.4 在业务服务中使用锁模拟一个库存扣减的业务场景。import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; import org.springframework.transaction.annotation.Transactional; Service public class InventoryService { Autowired private DistributedLockHelper lockHelper; Autowired private InventoryMapper inventoryMapper; // 假设的MyBatis Mapper private static final String LOCK_KEY_PREFIX inventory:lock:; /** * 扣减库存 - 使用分布式锁保护 * param productId 商品ID * param quantity 扣减数量 * return 是否扣减成功 */ Transactional(rollbackFor Exception.class) public boolean deductInventory(Long productId, Integer quantity) { String lockKey LOCK_KEY_PREFIX productId; boolean locked false; try { // 尝试获取锁最多等待3秒锁持有10秒业务应在10秒内完成 locked lockHelper.tryLock(lockKey, 3, 10); if (!locked) { throw new RuntimeException(系统繁忙请稍后重试); } // 1. 查询当前库存 Inventory inventory inventoryMapper.selectById(productId); if (inventory null) { throw new RuntimeException(商品不存在); } // 2. 校验库存是否充足 if (inventory.getStock() quantity) { throw new RuntimeException(库存不足); } // 3. 扣减库存 inventory.setStock(inventory.getStock() - quantity); inventoryMapper.updateById(inventory); // 4. 记录日志等后续操作... return true; } finally { // 确保锁被释放 if (locked) { lockHelper.unlock(lockKey); } } } }5.5 功能测试与效果验证测试目的验证分布式锁在高并发下能否正确防止超卖。操作步骤启动服务确保Redis服务运行启动Spring Boot应用。准备数据在数据库中插入一条商品记录库存设置为100。编写并发测试使用JMeter或以下简单的Java多线程代码模拟100个并发请求每个请求扣减1个库存。import java.util.concurrent.CountDownLatch; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; public class ConcurrentTest { public static void main(String[] args) throws InterruptedException { int threadCount 100; ExecutorService executor Executors.newFixedThreadPool(threadCount); CountDownLatch latch new CountDownLatch(threadCount); // 假设通过HTTP调用或直接调用Service // InventoryService service ...; for (int i 0; i threadCount; i) { executor.submit(() - { try { // 调用 deductInventory(1L, 1) 100次 // boolean success service.deductInventory(1L, 1); // System.out.println(扣减结果: success); } finally { latch.countDown(); } }); } latch.await(); executor.shutdown(); // 最终查询库存应为0。如果不为0说明锁失效。 } }预期结果与判断标准成功最终数据库库存为0日志中无“库存不足”异常除非并发数大于初始库存。所有扣减请求有序执行。失败锁失效最终库存大于0或出现负库存超卖。可能观察到大量“系统繁忙”提示获取锁失败。常见失败原因Redis连接失败检查Redis地址、端口、密码。锁未释放业务代码异常未执行到finally块。确保使用try-finally或try-with-resources。锁被误释放lockKey设计不合理导致不同业务冲突或释放锁时未检查持有者。Redisson的unlock内部已做线程标识校验但自己实现的锁需注意。锁过期时间太短业务未执行完锁自动释放其他线程进入。需合理评估业务耗时或使用Redisson的看门狗leaseTime-1自动续期。6. 接口API与批量任务考量分布式锁本身不直接提供HTTP API但它保护的业务接口是API。在微服务架构下需要关注1. 接口的幂等性与锁的配合即使有锁网络超时可能导致客户端重试。接口设计应具备幂等性如使用唯一请求ID避免锁内业务被重复执行。示例下单请求携带requestId在锁保护下先检查requestId是否已处理过。2. 批量任务中的锁粒度场景一个批量任务需要处理1000个商品库存。错误做法对整个任务加一个全局锁串行处理性能极差。正确做法对每个商品ID加锁细粒度锁允许不同商品并行处理。可以使用线程池配合CompletableFuture。// 伪代码批量处理中的细粒度锁 public void batchProcess(ListLong productIds) { productIds.parallelStream().forEach(productId - { String lockKey product:lock: productId; if (lockHelper.tryLock(lockKey, 1, 5)) { try { processSingleProduct(productId); // 处理单个商品 } finally { lockHelper.unlock(lockKey); } } else { // 记录该商品处理失败稍后重试或告警 } }); }7. 资源占用与性能观察分布式锁的性能开销主要来自网络延迟和中间件本身。1. 资源占用观察点Redis内存与CPU每个锁对应一个Redis键。大量锁会占用少量内存。高频率的加锁/解锁操作会增加Redis的CPU负载。通过Redis的INFO命令或监控工具观察used_memory、cpu_usage和commandstats重点关注SET、EVAL等命令调用次数。应用端连接数Redisson客户端与Redis保持长连接。观察应用服务器的网络连接数。应用端线程阻塞获取锁时的等待waitTime会阻塞业务线程。监控应用线程池的活跃线程数和等待时间。2. 性能优化建议降低锁粒度这是最有效的优化。锁的键应精确到具体资源如用户ID、订单号、商品SKU而不是整个服务或数据库表。减少锁持有时间只在进行共享资源操作时加锁锁内逻辑应尽可能简单、快速。避免在锁内进行远程调用、复杂计算或IO操作。使用本地锁做前置过滤对于一些热点资源可以在JVM内部先用ReentrantLock或synchronized做一层快速失败过滤减少对分布式锁的请求压力。合理设置超时waitTime不宜过长避免线程池被占满。leaseTime应略大于业务平均执行时间或使用看门狗自动续期。选择高性能模式如果使用Redis在可接受风险下使用单机或Proxy模式通常比集群模式延迟更低。8. 常见问题与排查方法分布式锁的“坑”很多下表列出了典型问题及应对策略。问题现象可能原因排查方式解决方案库存超卖1. 锁未生效配置错误。2. 锁过期释放业务未执行完。3. 锁被误释放非持有者解锁。1. 检查Redis连接和命令执行日志。2. 在锁前后打印带时间戳的日志计算业务耗时与锁超时时间。3. 检查锁的value客户端标识是否唯一。1. 确保SET NX PX命令正确执行。2. 延长锁超时时间或启用看门狗续期。3. 使用Redisson等成熟客户端其unlock逻辑已包含线程标识校验。系统响应变慢大量超时1. 锁竞争激烈大量线程在等待。2. Redis或ZooKeeper中间件性能瓶颈。3. 锁粒度太粗。1. 监控应用线程池状态和锁等待时间。2. 监控中间件的CPU、内存、网络IO。3. 分析锁键的设计。1. 优化业务逻辑减少锁持有时间。2. 升级中间件配置或做集群扩容。3.细化锁粒度将全局锁改为基于资源ID的锁。获取锁永远失败1. 锁未被释放死锁。2.waitTime设置过短。3. 网络分区导致客户端与锁服务失联。1. 查看Redis中锁的Key是否一直存在TTL。2. 检查业务代码finally块是否确保释放锁。3. 检查网络连通性。1. 必须设置锁的过期时间。2. 确保释放锁的代码一定会执行try-finally。3. 对于Redis考虑使用Redisson的看门狗机制避免业务未完成锁过期。Redis主从切换后锁失效Redis主节点宕机异步复制导致从节点丢失锁信息。模拟主节点宕机观察业务是否出现并发问题。1. 对锁一致性要求不高的场景可接受。2. 要求高的场景可考虑a. 使用RedLock多主Redis实例有争议。b. 切换到ZooKeeper/Etcd等CP模型组件。ZooKeeper连接断开锁丢失客户端与ZooKeeper会话过期临时节点被删除。查看ZooKeeper日志和客户端连接状态监听器。1. 合理配置会话超时时间。2. 客户端实现ConnectionStateListener在会话过期时进行业务补偿或告警。3. 使用Curator框架它封装了连接重试和会话管理。9. 最佳实践与使用建议锁命名规范使用业务前缀和资源标识如service:resource_type:resource_idorder:pay:123。避免不同业务间的键冲突。务必设置超时时间无论是Redis的PX还是业务代码中的waitTime都必须设置。这是防止死锁的生命线。释放锁必须放在finally块确保任何情况下正常返回、异常、中断锁都能被释放。避免锁内长耗时操作锁内只进行必要的共享资源操作。RPC调用、文件IO、复杂计算等应移到锁外。非必要不使用读锁读写锁RReadWriteLock适用于读多写少且读操作耗时的场景。如果读操作很快使用互斥锁更简单可靠。测试测试测试必须进行高并发集成测试验证锁的正确性和性能。使用CountDownLatch、Semaphore或压力测试工具模拟并发。监控与告警监控分布式锁的获取成功率、平均等待时间、锁持有时间。设置异常告警如获取锁失败率突增。有备选方案理解锁失效的可能性和影响。设计业务时考虑锁失效后的处理如使用数据库乐观锁做最终兜底。10. 总结与下一步分布式锁是分布式系统并发控制的基石其核心价值在于用性能和安全上的一点妥协换取数据在分布式环境下的一致性。Redisson提供的Redis分布式锁方案因其高性能和易用性成为大多数场景下的首选而在对一致性有严苛要求的领域ZooKeeper则提供了更可靠的保证。最先应该验证的是锁的互斥性和防死锁特性。写一个简单的多线程测试程序操作一个共享计数器如果不加锁结果错误加了锁结果正确并且程序能正常结束就迈出了第一步。最容易踩的坑是锁过期时间设置不当和锁被误释放。务必使用像Redisson这样成熟的客户端它们内部处理了锁续期、重入、线程标识等复杂问题能帮你避开大多数陷阱。下一步你可以深入探索Redisson更多特性如公平锁、联锁MultiLock、红锁RedLock、信号量Semaphore、可过期对象RExpirable。与Spring Cloud集成在微服务框架下如何优雅地管理锁的生命周期。性能压测与调优针对你的业务场景找到最佳的锁超时时间、等待时间和锁粒度。研究其他方案如基于Etcd的分布式锁了解其Raft协议如何保证强一致性。理解原理动手实践关注监控你就能在分布式系统中稳健地驾驭这把“锁”。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
