一个秒杀就把 MySQL 打挂了？我用 Redis + 异步削峰扛住了 100 倍流量

一个秒杀就把 MySQL 打挂了？我用 Redis + 异步削峰扛住了 100 倍流量

📌 前言

“服务器竟然挂了？”——下午 14:00，秒杀准时开启，你盯着监控面板，QPS 瞬间飙到 3 万，数据库连接池爆满，慢查询堆积成山，Tomcat 线程全部阻塞。用户端疯狂重试，nginx 日志全是 502，页面白屏转圈一分钟后弹出"网络异常"。

产品经理冲过来问：还能不能恢复？

你盯着数据库连接数的折线图——已经是一条垂直线了。MySQL CPU 100%，磁盘 IO 打满，慢查询队列里排着上万个UPDATE stock正在死锁回滚。

这不是虚构的生产事故。我经历过。而且不止一次。

本文会把那次完整的技术选型、排查过程、优化方案、底层原理全部拆开讲清楚。如果你团队下一个版本也要上秒杀，这可能是你今天读到最值的一篇文章。

📋 环境说明

🔍 问题复现

先看优化前的架构。简单到令人放心：用户请求经过 nginx 负载均衡到 Tomcat，Tomcat 直接操作 MySQL 集群。看起来没什么问题对吧？

这套流程在低并发时表现完美。但在秒杀场景下，暴露了三个致命问题：

问题 1：MySQL 行锁变表锁噩梦

库存表的核心 SQL 长这样：

UPDATEseckill_stockSETcount=count-1WHEREgoods_id=?ANDcount>0;-- <-- 同一商品所有用户竞争同一行锁

秒杀开始瞬间，上万请求涌入。MySQL行锁排队，事务等待时间飙升到秒级，大量请求超时回滚后立刻重试——形成死锁风暴 + 雪崩。

问题 2：一人一单校验反复查库

// 优化前的校验逻辑Orderorder=orderMapper.selectByUserIdAndGoodsId(userId,goodsId);// <-- 每次查MySQLif(order!=null){thrownewBusinessException("每人限购一件");}

假设 3 万 QPS，一人一单这一步就产生 3 万次 MySQL 查询。对于秒杀这种写多读更多的场景，MySQL 的 IO 根本扛不住。

问题 3：Tomcat 线程池耗尽

Tomcat 默认线程池 200。200 个线程全部阻塞在数据库连接获取上——等待排队、等待锁释放、等待回滚。新请求进不来，HTTP 连接超时后，用户疯狂 F5 重试，把服务器推向更深的雪崩。

压测数据说明一切：

这不是秒杀——这是自毁程序。

🧭 排查过程

尝试 1: 加 MySQL 连接池和索引 ❌

第一反应是"MySQL 太忙了，给它加点资源"。

把连接池从 120 加到 500，给seckill_stock表加了(goods_id, user_id)联合索引，把UPDATE改为只更新乐观锁版本号。

结果：连接多了，行锁竞争更激烈——500 个线程同时争同一行，死锁频次翻倍。TPS 从 200 降到 80。

教训：秒杀的本质矛盾不是 MySQL 连接不够，是同一行记录的写竞争。MySQL 的行锁机制决定了它不适合高并发"热点写"。

尝试 2: 前端限流 + 按钮置灰 ❌

前端倒计时结束后按钮置灰 3 秒，后端 nginxlimit_req限制单 IP 1r/s。

结果：阻止不了专业黄牛（他们发包不经过前端）、阻止不了海量并发（IP 分布极广）。真正用户也被限流挡在外面——误杀率 40%。

教训：前端限流只能做辅助，不能依赖。秒杀的核心矛盾不在入口，在数据库层。

尝试 3: 引入 Redis 预减库存 + 异步下单 ✅

第二次大促前花了两周重构了秒杀链路。核心思路只有一句话：

把秒杀的"资格校验"和"正式下单"解耦。

让 Redis 扛住瞬时流量做资格判断，把真正写入 MySQL 的操作放到队列里异步执行。

变更后重新压测：

🛠️ 解决方案（详细实现）

核心一：Redis LUA 脚本做资格校验

为什么用 LUA 脚本？因为 Redis 的 LUA 脚本原子执行，在整个脚本运行期间不会被其他命令打断。

-- check_and_dec.lua-- KEYS[1]: 商品库存 key-- KEYS[2]: 用户已购 set key-- ARGV[1]: 用户 ID-- ARGV[2]: 商品 ID-- 1. 检查库存localstock=tonumber(redis.call('GET',KEYS[1]))ifnotstockorstock<=0thenreturn-1-- 库存不足end-- 2. 检查一人一单localisBought=redis.call('SISMEMBER',KEYS[2],ARGV[1])ifisBought==1thenreturn-2-- 已购买过end-- 3. 预减库存 + 记录用户redis.call('DECR',KEYS[1])redis.call('SADD',KEYS[2],ARGV[1])-- 4. 生成唯一订单号localorderId=redis.call('INCR','order:id:gen')returnorderId

调用这段 LUA 脚本，整个秒杀资格校验在一次网络 IO + 几微秒内完成，彻底绕过了 MySQL。

核心二：线程池 + 阻塞队列异步落库

@ComponentpublicclassSeckillAsyncProcessor{privatefinalExecutorServiceexecutor=newThreadPoolExecutor(1,// corePoolSize1,// maxPoolSize0L,TimeUnit.SECONDS,newLinkedBlockingQueue<>(10000),// <-- 阻塞队列做缓冲区newThreadPoolExecutor.CallerRunsPolicy());@PostConstructpublicvoidstartConsumer(){executor.submit(()->{while(true){try{SeckillMessagemsg=queue.take();// <-- 阻塞获取processOrder(msg);}catch(Exceptione){log.error("异步下单失败",e);}}});}publicbooleanaddTask(SeckillMessagemsg){returnqueue.offer(msg,100,TimeUnit.MILLISECONDS);// <-- 超时保护}}

关键设计点：

• 单线程消费避免数据库写冲突，天然解决行锁问题
• LinkedBlockingQueue作为缓冲区，削峰填谷
• offer()带超时，队列满时快速失败，不让上游阻塞
• 秒杀场景要用快速拒绝策略，然后让用户重试

核心三：nginx 层面做网关限流

limit_req_zone $binary_remote_addr zone=seckill:10m rate=100r/s; location /seckill/ { limit_req zone=seckill burst=50 nodelay; proxy_pass http://backend_servers; limit_req_status 429; error_page 429 /seckill_busy.html; }

nginx 限流放在最外层，挡住 90% 的无效流量，让 Redis 只处理真正有资格进来的请求。

踩坑记录（README 没有告诉你的）

1. Redis DECR 可能变成负数——LUA 脚本里必须先 GET 判断库存 > 0 再 DECR，不要直接 DECR 后判断。
2. 阻塞队列不能无限大——上限设为 10000，超过直接拒绝。否则内存被打满，OOM 了连日志都写不出去。
3. 异步线程要单独处理失败重试——如果数据库写入失败，不能简单重试。设计一张状态表记录异步订单的处理状态，用定时任务补偿。

🧠 原理分析

为什么 Redis 比 MySQL 快这么多？

当我说"Redis 能在几微秒内完成资格校验"，你不是应该只记住这个结论，而是要理解为什么。

根本原因：MySQL 为了 ACID，每一行数据写入都要经过Buffer Pool → Redo Log → Binlog → 脏页刷盘，同一行的 UPDATE 还会产生行锁排队。而 Redis 纯粹在内存操作，LUA 脚本保证原子性，单线程模型天然避免了并发写冲突。

秒杀场景下，Redis 做资格校验是降维打击。

为什么要用异步削峰？

优化前，3 万请求同时打到 MySQL，每个请求都需要完整的数据库写操作——这是同心圆式压力放大。

优化后，99% 的请求在 Redis 层就被快速拒绝了（“库存不足"或"已购买”），只有真正抢到的请求进入队列。队列作为缓冲区，让 MySQL 的写入速率变成可控的每秒几百笔——这才是数据库能优雅处理的速度。

LUA 原子性的边界在哪？

一个很多人问的问题：如果 Redis 执行 LUA 脚本的瞬间宕机了怎么办？

场景：Redis 已经执行了 DECR stock 和 SADD user_set，但还没把订单号返回给客户端就宕机了。

解决方案：订单号不要依赖 Redis 返回。让 Redis 只判断"有资格/没资格"，返回布尔值。真正的订单号用雪花算法在应用层生成，并配套一个任务状态表：

CREATETABLE`seckill_task`(`id`BIGINTPRIMARYKEY,`user_id`BIGINTNOTNULL,`goods_id`BIGINTNOTNULL,`status`TINYINTDEFAULT0COMMENT'0-待处理 1-成功 2-失败',`create_time`DATETIMEDEFAULTCURRENT_TIMESTAMP,INDEX`idx_status`(`status`));

异步线程处理完后更新状态。定时任务每 5 秒扫描 status=0 的记录，超过 30 秒未处理的做补偿处理。这叫最终一致——秒杀场景下，你不需要强一致性，但必须保证数据不丢。

📝 总结

1. 不要把 MySQL 当秒杀引擎。MySQL 的行锁和磁盘 IO 决定了它不适合做"热点写"，让它做最终落库就够了。
2. Redis + LUA 原子脚本做资格校验，把 3 万 QPS 降维到几百 TPS 的 DB 写入，延迟从 8 秒降到 12 毫秒。
3. **异步削峰（阻塞队列 + 单线程消费者）**让数据库写入速率变得可控，完全避免死锁和雪崩。
4. 最终一致性 > 强一致性。秒杀不是银行转账，短暂的缓存和数据库不一致可以接受，但数据绝对不能丢。

延伸思考

如果你的秒杀规模更大（比如双十一百亿级），上面这套方案还需要补充什么？

• Redis 单机不够 →Redis Cluster + 本地标记缓存
• 阻塞队列内存不够 →Kafka/RocketMQ 替代内存队列
• 数据库还不够 →分库分表 + 读写分离

技术选型的核心就一句话：让合适的组件干合适的活。

📚 参考资料

• Redis Lua 脚本官方文档
• Spring Boot 异步任务配置
• MySQL 行锁与死锁分析
• 秒杀系统设计 · 美团技术博客
• nginx ngx_http_limit_req_module

本文为原创内容，转载请注明出处。

如果这篇文章对你有帮助，欢迎点赞 👍、收藏 ⭐、关注 ➕，你的支持是我持续输出的动力！