完整的电商秒杀链路

一个企业级电商秒杀场景，面试官真正想听的不是“用户点击抢购”，而是：

如何解决超卖、高并发、库存一致性、削峰填谷、订单最终一致性。

下面按照互联网公司常见方案讲一遍完整链路。

一、业务架构

用户 ↓ Nginx ↓ Gateway ↓ 秒杀服务 ↓ Redis ↓ RocketMQ/Kafka ↓ 订单服务 ↓ 库存服务 ↓ MySQL

二、秒杀开始前（预热阶段）

秒杀前几分钟通常会进行预热。

1. 商品信息加载到Redis

数据库：

商品ID:1001 库存:10000

预热：

seckill:stock:1001 = 10000

存入Redis。

这样秒杀时不会直接查数据库。

2. 本地缓存预热

例如：

ConcurrentHashMap<Long, Boolean>

保存：

1001 -> true

表示：

还有库存

当库存卖完：

1001 -> false

后续请求直接拒绝。

避免继续访问Redis。

3. 用户资格校验

例如：

会员等级 黑名单 限购次数

提前准备。

三、秒杀开始（核心链路）

假设：

库存：10000 用户：100万人

第一步：请求进入Gateway

用户 ↓ Gateway

Gateway负责：

限流

例如：

100万请求 ↓ 限流 ↓ 每秒1万

防止系统被打爆。

常见：

• Sentinel
• Gateway限流

第二步：秒杀资格判断

判断：

是否登录 是否实名 是否限购 是否重复购买

例如：

SETNX

user:1001:product:2001

存在说明抢过了。

直接返回：

请勿重复抢购

第三步：Redis预扣库存

核心操作：

DECR seckill:stock:1001

Redis：

10000 9999 9998 ...

如果：

库存 < 0

说明抢光了。

立即：

库存不足

结束。

为什么不用数据库扣减？

如果直接：

update stock set count=count-1

100万人同时执行：

数据库直接崩掉

所以必须Redis承担流量。

四、削峰填谷（MQ）

扣减Redis成功后：

不要立即创建订单。

而是发送MQ。

秒杀服务 ↓ RocketMQ

消息内容：

{ "userId":1001, "productId":2001 }

这样：

100万请求 ↓ Redis ↓ MQ ↓ 慢慢消费

数据库压力大幅下降。

五、订单服务消费MQ

消费者收到消息：

订单消费者 ↓ 创建订单

生成订单：

insert into order(...)

订单状态：

WAIT_PAY

待支付。

六、库存服务扣减数据库库存

订单创建成功后：

调用库存服务。

update stock set count=count-1 where product_id=1001 and count>0;

这里是最终库存落库。

Redis库存只是临时库存。

数据库库存才是真实库存。

七、支付环节

用户支付：

支付宝 微信

回调：

支付服务 ↓ 订单服务

订单状态：

WAIT_PAY ↓ PAID

八、超时未支付

例如：

30分钟未支付

发送延迟消息：

RocketMQ Delay

消费者处理：

关闭订单 恢复库存

恢复：

Redis：

INCR stock

数据库：

update stock set count=count+1

九、防止超卖（重点）

面试必问。

方案1：Redis原子扣减

DECR

天然原子。

方案2：数据库乐观锁

update stock set count=count-1 where id=? and count>0

方案3：版本号

version=version+1

CAS思想。

十、防止重复下单

Redis：

userId_productId

例如：

SETNX

order:1001:2001

成功：

第一次购买

失败：

重复购买

十一、库存一致性问题

面试高频。

例如：

Redis扣减成功 MQ发送失败

怎么办？

解决：

事务消息

例如：

• Apache RocketMQ 事务消息

流程：

Redis扣库存 ↓ 半消息 ↓ 本地事务 ↓ 提交消息

保证最终一致。

十二、企业级完整链路

用户点击秒杀 ↓ Gateway限流 ↓ 登录校验 ↓ 资格校验 ↓ Redis判断库存 ↓ Redis预扣库存 ↓ SETNX防重复购买 ↓ 发送MQ ↓ 订单服务消费 ↓ 创建订单 ↓ 库存服务落库 ↓ 返回抢购成功 ↓ 用户支付 ↓ 修改订单状态 ↓ 发货

面试版 1 分钟总结

秒杀系统核心目标是解决高并发和超卖问题。秒杀开始前会将库存预热到 Redis。用户请求经过 Gateway 限流后，先进行资格校验和重复下单校验，然后通过 Redis 原子扣减库存实现快速响应。扣减成功后不直接操作数据库，而是发送 MQ 进行削峰填谷。订单服务异步消费消息创建订单，库存服务完成数据库库存扣减。支付成功后修改订单状态，超时未支付通过延迟消息关闭订单并回补库存。整个过程中利用 Redis、MQ、乐观锁、幂等控制和最终一致性机制保证系统稳定运行并避免超卖。