1. 百万级QPS抢券系统的核心挑战抢券系统本质上是一个特殊的秒杀场景但与普通秒杀相比存在三个显著差异点首先是券的库存通常比实物商品更轻量化这意味着系统可以承受更高的并发压力其次是券的发放往往伴随着复杂的业务规则如每人限领、叠加规则等最后是券的使用存在时间窗口这要求系统在发放时就要考虑后续核销的链路一致性。在百万QPS的压力下系统会面临几个典型瓶颈数据库连接池耗尽、缓存雪崩、库存超卖以及分布式锁争用。我曾参与设计的一个电商平台抢券系统在未优化前MySQL集群的CPU利用率在峰值时直接冲到98%导致整个交易链路瘫痪。后来通过以下架构改造最终稳定支撑了120万QPS的流量洪峰。2. 分层抗压架构设计2.1 接入层优化接入层是流量洪峰的第一道防线。我们采用NginxOpenResty的方案通过Lua脚本实现以下关键功能流量染色给不同渠道的请求打上标签便于后续限流策略的差异化执行。例如APP端请求优先级高于H5端location /coupon { access_by_lua if ngx.var.http_user_agent ~ nil then if string.find(ngx.var.http_user_agent, APP) then ngx.req.set_header(X-Source-Type, HIGH_PRIORITY) end end ; }动态限流基于令牌桶算法实现多维度限流。这里有个关键技巧是采用Redis的CL.THROTTLE命令而非自己实现算法redis-cli --eval throttle.lua $ip $burst_rate $rate , $expire_time踩坑提醒Nginx的limit_req模块在极端高并发下会导致worker进程阻塞我们实测改用LuaRedis方案后单节点限流性能提升17倍。2.2 服务层设计服务层采用漏斗型架构逐层过滤无效请求请求预处理参数校验券ID有效性、用户资质等内存布隆过滤器拦截无效请求误判率设为0.1%时可减少98%的Redis查询本地缓存热点数据如券基本信息分布式锁优化 传统Redis锁在百万QPS下会产生严重争用。我们的解决方案是// 分段锁本地锁结合 public boolean tryLock(String couponId, Long userId) { int segment userId.hashCode() % 32; // 32个分段 synchronized(segmentLocks[segment]) { String lockKey lock: couponId : segment; return redisTemplate.opsForValue().setIfAbsent(lockKey, 1, 10, TimeUnit.SECONDS); } }库存扣减方案 采用RedisLua保证原子性关键是要处理库存回滚-- 扣减库存脚本 local stock tonumber(redis.call(GET, KEYS[1])) if stock 0 then return 0 end redis.call(DECR, KEYS[1]) redis.call(HSET, KEYS[2], ARGV[1], ARGV[2]) -- 记录领取明细 return 12.3 数据层设计缓存策略采用多级缓存架构本地缓存Caffeine - 分布式缓存Redis Cluster - 持久层MySQL热点Key检测通过Redis的MONITOR命令分析热点Key对检测到的热点进行本地缓存预热数据库优化垂直分库用户库、券库、订单库分离水平分表按券ID哈希分16个表异步落库通过BinlogMQ实现最终一致性3. 库存一致性保障方案3.1 预扣库存模式采用预占-确认-释放的三阶段模式先在Redis中预扣减创建预占记录到MQ消费者异步更新数据库// 库存服务核心逻辑 public Result grabCoupon(Long couponId, Long userId) { // 1. Redis预扣减 Long remain redisTemplate.execute(STOCK_DEDUCTION_SCRIPT, Arrays.asList(stock: couponId, record: couponId), userId.toString(), System.currentTimeMillis()); if (remain 0) { return Result.fail(库存不足); } // 2. 发送预占MQ mqProducer.send(new PreOccupyMessage(couponId, userId)); // 3. 返回预占成功 return Result.success(preOccupyId); }3.2 异常处理机制我们设计了库存对账系统每小时执行以下流程比对Redis库存与DB库存差异扫描预占超时30分钟的记录自动触发库存回补经验之谈对账时一定要加分布式锁我们曾因没加锁导致重复回补一夜之间多发了200万张券。4. 性能压测实战数据4.1 压测环境配置服务器8C16G * 20台K8s集群中间件Redis Cluster16分片、RocketMQ8节点数据库MySQL 8.01主3从4.2 优化前后对比指标优化前优化后最大QPS12万152万平均延迟820ms38msDB CPU峰值98%23%超卖发生率0.3%04.3 关键参数调优Redis连接池spring.redis.lettuce.pool: max-active: 500 # 原默认8 max-idle: 100 min-idle: 20Tomcat参数server.tomcat.max-threads800 server.tomcat.accept-count1000JVM调优-XX:UseG1GC -Xms4g -Xmx4g -XX:MaxGCPauseMillis2005. 容灾与降级方案5.1 多级熔断策略硬件层在SLB配置每秒请求数阈值服务层Sentinel配置异常比例熔断功能层开关控制非核心功能降级// 降级开关示例 GetMapping(/coupon/list) public Result listCoupons() { if (degradeSwitch.get()) { return Result.success(cacheService.getBasicCouponInfo()); } return couponService.queryDetailList(); }5.2 热点隔离方案物理隔离独立部署抢券服务集群数据隔离单独Redis集群处理库存链路隔离独立线程池处理核心流程我们通过Arthas监控发现在流量峰值时非核心的日志打印占用了15%的CPU资源后来改为异步日志后性能提升显著。6. 监控体系搭建6.1 核心监控指标系统层服务器Load值GC次数与耗时网络带宽使用率应用层接口TP99线程池活跃度缓存命中率业务层库存偏差率抢券成功率用户重复领取率6.2 全链路追踪通过SkyWalking实现Trace(operationName coupon/grab) public void grabCoupon() { ActiveSpan.tag(user_id, getUserId()); // 业务逻辑... }在实战中发现将Trace采样率设置为100%会导致性能下降40%最终调整为动态采样日常1%大促10%异常时100%这套系统经过618大促实战检验在130万QPS压力下保持稳定期间Redis集群峰值QPS达到210万平均延迟控制在50ms以内。最关键的经验是高并发系统不是设计出来的而是压测出来的。我们前后进行了37次全链路压测每次都能发现新的性能瓶颈。