秒杀系统异步下单全链路设计：Redis预扣与MQ削峰实战

1. 项目概述：为什么秒杀系统必须走异步下单

做过电商业务的开发者，十有八九都遇到过秒杀场景。商品数量有限、瞬间涌入大量用户、并发请求动辄上万，这时候如果还按照普通的“同步下单、同步扣库存、同步返回结果”链路去做，系统会在第一波流量冲击下直接被打垮。我接手过某商城的模拟秒杀项目（为避免敏感信息，这里用模拟项目X代称），一开始用同步方案压测，QPS到500左右数据库连接池就爆了，订单接口响应时间从几十毫秒飙升到几十秒，大量请求超时重试，库存数据错乱。后来把下单链路全面改造成异步化，压测结果才恢复正常。

所谓异步下单，核心思路就一句话：让用户请求先进入一个稳定可靠的缓冲通道，后台再从容地逐步处理，最终把结果推给用户。它解决的问题不是“能不能扛住高并发”这一个点，而是同时解决了三件事：削峰填谷保护下游存储、提升接口响应速度、保证最终库存扣减的正确性。

我梳理这份业务逻辑，是想把秒杀异步下单这条链路上的每个环节拆开讲清楚，包括用户发起请求后到底发生了什么、库存在哪里被真正扣掉、消息队列怎么选、消费者端怎么保证幂等、以及失败订单如何补偿。适合正在搭建秒杀系统的开发者、准备做高并发场景面试复盘的同学，以及想做技术方案评审但还没系统梳理过全链路的人看。

2. 整体链路设计与核心思路拆解

2.1 同步下单为什么扛不住

先看传统同步下单长什么样。用户点击“立即秒杀”，浏览器发一个POST请求到订单服务，订单服务要做的动作包括：校验用户登录态、校验秒杀资格、查询商品信息、检查库存是否足够、扣减库存、生成订单号、落订单表、可能还要调用营销服务发放优惠券、最后返回“下单成功”。整个请求期间，数据库连接一直被占用，任何一步慢一点，整个请求就变慢。

秒杀流量的特点是指数级瞬发，不是缓慢爬坡。某秒杀活动刚上线的前10秒，请求量可能占到全天的70%以上。这种流量模型下，同步链路有两个致命问题：

• 串行瓶颈堆积：一个请求从进入系统到返回结果，前后要经过4到8次数据库操作。DB的连接数是有限的，假设连接池配置是50，每个连接处理一个请求需要300毫秒，那这个服务理论上每秒最多处理约160个请求。可秒杀瞬时涌入的是每秒几万个请求，多出来的全部排队、超时、重试，然后重试又加剧拥堵，雪崩就是这么来的。
• 故障放大效应：同步链路里只要有一个环节抖动（比如商品服务响应慢了200毫秒），所有请求都会被拖住，用户感知就是“页面卡死”“一直转圈”。

异步下单的思路恰恰是规避这两点：把耗时的核心业务处理从用户请求线程中剥离出去。用户请求进来只做两件最轻的事：校验资格、写入一个待处理标记，然后立刻返回“已收到请求”。真正的订单创建、库存扣减、支付引导，统统放到后台异步执行。

2.2 异步下单的完整链路骨架

我梳理的异步下单链路分成四段：

用户端发起请求 → 接入层（限流+风控） → 缓冲层（消息队列） → 消费端（异步处理订单） → 结果通知

• 接入层：负责接口幂等校验、用户资格预检、限流。这一层要把明显无效的流量挡掉，比如重复点击、没有秒杀资格的用户。
• 缓冲层：消息队列承担削峰功能。秒杀瞬时流量再大，写入MQ的速度一般都能扛住，MQ做持久化后，流量就变成可控速率地从队列里被消费。
• 消费端：真正干活的模块。从MQ拉取消息，执行库存预扣、订单落库、状态流转等核心逻辑。
• 结果通知：用户不一定要同步拿到结果，可以通过轮询订单状态、WebSocket推送，或者短信/站内信延迟通知。

这个骨架里有一个关键的设计选择：用户请求在接入层返回的是什么。很多人误以为异步下单就是接口响应变慢，其实恰恰相反，异步下单的接口响应会非常快——因为它返回的不是“下单结果”，而是“受理结果”。比如接口返回“请求已受理，请稍后查看订单状态”，用户端再通过订单查询接口去获取最终状态。

2.3 为什么是把流量先写入消息队列而不是直接写数据库

这是我被问过最多的问题：既然最终要扣库存、订单要落库，为什么中间非要隔一层MQ？直接在接入层用Redis预扣库存，然后再异步写订单不行吗？

答案是：可以，而且实际架构里Redis预扣本来就是必须做的。但MQ承担的角色不是替代Redis做库存控制，而是做数据库写操作的流量整形。Redis虽然吞吐量高，但它不是关系型数据库，订单数据最终还是要落到MySQL这类存储里。如果几千个并发同时往订单表INSERT，即使库存已在Redis层扣好了，数据库的写入能力依然是瓶颈。

把订单创建消息投递到MQ后，消费端可以根据自身能力设置消费速率（比如每秒处理500个订单），这样数据库每秒最多接收500次写入，完全在安全水位内。MQ在这里起到的是**“可变速率器”**的作用，把不可预测的高峰流量，转换成下游存储能够承受的匀速流量。

3. 核心环节详解：从请求接入到库存扣减的设计逻辑

3.1 接入层：用户请求进来后第一步做什么

用户点了“立即秒杀”，到达后端接口，第一步不是直接扣库存，而是做三个轻量级前置校验。

第一个是登录态和资格校验。用户是否登录、是否在黑名单里、是否已经参与过该场次秒杀。这里我会用一个独立的Redis Key来记录“用户已参与”，比如seckill:user:{userId}:{activityId}，值为1则表示已参与。这个Key的过期时间设置为活动结束时间，既防止重复参与，也不会长期占用内存。

第二个是接口幂等校验。秒杀页面用户会疯狂点击按钮，前端一般会做按钮置灰，但防不住多终端同时请求，或者网络异常后自动重试。幂等方案我采用的是UUID令牌：页面加载时向后端申请一个全局唯一的requestToken，提交下单时必须携带，Redis里用SETNX写入这个Token，写入成功说明是第一次请求，反之说明是重复提交，直接拒绝。

第三个是限流。接入层限流有全局限流和用户级限流两种。全局限流用Redis + Lua脚本实现滑动窗口限流，防止整体流量超过系统水位；用户级限流则限制单个用户每秒最大请求次数，比如每秒3次，防止脚本刷接口。

3.2 前置校验通过后：写Redis预扣还是直接发MQ

前置校验通过后，进入核心链路的第一步：库存预扣。这一步是秒杀系统的胜负手，必须保证“扣减准确”和“绝不超卖”。

我采用Redis + Lua脚本来执行预扣。脚本逻辑大致如下：

-- KEYS[1]: 秒杀商品库存Key -- KEYS[2]: 用户参与标记Key -- ARGV[1]: 用户ID -- ARGV[2]: 活动ID if redis.call('exists', KEYS[2]) == 1 then return -1 -- 用户已参与过 end local stock = tonumber(redis.call('get', KEYS[1])) if stock == nil or stock < 1 then return 0 -- 库存不足 end redis.call('decr', KEYS[1]) redis.call('set', KEYS[2], 1, 'EX', ARGV[3]) return 1 -- 预扣成功

这段Lua脚本为什么要用Lua而不是Java/Go代码里先查后减？核心原因只有一个：原子性。单个Lua脚本在Redis中是原子执行的，中间不会被其他客户端的命令插入，所以不存在“A查到库存还剩1个，B也查到还剩1个，然后A扣成0，B又把0扣成-1”的竞态问题。如果用代码里“先GET再DECR”的方式，两个线程同时读到库存为1，各自都执行DECR，最终库存变成-1，这就是典型的超卖场景。

预扣成功之后，商品库存已经在Redis层被占用，但这不代表订单就一定有——因为后续创建订单可能失败。所以预扣只是“预占”，真正的“扣减”要以订单创建成功为准。我遇到不少团队在设计时把Redis预扣等同于库存扣减，后面订单失败时没有释放库存，导致活动结束后还有大量库存没卖出去，系统里却显示“已售罄”。这个坑后面会细说。

3.3 消息投递：订单消息里应该带什么

预扣成功后，把“订单创建消息”投递到MQ。这一步要注意消息体不能过大，也不能只传一个商品ID就完事。我给出的最小消息体建议是：

{ "requestToken": "UUID令牌", "userId": 100123, "commodityId": "SP20240601001", "activityId": "ACT20240601", "seckillPrice": 99.00, "quantity": 1, "stockPayToken": "库存预扣成功后的唯一凭证", "timestamp": 1717200000000 }

特别注意stockPayToken这个字段。它是Redis预扣成功时生成的唯一标识，比如取requestToken本身。消费者处理消息时，只要拿到这个Token，就能确认“库存确实已经被这个请求预占了”，从而避免重复扣减。有些方案里还会把Token对应的状态写入Redis，比如seckill:stockToken:{token}的值是occupied，订单落库成功后改成committed，失败改成released，这相当于给“预扣-确认-释放”做了一个状态机。

3.4 消费者端：如何保证库存最终一致

消费端从MQ拉取到订单创建消息后，工作流程是这样的：

第一步：检查消息幂等。消息队列提供的是at-least-once投递语义，也就是说消息可能被重复投递。我收到消息后，先查requestToken对应的订单是否已存在。可以对订单表的request_token字段建唯一索引，这样即使消息重复消费，第二次INSERT会因唯一键冲突而失败，从数据库层面保证幂等。

第二步：落订单数据。订单状态初始为“待支付”。这里订单编号不能用数据库自增ID，因为自增ID无法在写入前生成，且容易被猜出订单量。我使用的是雪花算法生成全局唯一订单号，在消费者本地生成后随INSERT一起写入。

第三步：确认Redis库存状态。检查stockPayToken对应的状态，如果是occupied，说明一切正常，继续往下走；如果已经是committed，说明这条消息被重复消费了，直接ACK丢弃；如果是released，说明之前有一次订单创建失败了，库存已经释放，这条消息不应该再创建订单，记录日志后ACK。

第四步：执行数据库库存扣减。这里要说明一个很多文章没讲透的点：Redis预扣是“占坑”，数据库扣减才是“真正卖出”。为什么不能只依赖Redis？因为Redis有丢失数据的风险（虽然可以开启AOF持久化），而且订单最终要落库，MySQL里需要维护一个真实的库存数字用于对账。正确的做法是：订单表和库存表在同一个数据库事务里操作，UPDATE stock_table SET sold_count = sold_count + 1 WHERE commodity_id = ? AND sold_count < stock_total，受影响行数为1才说明扣减成功。

这里有一个性能争议：为什么不直接在Redis预扣后就算下单成功，数据库扣减放到异步慢慢做？因为如果数据库扣减失败（比如库存和Redis数据不一致），订单已经建出来了，但实际没货，会给用户发货环节带来大麻烦。我的原则是：订单状态必须由数据库真实库存扣减结果决定。

3.5 结果通知：用户在哪里看到“秒杀成功”

用户请求在接入层已经快速返回，但最终是否成功，用户需要知道结果。这块有三条路径：

• 前端轮询：下单后前端每隔2秒调用一次订单查询接口，返回状态为“待支付”则提示用户去支付，返回“已关单”则提示未中选。实现简单，但2秒一次轮询在10万用户同时在线时也有压力，所以轮询接口会用Redis缓存订单状态，减少DB压力。
• WebSocket推送：服务端订单状态变更后，推送给用户端。体验好但实现复杂度高，秒杀场景下海量连接对网关压力很大。
• 主动查询+延迟补偿：订单状态写入Redis并设置过期时间，用户端轮询接口优先查Redis；超过一定时间Redis没有记录，就查数据库兜底。

实际项目里我常用第三种变体：活动结束后统一做一次“未支付订单批量关单”，同时给用户推送结果。比如活动结束后5分钟，批量关闭所有未支付订单，释放库存给候补用户。这个逻辑和异步下单的“结果通知”是配套的——用户在下单页看到“待支付”后，必须在一个有效期内完成支付，否则视为放弃。

4. 实操过程中的关键参数与配置方案

4.1 数据库表结构设计：订单表这样建才能撑住高并发

订单表是异步下单链路的最终落点，设计上有几个关键点。先看简化版表结构：

CREATE TABLE `seckill_order` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `order_no` varchar(64) NOT NULL COMMENT '业务订单号（雪花算法生成）', `request_token` varchar(64) NOT NULL COMMENT '请求幂等令牌', `user_id` bigint(20) NOT NULL, `commodity_id` bigint(20) NOT NULL, `activity_id` bigint(20) NOT NULL, `pay_amount` decimal(10,2) NOT NULL, `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0待支付 1已支付 2已取消 3已关闭', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `paid_at` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), UNIQUE KEY `uk_request_token` (`request_token`), KEY `idx_user_id` (`user_id`), KEY `idx_commodity_id` (`commodity_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里面有几个容易被忽略的细节：

• request_token建唯一索引，这是业务幂等和消息去重的最强后盾。消息重复消费时，INSERT会因为唯一键冲突直接失败，不用写复杂的判断逻辑。
• order_no是雪花算法生成的业务订单号，不是自增ID。自增ID在秒杀场景里有两个问题：高并发下批量INSERT自增ID会成为热点；而且自增ID暴露了订单量，活动结束后竞品能大概算出你卖出了多少单。
• 订单表本身要分表。单表千万数据后查询性能会明显下降。我建议按user_id做分表键，这样同一个用户的订单都在同一张表里，查询“我的订单”不需要跨表聚合。

4.2 Redis Key设计：一次秒杀活动要用哪些Key

这些Key有一个共性：都要设置过期时间。秒杀活动结束后，这些数据如果长期留在Redis里会浪费大量内存，尤其是“用户已参与”这类Key，如果不清理，下次活动复用同一个Key前缀时会出现“新活动用户无法参与”的诡异Bug。我习惯在活动结束后跑一个清理任务，把所有秒杀相关Key按前缀扫描删除。

4.3 消息队列选型与消费速率配置

异步下单的MQ选型，社区通常在三者之间选：RabbitMQ、Kafka、RocketMQ。

秒杀场景我推荐RocketMQ或Kafka。如果是阿里云环境，RocketMQ有现成的定时消息和事务消息，对“活动结束批量关单”这类延迟任务支持得非常好。自建的话Kafka更常见，但要注意Kafka的消费延迟和分区数量规划：分区数是消费并行度的上限，秒杀峰值如果每秒产生5000条订单消息，单分区消费能力大约是每秒2000条，那就至少需要3个分区才能消费完。

消费端还有一个非常关键但经常被忽略的点：消费速率和数据库写入速率的匹配。比如你的订单表MySQL能承受的峰值写入是每秒1000条，那消费端应该通过限流工具（比如Guava RateLimiter或Sentinel）限制消费速率为每秒800条，留20%的余量。很多系统出问题就出在消费端全速消费，结果把数据库连接池打满，反而比同步链路挂得更快。这个教训我是花了两个通宵才彻底明白的。

4.4 库存扣减策略对比：谁先扣，谁后扣

库存扣减涉及两个存储系统：Redis（预扣）和MySQL（真实扣减），两者扣减的先后顺序会影响最终一致性。我对比过几种方案，只说最典型的两种：

方案A：先Redis预扣，再异步扣MySQL（推荐）

用户请求 → Redis预扣成功 → 发MQ → 返回"已受理" 消费者 → 收到消息 → 事务内：INSERT订单 + UPDATE库存表 → 提交

优点：Redis预扣操作极快（Lua脚本微秒级），用户请求响应快，系统能扛住的瞬时并发最高。缺点：如果MySQL扣减失败，需要一个补偿任务释放Redis预扣的库存。这就是为什么Redis侧要有“预扣状态机”，失败后要能把occupied改成released。

方案B：先扣MySQL，再同步Redis

用户请求直接对MySQL库存行做UPDATE，成功后再写Redis。这种方式库存绝对准确，但因为要等数据库IO，吞吐量受限。秒杀场景下不一定撑得住。

还有一个“只扣Redis不扣MySQL”的极端方案，适合库存数量不大、对账容忍度高的场景，但不适合正规电商，我直接排除。

5. 常见问题与排查实录

5.1 消息重复消费导致订单重复

现象：压测时发现同一用户产生了两条相同商品的订单，而且都显示待支付。

排查过程：我先查订单表里request_token字段是否有唯一索引，结果发现开发环境表结构里漏加了。加上唯一索引后，问题消失大半。但还有一个隐蔽场景：消息重复投递发生在库里订单已经存在之后，消费者重复消费时，除非每次都对request_token做查询判断，否则会直接报唯一键冲突异常。这个异常如果没被捕获，会导致消息一直重试，最终进入死信队列。

解决方式是双保险：消息消费入口先查一次request_token是否已存在订单，存在直接ACK；查不到时再执行INSERT，让唯一索引兜底。

避坑提示：不要在生产环境依赖“先查再插”做幂等，因为并发下两个消费者同时查都是空，会同时插入成功。唯一索引才是真正可靠的幂等防线。

5.2 Redis库存预扣成功但订单落库失败，库存“凭空消失”

现象：活动结束后统计销量，MySQL里确认的销售订单数小于Redis预扣成功数，库存也不见了。

排查过程：这是我说的“预扣库存未释放”问题。消费者的订单创建逻辑里，如果INSERT订单失败（比如数据库事务超时），代码没有捕获异常后调用“释放库存Token”的逻辑，导致Redis里的库存被预扣了，但没有任何订单绑定这个库存，库存就蒸发了。

解决方式：订单落库失败时，消费者要把stockPayToken的状态置为released，并且记录一条释放日志。同时，活动结束后的对账任务里，扫描所有occupied状态但超过活动结束时间还未committed的Token，统一释放库存。

5.3 MQ消息积压，订单状态迟迟不更新

现象：用户已经提交秒杀请求，但等了半天订单状态还是“处理中”。

排查过程：先看MQ的消费速率，发现消费端日志显示处理一条消息耗时从50毫秒涨到了2秒。进一步排查，发现消费端里每处理一条消息都调用了两次用户服务RPC去查用户信息，用户服务此时也有压力，导致RPC超时重试，消费速度直线下降。

解决方式：把用户信息预取到Redis缓存，消费端直接读缓存而不是调用RPC。同时在生产端对消息做聚合，同一条消费线程连续处理多条消息时减少链路中无意义的远程调用。处理完后消费速率恢复到每秒1800条左右，积压消息在10分钟内消化完毕。

• 到这里要说一个很实际的经验：消息积压不是无解的，核心是看你是“长尾积压”还是“流量瞬时限流”。如果是消费者自身逻辑慢，优化消费端比扩容更有效；如果是生产者瞬时发送量超过消费能力且持续很久，才需要扩容分区或增加消费者实例。

5.4 数据库主从延迟导致用户查不到订单

现象：用户提交秒杀后，立即轮询订单接口，提示“未找到订单”。明明Redis里显示库存已经扣了。

排查过程：订单接口走的是MySQL从库，而消费端写入的是主库。秒杀场景下主库刚INSERT完一条订单，从库同步存在延迟（正常时1秒内，但高峰时可能到3秒），用户这3秒内查询从库自然查不到。

解决方式：订单写入后立即把“订单已生成”标记写入Redis，轮询接口优先查Redis。Redis里有这个标记，就返回“正在处理中”而不是“未找到订单”，让用户继续等待或者去支付。同时轮询接口如果Redis里没有标记，需要去主库兜底查一次，避免从库延迟导致误判。

5.5 消费者重复消费且消费速度被拖垮的排查工具

给一个排查抗高并发链路问题的常用命令集合：

# 查看消费组堆积情况 kafka-consumer-groups.sh --bootstrap-server xxx:9092 --describe --group seckill-order-group # 查看Redis当前瞬时请求量 redis-cli --stat # 压测时查看MySQL当前连接数和慢查询 mysql -h xxx -e "show processlist;" mysql -h xxx -e "show global status like 'Slow_queries';"

有一次我压测时发现MySQL的Threads_connected从正常30飙升到800，用show processlist看出大量INSERT订单语句处于Waiting for table metadata lock状态，定位到一个消费端实例里有个长时间未提交的事务占用了表锁。杀掉那个线程后连接数恢复正常。

6. 我踩坑后的几点实操心得

做秒杀异步下单这个模块，前后改了四版设计，最大的心得是：异步化只是手段，一致性才是目的。很多人把异步下单简单理解为“用MQ把流量缓冲掉”，但真正难的是缓冲之后，怎么让Redis、MQ、MySQL三个系统之间的状态保持一致。

我整理几条直接能用上的经验：

第一，Redis预扣的“状态机”一定要设计清楚。occupied（已占用）、committed（已确认）、released（已释放）三个状态缺一不可。每个状态变更都要有对应的日志，否则出问题的时候你根本不知道库存去了哪里。

第二，消费者的幂等判断不能只靠代码逻辑。Redis或数据库的唯一约束至少要有一样，双保险更稳。我在生产环境见过太多“代码里判断了，但因为并发时机不对还是重复插入”的案例。

第三，消息体不要带大字段。比如不下放用户的收货地址、商品详情等信息到消息里，消费者需要时再查。消息体越小，MQ的吞吐越高，序列化开销越小，积压风险越低。

第四，库存扣减必须用UPDATE语句的条件判断，不能用“先查后改”。UPDATE stock SET sold_count = sold_count + 1 WHERE id = ? AND sold_count < total这一步是数据库层的最后防线。

第五，压测不能只测单环节。我见过团队把Redis预扣压测到每秒5万，觉得很满意，结果MySQL订单写入每秒只能处理500，瞬间积压。全链路压测时要把生产端、MQ、消费端、DB、限流策略全部打通，观察瓶颈出现在哪一层。

秒杀异步下单这个业务逻辑，看起来只是一个“请求进MQ再消费”的简单流程，真正落地时涉及分布式事务、幂等设计、消息可靠性、数据库性能优化等多个领域的知识。如果你正在做类似的系统，建议把职责边界画清楚：接入层只负责挡流量、MQ只负责削峰、消费端只负责保证“要么都成功要么都失败”的状态一致。边界清晰了，问题就好定位得多。