1. 项目背景与核心挑战外卖平台的霸王餐活动是典型的秒杀场景——有限数量的免费餐食资格需要在极短时间内公平发放给海量用户。去年双十一期间某头部平台单日峰值请求量突破50万QPS而库存量仅有5000份。这种万分之一的中签率对系统提出了三大核心挑战超卖风险当100个服务器节点同时判断剩余库存0时可能同时发出100个资格实际超发95个性能瓶颈传统数据库行锁在10万QPS下响应延迟超过2秒导致用户体验灾难死锁问题网络抖动时可能出现锁无法释放造成整个发放服务瘫痪2. 分布式锁技术选型矩阵2.1 Redis单节点锁SETNX方案基础实现方案// 加锁 Boolean locked redisTemplate.opsForValue().setIfAbsent(lock:activity_123, requestId, 30, TimeUnit.SECONDS); // 解锁Lua脚本保证原子性 String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; redisTemplate.execute(new DefaultRedisScript(script, Long.class), Collections.singletonList(lock:activity_123), requestId);压测数据JMeter 5万并发指标数值平均耗时12ms错误率0.3%死锁发生率1次/小时致命缺陷主从切换时可能出现锁丢失。曾实测在Redis主节点宕机后从节点提升期间有200ms窗口期导致双发资格。2.2 Redisson红锁RedLock多节点部署方案Config config1 new Config(); config1.useSingleServer().setAddress(redis://node1:6379); RedissonClient client1 Redisson.create(config1); // 类似配置其他4个节点 RLock lock1 client1.getLock(lock); RLock lock2 client2.getLock(lock); RLock redLock new RedissonRedLock(lock1, lock2, lock3, lock4, lock5); try { if(redLock.tryLock(100, 10, TimeUnit.SECONDS)) { // 业务逻辑 } } finally { redLock.unlock(); }性能对比维度SETNXRedLock吞吐量(QPS)85003200网络要求单节点多节点一致性强度弱强适用场景非关键业务金融级业务2.3 ZooKeeper临时顺序节点CP系统实现方案public class ZkDistributedLock implements Watcher { private ZooKeeper zk; private String lockPath; public boolean tryLock() throws Exception { // 创建临时顺序节点 String node zk.create(lockPath /lock_, new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); // 获取所有子节点并排序 ListString children zk.getChildren(lockPath, false); Collections.sort(children); // 判断是否获得锁 return node.endsWith(children.get(0)); } }特殊场景表现强一致性场景在ZK集群中写请求需要超过半数节点确认实测写延迟在200ms左右惊群效应当释放锁时所有监听节点都会收到通知可能引发短暂流量风暴3. 混合锁架构实战方案3.1 分层锁设计graph TD A[接入层] --|本地限流| B(Redis集群) B --|Redisson锁| C[资格服务] C --|ZK分布式锁| D[库存中心]关键配置参数Redis锁过期时间建议设置为业务平均耗时的3倍如业务需2秒则设6秒锁等待超时根据TP99响应时间设置通常不超过800ms重试次数建议2-3次避免雪崩3.2 性能优化技巧锁粒度控制错误做法lock:activity_all全局大锁正确做法lock:activity_123_user_456用户维度锁锁分段技术// 将库存拆分为10个段 int segment userId.hashCode() % 10; RLock lock redisson.getLock(lock:segment_ segment);预热与降级活动前1小时预热连接池当Redis响应超时500ms时自动降级到本地缓存4. 生产环境监控要点4.1 关键监控指标指标名称报警阈值采集方式锁等待时间300msRedisson Metric锁持有时间5s自定义埋点锁竞争失败率15%PrometheusZK节点变更通知延迟1sZK自带监控4.2 典型故障案例案例1锁提前过期现象日志中出现未持有锁却执行解锁错误根因GC停顿导致业务逻辑未完成锁已过期解决方案引入锁续期机制// Redisson自动续期配置 config.setLockWatchdogTimeout(30000);案例2跨机房延迟现象上海机房已释放锁但北京机房5秒后才感知根因ZK集群跨机房部署时时钟不同步解决方案采用同城多活架构时钟偏差控制在200ms内5. 终极方案RedisZK双校验对于资金级别的重要业务我们最终采用的架构第一层Redis快速过滤99%请求性能优先第二层ZK保证最终一致性安全优先异步对账每小时跑一次库存校正任务这个方案在去年双十一实现了零超卖平均响应时间23ms峰值QPS 12万实际编码中最大的教训是永远要为锁操作添加唯一标识如UUID我们曾因未使用requestId导致误删其他线程的锁。现在团队强制使用这种模式String lockKey coupon: activityId; String requestId UUID.randomUUID().toString(); try { boolean locked redisLock.tryLock(lockKey, requestId, 10, TimeUnit.SECONDS); if(locked) { // 业务逻辑 } } finally { redisLock.unlock(lockKey, requestId); } 
长河君 · 2026/10/27 21:13:39 · 阅读 1.2k 高并发场景下分布式锁技术选型与实战优化
1. 项目背景与核心挑战外卖平台的霸王餐活动是典型的秒杀场景——有限数量的免费餐食资格需要在极短时间内公平发放给海量用户。去年双十一期间某头部平台单日峰值请求量突破50万QPS而库存量仅有5000份。这种万分之一的中签率对系统提出了三大核心挑战超卖风险当100个服务器节点同时判断剩余库存0时可能同时发出100个资格实际超发95个性能瓶颈传统数据库行锁在10万QPS下响应延迟超过2秒导致用户体验灾难死锁问题网络抖动时可能出现锁无法释放造成整个发放服务瘫痪2. 分布式锁技术选型矩阵2.1 Redis单节点锁SETNX方案基础实现方案// 加锁 Boolean locked redisTemplate.opsForValue().setIfAbsent(lock:activity_123, requestId, 30, TimeUnit.SECONDS); // 解锁Lua脚本保证原子性 String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; redisTemplate.execute(new DefaultRedisScript(script, Long.class), Collections.singletonList(lock:activity_123), requestId);压测数据JMeter 5万并发指标数值平均耗时12ms错误率0.3%死锁发生率1次/小时致命缺陷主从切换时可能出现锁丢失。曾实测在Redis主节点宕机后从节点提升期间有200ms窗口期导致双发资格。2.2 Redisson红锁RedLock多节点部署方案Config config1 new Config(); config1.useSingleServer().setAddress(redis://node1:6379); RedissonClient client1 Redisson.create(config1); // 类似配置其他4个节点 RLock lock1 client1.getLock(lock); RLock lock2 client2.getLock(lock); RLock redLock new RedissonRedLock(lock1, lock2, lock3, lock4, lock5); try { if(redLock.tryLock(100, 10, TimeUnit.SECONDS)) { // 业务逻辑 } } finally { redLock.unlock(); }性能对比维度SETNXRedLock吞吐量(QPS)85003200网络要求单节点多节点一致性强度弱强适用场景非关键业务金融级业务2.3 ZooKeeper临时顺序节点CP系统实现方案public class ZkDistributedLock implements Watcher { private ZooKeeper zk; private String lockPath; public boolean tryLock() throws Exception { // 创建临时顺序节点 String node zk.create(lockPath /lock_, new byte[0], ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); // 获取所有子节点并排序 ListString children zk.getChildren(lockPath, false); Collections.sort(children); // 判断是否获得锁 return node.endsWith(children.get(0)); } }特殊场景表现强一致性场景在ZK集群中写请求需要超过半数节点确认实测写延迟在200ms左右惊群效应当释放锁时所有监听节点都会收到通知可能引发短暂流量风暴3. 混合锁架构实战方案3.1 分层锁设计graph TD A[接入层] --|本地限流| B(Redis集群) B --|Redisson锁| C[资格服务] C --|ZK分布式锁| D[库存中心]关键配置参数Redis锁过期时间建议设置为业务平均耗时的3倍如业务需2秒则设6秒锁等待超时根据TP99响应时间设置通常不超过800ms重试次数建议2-3次避免雪崩3.2 性能优化技巧锁粒度控制错误做法lock:activity_all全局大锁正确做法lock:activity_123_user_456用户维度锁锁分段技术// 将库存拆分为10个段 int segment userId.hashCode() % 10; RLock lock redisson.getLock(lock:segment_ segment);预热与降级活动前1小时预热连接池当Redis响应超时500ms时自动降级到本地缓存4. 生产环境监控要点4.1 关键监控指标指标名称报警阈值采集方式锁等待时间300msRedisson Metric锁持有时间5s自定义埋点锁竞争失败率15%PrometheusZK节点变更通知延迟1sZK自带监控4.2 典型故障案例案例1锁提前过期现象日志中出现未持有锁却执行解锁错误根因GC停顿导致业务逻辑未完成锁已过期解决方案引入锁续期机制// Redisson自动续期配置 config.setLockWatchdogTimeout(30000);案例2跨机房延迟现象上海机房已释放锁但北京机房5秒后才感知根因ZK集群跨机房部署时时钟不同步解决方案采用同城多活架构时钟偏差控制在200ms内5. 终极方案RedisZK双校验对于资金级别的重要业务我们最终采用的架构第一层Redis快速过滤99%请求性能优先第二层ZK保证最终一致性安全优先异步对账每小时跑一次库存校正任务这个方案在去年双十一实现了零超卖平均响应时间23ms峰值QPS 12万实际编码中最大的教训是永远要为锁操作添加唯一标识如UUID我们曾因未使用requestId导致误删其他线程的锁。现在团队强制使用这种模式String lockKey coupon: activityId; String requestId UUID.randomUUID().toString(); try { boolean locked redisLock.tryLock(lockKey, requestId, 10, TimeUnit.SECONDS); if(locked) { // 业务逻辑 } } finally { redisLock.unlock(lockKey, requestId); }