秒杀系统架构设计：高并发场景下的分布式锁与库存优化

1. 秒杀场景的技术挑战与核心诉求淘宝闪购SPS这类秒杀业务对后端服务的冲击本质上是一场关于有限资源公平分配的技术战役。去年双11期间某品牌新款手机在淘宝闪购上线时瞬时请求量达到了惊人的42万QPS而库存量仅有2000台。这种数万人抢购几十件商品的场景暴露出三个核心矛盾点第一是资源争抢的物理限制。单个商品库存可能只占Redis中一个简单的键值对如item_123_stock: 2000但数万线程同时对这个键进行DECR操作时网络带宽、CPU时间片、磁盘I/O都成为瓶颈。我们曾用Arthas监控发现在未优化前单次库存扣减操作平均需要经历1次TCP传输约0.3ms 1次Redis命令排队约1.2ms 1次持久化日志写入约5ms这意味着单个商品的理论处理上限很难超过1000TPS。第二是公平性与用户体验的平衡。当使用简单分布式锁时虽然能保证数据一致性但前几毫秒拿到锁的客户端可能已经处理完所有库存导致后续99%的请求直接返回已售罄。某次大促中我们观察到98.7%的成功交易集中在最初300毫秒内完成这种瞬间秒光的体验对用户并不友好。第三是系统自我保护的需求。2020年某次秒杀活动曾因流量过大导致Redis连接数暴增进而引发FullGC最终整个集群雪崩。事后分析发现当时每个请求都在竞争同一把全局锁持有锁的线程因MySQL写入延迟导致锁超时而重试机制又加剧了竞争。2. 分层削峰架构设计2.1 流量漏斗模型我们采用四级流量过滤机制构建分层防御体系用户请求 → 前端限流 → 网关层限流 → 服务层限流 → 队列削峰 (滑动窗口) (令牌桶) (漏桶) (RabbitMQ)第一层的前端限流通过在H5页面植入JavaScript计数器实现。当点击立即抢购按钮时会先执行本地校验let clickCount 0; function handleClick() { if (clickCount 3) { alert(操作过于频繁请稍后再试); return false; } // 继续提交请求 }这种方案虽然容易被绕过如禁用JS但能拦截80%以上的非正常流量。实测显示加入前端限流后网关层收到的无效请求减少62%。2.2 动态令牌分发机制在网关层我们设计了基于用户特征的动态令牌算法。不同于固定速率的令牌桶该算法会结合用户历史行为动态调整发放频率// 根据用户权重计算令牌间隔 public long calculateInterval(User user) { double weight 0.3 * user.getCreditScore() 0.7 * (1 - user.getRecentRequestFrequency()); return (long)(BASE_INTERVAL * (1 Math.exp(-weight))); }其中信用分高的活跃用户会获得更快的令牌发放速率。通过这种有差别的限流策略在总QPS不变的情况下优质用户的成交率提升了35%。3. 分布式锁的精细化控制3.1 分段锁实践针对热门商品我们采用库存分片策略。将2000件库存拆分为20个分片每个分片100件每个分片对应独立的Redis键item_123_stock_shard_1: 100 item_123_stock_shard_2: 100 ... item_123_stock_shard_20: 100扣减库存时先对用户ID取模确定分片再对该分片加锁。这种设计使得锁粒度从商品级细化到分片级实测并发能力提升约17倍。核心代码逻辑public boolean deductStock(Long itemId, Long userId) { int shardNo (int)(userId % SHARD_COUNT); String lockKey item_ itemId _lock_shard_ shardNo; try { // 使用Redisson的可重入锁 RLock lock redisson.getLock(lockKey); if (lock.tryLock(50, 1000, TimeUnit.MILLISECONDS)) { // 扣减分片库存 Long remain redisTemplate.opsForValue() .decrement(item_ itemId _stock_shard_ shardNo); return remain ! null remain 0; } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return false; }3.2 锁竞争优化技巧在Redisson锁的使用中我们总结出几个关键参数调优点锁等待时间不宜设置过长通常建议50-100ms。某次压测显示当等待时间从500ms降至80ms系统吞吐量提升210%但超时率仅增加5%。锁自动释放时间必须大于业务操作最长时间。曾因设置为3秒而MySQL写入耗时5秒导致锁提前释放引发超卖。现在通过动态计算设置long estimatedTime avgSQLTime * 2 redisRT; lock.lock(estimatedTime, TimeUnit.MILLISECONDS);锁重试策略采用指数退避算法最大重试次数控制在3次以内。示例int retries 0; while (retries MAX_RETRY) { if (tryLock()) return true; Thread.sleep(100 * (1 retries)); // 指数等待 }4. 库存预扣减与最终一致性4.1 异步日志持久化为解决Redis与MySQL的数据一致性问题我们设计了三阶段库存管理预扣减阶段在Redis中快速完成库存检查-- KEYS[1]:库存key ARGV[1]:扣减数量 local stock tonumber(redis.call(GET, KEYS[1])) if stock tonumber(ARGV[1]) then return redis.call(DECRBY, KEYS[1], ARGV[1]) else return -1 end日志记录阶段将订单信息写入KafkakafkaTemplate.send(order-events, new OrderEvent(orderId, userId, itemId, amount));最终落库阶段消费者从Kafka读取消息写入MySQLUPDATE items SET stock stock - ? WHERE id ? AND stock ?这种设计使得库存扣减的RT从平均58ms降至12ms。关键是要处理消费失败的情况我们采用本地消息表定时任务进行补偿。4.2 热点Key的缓存策略对于商品详情这类读多写少的数据采用多级缓存方案本地缓存使用Caffeine设置10%的随机过期时间避免集中失效Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(5 ThreadLocalRandom.current().nextInt(3), TimeUnit.SECONDS) .build();Redis缓存通过Lua脚本实现原子化的缓存更新-- 更新缓存并设置过期时间 redis.call(SET, KEYS[1], ARGV[1]) redis.call(EXPIRE, KEYS[1], ARGV[2])缓存击穿防护使用Redisson的分布式锁保证只有一个线程回源数据库RLock lock redisson.getLock(item_lock_ itemId); if (lock.tryLock()) { try { Item item loadFromDB(itemId); updateCache(item); } finally { lock.unlock(); } }5. 全链路压测与熔断策略5.1 影子库压测方案为真实模拟大促场景我们搭建了与生产环境1:1的压测环境关键点包括流量录制使用Tcpdump捕获线上流量过滤出秒杀相关请求tcpdump -i eth0 -w traffic.pcap port 8080 and host api.taobao.com数据隔离通过中间件路由将压测流量导向影子库Around(annotation(loadTest)) public Object route(ProceedingJoinPoint pjp) { if (isLoadTest()) { DynamicDataSource.set(shadow_db); } return pjp.proceed(); }指标监控使用PrometheusGrafana监控关键指标# Prometheus配置示例 - job_name: spring metrics_path: /actuator/prometheus static_configs: - targets: [app:8080]5.2 自适应熔断机制基于Sentinel实现的动态熔断规则包含三个关键维度慢调用比例当RT500ms的请求占比超过40%触发熔断Rule rule new DegradeRule(deductStock) .setGrade(RuleConstant.DEGRADE_GRADE_RT) .setCount(500) .setTimeWindow(10) .setSlowRatioThreshold(0.4);异常比例当错误率超过50%持续5秒熔断30秒Rule rule new DegradeRule(createOrder) .setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO) .setCount(0.5) .setTimeWindow(30);系统负载保护当CPU使用率80%持续1分钟拒绝50%流量SystemRule systemRule new SystemRule() .setHighestSystemLoad(8.0) .setQps(1000) .setAvgRt(100);在实际运行中这套机制成功在2023年618大促期间拦截了3次潜在的系统崩溃。一个典型的熔断日志如下2023-06-18 02:15:23 [Sentinel] WARN DegradeRuleManager - [DegradeRule] Circuit breaking for deductStock occurs, ratio0.52, currentThreshold0.56. 实战中的经验教训在多次大促中我们积累了一些教科书上不会写的经验Redis连接池的隐藏陷阱某次压测发现TPS突然下降最终定位是Jedis连接池的maxWaitMillis设置过大默认-1无限等待当Redis变慢时大量线程阻塞在获取连接阶段。解决方案JedisPoolConfig config new JedisPoolConfig(); config.setMaxWaitMillis(200); // 设置为200msLua脚本的序列化开销原本使用JSON序列化参数后发现直接传递原始字符串性能提升40%。优化前后对比// 优化前 String script return {KEYS[1],ARGV[1]}; Object result jedis.eval(script, Collections.singletonList(key1), Collections.singletonList(value1)); // 优化后 byte[] script return {KEYS[1],ARGV[1]}.getBytes(); Object result jedis.eval(script, 1, key1.getBytes(), value1.getBytes());GC导致的锁失效曾出现Redisson锁在FullGC期间因心跳停止而意外释放后调整为Config config new Config(); config.setLockWatchdogTimeout(30_000); // 默认30秒 // 同时添加JVM参数 // -XX:UseG1GC -XX:MaxGCPauseMillis200时间同步问题分布式环境下曾因NTP服务异常导致各节点时间不同步影响Redis过期时间的准确性。现在所有服务器强制使用阿里云NTP服务ntpdate ntp.aliyun.com这些细节优化看似微小但在百万QPS的场景下每个环节节省1毫秒整体性能就能提升10%以上。