1. 项目背景与核心挑战霸王餐资格发放是外卖平台常见的营销手段但每逢大促期间系统面临的并发压力往往呈指数级增长。去年双十一期间某头部平台就曾因资格超发导致数百万损失。这个项目要解决的正是如何在每秒数万次请求的冲击下确保每个霸王餐资格都能精准发放且绝不重复。分布式锁作为解决这类问题的关键技术方案其选型直接影响系统的三个核心指标准确性必须100%避免超发高性能不能因锁机制拖慢整体响应高可用不能因锁服务故障导致业务停摆2. 分布式锁方案深度对比2.1 Redis单节点实现方案基于SETNX命令的经典实现// 伪代码示例 Boolean lockAcquired redis.setnx(lockKey, requestId, expireTime); if(lockAcquired) { try { // 业务处理 } finally { // 确保只释放自己的锁 if(requestId.equals(redis.get(lockKey))) { redis.del(lockKey); } } }致命缺陷锁过期时间难设定业务处理时间可能超过expire非原子性操作风险get和del非原子操作单点故障问题2.2 Redisson分布式锁实现Redisson通过lua脚本解决了原子性问题if (redis.call(exists, KEYS[1]) 0) then redis.call(hset, KEYS[1], ARGV[2], 1) redis.call(pexpire, KEYS[1], ARGV[1]) return nil end核心优势看门狗机制自动续期可重入锁设计支持多种锁类型公平锁、联锁等2.3 ZooKeeper方案实现基于临时顺序节点// 创建临时节点 String lockPath zk.create(/locks/meal-, null, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); // 获取所有子节点并排序 ListString children zk.getChildren(/locks, false); Collections.sort(children); // 检查是否获得锁 if (lockPath.endsWith(children.get(0))) { // 业务处理 }特性对比表特性Redis单节点RedissonZooKeeper性能(ops/sec)100,00080,00020,000可靠性低中高实现复杂度简单中等复杂网络分区容忍度无部分完全锁自动释放定时可续期会话结束3. 压测数据与选型建议3.1 基准测试环境服务器配置8核16G云主机测试工具JMeter 5.4.1并发梯度1k、5k、10k、20k QPS3.2 关键指标对比吞吐量对比(QPS)Redis单节点12,345 → 9,876 → 8,543 → 6,789 Redisson10,987 → 9,765 → 8,901 → 7,654 ZooKeeper5,432 → 4,321 → 3,456 → 2,109错误率对比(%)Redis单节点0.01 → 0.05 → 0.12 → 0.89 Redisson0 → 0 → 0.01 → 0.03 ZooKeeper0 → 0 → 0 → 03.3 选型决策树是否需要强一致性是 → ZooKeeper否 → 进入下一步是否要求超高吞吐是 → Redis/Redisson否 → 进入下一步是否有运维ZooKeeper能力是 → 根据业务特性选择否 → Redisson4. 生产环境实施方案4.1 Redisson最佳配置singleServerConfig: idleConnectionTimeout: 10000 connectTimeout: 5000 timeout: 3000 retryAttempts: 3 retryInterval: 1500 subscriptionsPerConnection: 5 clientName: meal-lock address: redis://127.0.0.1:6379 subscriptionConnectionMinimumIdleSize: 1 subscriptionConnectionPoolSize: 50 connectionMinimumIdleSize: 10 connectionPoolSize: 1004.2 降级方案设计// 多级降级策略 public boolean acquireLock(String lockKey) { // 第一级Redisson RLock lock redisson.getLock(lockKey); if(lock.tryLock(0, 10, SECONDS)) return true; // 第二级本地缓存 if(localCache.tryLock(lockKey)) return true; // 第三级数据库乐观锁 return dbOptimisticLock(lockKey); }5. 典型问题排查实录5.1 锁提前释放问题现象出现资格超发日志显示锁在业务完成前消失根因分析业务处理时间 lockWatchdogTimeout(默认30秒)未正确捕获异常导致锁未续期解决方案调整watchdog超时时间添加异常处理模板RLock lock redisson.getLock(lockKey); try { lock.lock(); // 业务代码 } catch (Exception e) { lock.forceUnlock(); throw e; } finally { if(lock.isLocked() lock.isHeldByCurrentThread()) { lock.unlock(); } }5.2 集群脑裂问题现象主从切换期间出现双发解决方案启用RedLock算法需至少3个独立Redis实例配置最小存活节点数Config config new Config(); config.useClusterServers() .setCheckSlotsCoverage(false) .setMasterConnectionMinimumIdleSize(3) .addNodeAddress(redis://127.0.0.1:7000);6. 性能优化技巧锁粒度控制错误做法锁定整个资格池正确做法按城市ID活动ID分段锁定锁等待策略优化// 原始方式性能差 lock.lock(); // 优化方案吞吐提升40% if(!lock.tryLock(50, TimeUnit.MILLISECONDS)) { // 快速失败返回排队位置 return Response.busy(queuePosition); }热点key预防对抢购资格实施随机sleep(0-50ms)采用分段统计再汇总的方案实际案例某平台通过上述优化在同等硬件条件下将峰值处理能力从8k QPS提升到15k QPS错误率从0.15%降至0.002%。关键技巧在于将锁竞争从全局维度拆分为地域维度同时引入分级降级策略确保极端情况下的系统可用性。