秒杀系统架构设计与实践：从微服务拆分到Redis防超卖与MQ削峰

1. 秒杀系统到底难在哪：业务场景与技术挑战

接手这个需求的时候，产品经理给的描述很简单："首页挂一个秒杀专场，每天10点、20点开两场，每场放三到五个SKU，每个SKU库存50到200件不等，限时十分钟。"听起来不多？但电商业务的诡异之处就在这——平时日活几万的系统，一到秒杀场次，瞬时流量能干到平时的几十倍。

我负责的系统原本是单体应用，订单、库存、用户、商品全部揉在一个Spring Boot工程里，MySQL单库单表硬扛。平时凑合够用，但秒杀这种场景根本顶不住。热词里有人问"Spring Boot微服务架构图"，我当时面对的问题恰恰就是：单体怎么拆、按什么维度拆、拆完之后原本一次本地事务调用变成多次RPC调用怎么保证数据一致。

秒杀系统的难度不在业务逻辑本身——它本质上就三个操作：验证资格、扣库存、生成订单。难的是这三个操作发生在同一瞬间，成千上万个请求同时打过来。这不是"能不能写出来"的问题，而是"扛不扛得住、卖完会不会超卖、用户会不会重复下单"的问题。整个项目做下来，我的核心体会是：秒杀系统的架构设计，本质上是把"瞬时高并发"转化为"可控的异步流量"的过程。

这套设计适合谁参考？如果你是中小团队的后端开发，你们的产品也打算上秒杀、抢购、限量活动这类玩法，这篇文章可以帮你少走很多弯路。我下面讲的不是教科书里的标准答案，而是我在真实业务里踩过坑之后沉淀下来的一套可行方案。

2. 微服务拆分：为什么必须拆出独立的秒杀链路

2.1 单体架构在秒杀场景下首先崩掉的是哪里

先复盘一下最初的单体架构在压测中是怎么挂掉的。2000个并发线程打过来，第一个扛不住的不是数据库，而是Tomcat的线程池。默认配置下Spring Boot内嵌Tomcat最大线程数是200，意味着同一时刻只能处理200个请求，剩下的全部排队。而秒杀接口里既有库存查询又有订单写入，平均响应时间被拖到3秒以上，队列越积越长，最后雪崩。

第二个瓶颈是数据库连接池。HikariCP默认最大连接数是10，2000个请求同时进来，全部在等连接释放，数据库端一堆Waiting for connection。第三个问题是应用层的内存和GC，订单、库存、用户三张表的大查询把老年代撑爆，Full GC频繁触发，整个应用进入假死状态。

所以第一步不是优化代码，而是拆分。但拆分不是把原来的单体按controller、service、dao拆成三个工程，那是物理拆分，不是架构拆分。合理的做法是按业务域拆，把秒杀相关的逻辑从主链路中隔离出去。

2.2 电商秒杀的域划分与工程落地

我的拆分方案是这样：

• 用户服务：负责登录态校验、用户等级与风控标签查询，独立部署，承接所有业务共用的用户能力。
• 商品服务：维护商品基本信息、秒杀场次配置、秒杀价格，独立部署，提供商品详情查询接口。
• 库存服务：这是秒杀链路的专用服务，维护SKU库存、预扣库存、库存流水，独立部署，使用独立的Redis集群。
• 订单服务：负责创建订单、订单状态流转，独立部署，与库存服务通过MQ解耦。
• 秒杀网关：基于Spring Cloud Gateway，负责秒杀路由、限流、防重复提交，是整个秒杀流量的唯一入口。

这是一个典型的多服务拆分。你可能会问，用户服务和商品服务原本在单体里就存在，为什么要单独再拆？因为秒杀场景对这两个服务的调用量是平时的几十倍，如果不物理隔离，秒杀流量会把普通商城的查询也拖垮。物理隔离之后，即便秒杀链路出了问题，普通的下单、加购、退款仍然可用。

各服务之间通过OpenFeign做同步RPC调用，通过RocketMQ做异步解耦。工程上统一使用Spring Boot 2.7.x + Spring Cloud Alibaba 2021.x版本，注册中心用Nacos，配置中心也用Nacos，网关用Spring Cloud Gateway，熔断降级用Sentinel。

2.3 拆完之后的一个隐性成本：链路变长，超时控制必须重做

拆分之后最大的感受是：以前单体里一个方法调另一个方法，失败了直接抛异常回滚事务就行。现在服务之间是网络调用，就要面对超时、重试、幂等等一系列分布式问题。

以秒杀主流程为例，请求要经过：网关 -> 秒杀网关 -> 库存服务 -> (MQ) -> 订单服务。每一步都可能超时。我当时的做法是给OpenFeign统一配置了连接超时2秒、读超时3秒的阈值，同时用Sentinel配置了QPS维度的流控规则和异常比例的熔断规则。一条链路的超时时间必须严格把控，任何一个环节读超时时间设置过长，都会拖垮整体吞吐。这是拆完之后很多人都忽略的坑。

3. 库存防超卖：从数据库行锁到Lua脚本的演进

3.1 为什么数据库行锁方案在秒杀场景下不可行

库存防超卖是秒杀系统最核心的问题。最简单的方案是数据库更新时加条件：

sql复制UPDATE sku_stock SET stock = stock - 1 WHERE sku_id = 123 AND stock > 0;

这条SQL利用数据库的行锁保证同一时刻只有一个事务能成功扣减，配合stock > 0条件就能防止超卖。这个方案在低并发下完全没问题，但在秒杀场景下，1000个并发请求同时update同一行，数据库的行锁会让这1000个请求串行执行。虽然数据不会出错，但响应时间完全不可控，数据库的QPS也会被锁竞争拖垮。

我压测过这个方案，2000并发下数据库的CPU直接飙到90%以上，平均响应时间超过5秒，大量请求超时。结论是：数据库防超卖只能作为最后的兜底，不能作为秒杀主链路的方案。

3.2 Redis预扣库存与Lua脚本的原子性保证

主链路我选择了Redis预扣库存方案。核心思路是：秒杀开始前，把商品库存预先加载到Redis中，用DECR命令或Lua脚本完成扣减，只有Redis扣减成功的请求才允许继续走下单流程。

这里有一个非常关键的设计——扣库存必须用Lua脚本保证原子性。下面是我当时写的扣减脚本：

lua复制-- KEYS[1]: 库存key，例如 seckill:stock:1001
-- KEYS[2]: 已售key，例如 seckill:sold:1001
-- ARGV[1]: 本次扣减数量

local stock = tonumber(redis.call('get', KEYS[1]) or '0')
local sold = tonumber(redis.call('get', KEYS[2]) or '0')

if stock < tonumber(ARGV[1]) then
    return 0
end

redis.call('decrby', KEYS[1], ARGV[1])
redis.call('incrby', KEYS[2], ARGV[1])
return 1

为什么不能用DECR命令加一次GET来判断？因为判断和扣减是两个操作，在高并发下存在时间差。A请求判断库存为1，还没来得及减，B请求也判断库存为1，两个都通过了，就超卖了。Lua脚本在Redis中是原子执行的，整个脚本执行期间不会有其他命令插入，所以判断和扣减是捆绑在一起的。

3.3 数据库库存扣减的兜底与对账

Redis扣减成功不代表数据库可以不做处理。最终数据库里必须有一份准确的库存记录，用于对账、退款、发货等操作。

我的设计是：Redis扣减成功 -> 发送MQ消息 -> 订单服务消费消息 -> 创建订单 -> 异步将预扣的数据库库存转为实际扣减。

数据库层的扣减仍然使用条件更新：

sql复制UPDATE sku_stock 
SET stock = stock - #{count},
    version = version + 1 
WHERE sku_id = #{skuId} 
  AND stock >= #{count};

这里加了乐观锁的version字段，同时保留stock >= #{count}条件。两套方案叠加的目的是：Redis保证用户端的快速响应和大部分拦截，数据库保证最终的强一致。

这里有个体验问题需要提前想清楚：用户秒杀成功后，数据库异步扣减万一失败了怎么办？我的做法是预留一个对账任务，每5分钟扫描一次Redis已售数和数据库实际扣减数的差异，发现不一致就告警并尝试重试补偿。实际运行中，消息丢失的概率极低，但补偿链路一定要有，不然出问题的时候你连数据对不对都不知道。

4. 缓存设计：热点数据的读多写少问题

4.1 商品详情的三级缓存架构

秒杀场景下，商品详情的请求量是最大的。用户还没点"立即秒杀"之前，就已经把商品详情页刷了无数次了。如果每一次都查数据库，数据库肯定扛不住。

我给商品详情设计了三级缓存：

• 本地缓存：Caffeine，每个服务实例内存中缓存商品详情，过期时间60秒。这一层的命中率大概有40%左右，因为秒杀场次的商品是固定的，用户请求会集中在这几个SKU上。
• Redis缓存：缓存商品详情JSON，过期时间5分钟，key格式seckill:product:1001。这一层的命中率在50%左右。
• 数据库兜底：本地缓存和Redis都没有命中的时候查询数据库。

这里要注意一个问题：本地缓存是每个实例各存一份的，如果某个商品在上架前改了价格，那最多有60秒的延迟，这个可以接受。但如果你的业务对数据的实时性要求极高，本地缓存就不适合了，一律走Redis。

4.2 缓存击穿：一个热点key过期瞬间的雪崩

秒杀场景有一个很容易踩的大坑——缓存击穿。商品详情Redis缓存的过期时间到了，key正好失效，此时几十万个请求同时涌向数据库，数据库瞬间被打爆。

解决缓存击穿有两种主流方案：互斥锁重建缓存和逻辑过期。

互斥锁方案：当缓存失效时，不是所有请求都去查数据库，而是只让一个请求去查数据库并重建缓存，其他请求等待。可以用Redis的SETNX实现：

java复制public String getProductDetail(Long productId) {
    String cacheKey = "seckill:product:" + productId;
    String detail = redisTemplate.opsForValue().get(cacheKey);
    if (detail != null) {
        return detail;
    }
    // 尝试获取锁，key为 lock:product:1001，超时时间3秒
    Boolean locked = redisTemplate.opsForValue()
        .setIfAbsent("lock:product:" + productId, "1", Duration.ofSeconds(3));
    if (Boolean.TRUE.equals(locked)) {
        try {
            detail = productService.queryFromDb(productId);
            redisTemplate.opsForValue().set(cacheKey, detail, Duration.ofMinutes(5));
            return detail;
        } finally {
            redisTemplate.delete("lock:product:" + productId);
        }
    } else {
        // 没获取到锁，短暂sleep后重试
        Thread.sleep(50);
        return getProductDetail(productId);
    }
}

逻辑过期方案：缓存数据里保存真正的过期时间，而不是依赖Redis的TTL。每次读取时判断逻辑过期时间是否到了，如果到了，异步去重建缓存，当前请求继续返回旧数据。这个方案的数据一致性稍弱，但性能最好，秒杀场景下体验更佳。

4.3 缓存预热：别等用户来触发

秒杀开始前，商品信息和库存必须提前写入Redis。我的做法是写一个定时任务，场次开始前1分钟把商品详情和库存加载到Redis中。这个步骤很重要，因为如果等第一个用户来触发缓存加载，你无法确定第一个用户请求到来时缓存是否已经就绪。

我在第一次上线时吃过这个亏——场次开始了，Redis里库存还没加载，所有请求直接打到数据库，数据库连接池瞬间耗尽，秒杀直接变成了"秒崩"。所以缓存预热一定要作为上线流程的一部分，配合发布平台的流水线自动执行。

5. MQ削峰填谷：从同步下单到异步下单

5.1 同步下单为什么会被压垮

早期版本的下单流程是同步的：扣完库存 -> 调用订单服务创建订单 -> 返回结果。这个流程在500并发以内还能跑，超过500并发就开始出现大量超时。

原因是创建订单涉及多个数据库写操作：插入订单表、插入订单明细表、更新商品销量、记录库存流水。这几个写操作在一个事务里，数据库的锁竞争非常激烈。2000并发同时进来，数据库的写入能力远跟不上。

**削峰的核心思路是：把请求拆成"接收"和"处理"两段。**接收请求时只需要做轻量操作，然后立刻响应"已收到"；真正的订单创建放到后台异步执行。

5.2 RocketMQ 异步下单的完整流程

改造后的下单流程：

1. 用户请求到达网关，完成限流和登录校验。
2. 进入秒杀服务，校验场次时间、商品状态、用户是否已购买。
3. Redis Lua脚本扣减库存，扣减失败直接返回"已抢光"。
4. 扣减成功后，发送一条MQ消息，内容包含userId、skuId、场次ID、秒杀价格。
5. 立即返回"秒杀成功，订单处理中"。
6. 订单服务监听MQ消息，创建订单，标记秒杀成功。
7. 订单创建成功后通过WebSocket或状态轮询通知前端。

这里有一个非常关键的会话一致性设计点——如果用户秒杀成功后立即去"我的订单"里查，大概率查不到，因为订单还没创建。我在前端页面上做了处理：秒杀成功后轮询订单状态接口，最多轮询5次，每次间隔1秒，如果5秒后还没看到订单，再提示"订单处理中，请稍后刷新"。同时给MQ消费者设置了失败重试机制，保证消息最终被成功消费。

5.3 消息不丢失的三重保障

MQ环节最怕消息丢失。消息丢失等于用户秒杀成功但订单没了，属于重大事故。我当时做了三重保障：

1. 生产者保证消息发送成功：发送端使用同步发送方式，并设置setRetryTimesWhenSendFailed(3)。发送失败时记录日志并降级为同步创建订单——虽然慢，但至少不丢。
2. Broker持久化：RocketMQ默认消息会落盘，但需要确认打开flushDiskType=ASYNC_FLUSH，保证写入PageCache后返回，性能与持久化的折中。
3. 消费者确认机制：消费者使用MessageListenerConcurrently，处理成功后返回ConsumeConcurrentlyStatus.CONSUME_SUCCESS，处理失败返回RECONSUME_LATER，RocketMQ会自动重试。同时消费者幂等是必须的，因为RocketMQ的重试可能导致消息重复投递。

5.4 消费者幂等：一个容易被忽略的细节

MQ消费者幂等怎么做？我踩过坑：消费失败重试后，订单表插入了两条同样的记录。

幂等方案我选择了"唯一键约束 + 插入前判断"。订单表加了一个biz_unique_key字段，内容格式为seckill_order:{userId}:{skuId}:{sessionId}，数据库层加唯一索引。消费者处理消息时先尝试插入订单，如果插入报唯一键冲突，说明消息已经处理过，直接返回成功。

这样就不用加Redis分布式锁，也不用查数据库再判断，靠数据库的唯一索引就可以保证幂等，性能开销最小。

6. 限流与接口防刷：从网关到业务层的多层防御

6.1 为什么需要多层限流

单层限流解决不了所有问题。网关限流挡的是流量入口的洪峰，但无法区分正常用户和脚本；业务层限流可以结合用户维度的精细化控制；接口层的防刷逻辑需要独立于网关存在，因为攻击者完全可以绕过网关直连服务端口（虽然内网有网络隔离，但微服务架构下还是要以防万一）。

我的限流架构分三层：

• Nginx层：限制单IP每秒请求数，超过阈值直接返回444并拉黑IP。
• 网关层：使用Sentinel配置按路由的QPS限流，秒杀路由/seckill/**的阈值按压测结果动态调整。
• 业务层：基于用户ID的限流，一个用户一秒钟最多允许3次秒杀请求。

6.2 令牌桶算法与Sentinel配置

Sentinel的默认限流算法是滑动窗口，也可以配置为令牌桶。令牌桶的特点是允许一定程度的突发流量，适合秒杀场景前几秒的流量脉冲。我在网关层配置的规则：

yaml复制spring:
  cloud:
    sentinel:
      datasource:
        ds1:
          nacos:
            server-addr: 127.0.0.1:8848
            dataId: seckill-gateway-flow
            rule-type: flow

配置内容：

json复制[
  {
    "resource": "/seckill/**",
    "limitApp": "default",
    "grade": 1,
    "count": 2000,
    "strategy": 0,
    "controlBehavior": 2,
    "warmUpPeriodSec": 10
  }
]

这里grade=1表示按QPS限流，count=2000表示每秒最多放行2000个请求，controlBehavior=2表示匀速排队模式（对应漏桶），超过阈值的请求在队列中等待，而不是直接拒绝。warmUpPeriodSec=10表示预热10秒，让流量慢慢爬升到阈值，避免冷启动时被击穿。

实际调优时的经验：网关的限流阈值不能压得太紧，要给业务层留出余量。我一开始把网关QPS阈值设成和业务层持平，结果业务层一抖动，网关就开始大量拒绝正常用户。后来改成业务层阈值的1.5倍，给下游留了缓冲。

6.3 接口防刷的黑名单机制

秒杀系统最怕的不是人类用户，是脚本。脚本可以在1秒内发出几十个请求，而且每次都换IP。我做了以下防刷策略：

• 用户维度的防重复购买：用户在Redis中购买记录的key存在时，直接拒绝。key的过期时间设置为一整天，防止用户两场秒杀之间重复下单。
• UA特征识别：检查请求的User-Agent，脚本的UA往往是空值或非常规的值。但这个策略误杀率较高，我在生产环境只做了记录没有主动拒绝。
• 动态令牌：秒杀开始前前端会请求一个参与令牌，服务端生成后返还给前端，秒杀请求必须携带令牌。因为令牌是动态生成的且一次性使用，脚本很难提前准备大量令牌。

这套防刷方案能做到什么程度？上线后统计，脚本流量在总请求量的占比从没做防刷前的70%降到15%左右。没有绝对完美的防刷，但能拦住大部分低级脚本，就达到了业务目标。

7. 压测数据与调优过程：数字不会骗人

7.1 压测方案与工具选择

我用JMeter做压测，压测机和服务器分属不同机器，避免压测工具本身占用服务资源影响数据准确性。压测场景是：2000个并发线程，模拟10000个用户抢200件库存的商品，持续时间3分钟。

压测过程中主要关注四个指标：QPS、响应时间P95、错误率、数据库的CPU使用率。

7.2 第一轮压测：大量超时和错误

第一轮压测的结果很不理想：

从数据看，错误率高的原因主要有两个：一是Tomcat线程池被打满，大量请求排队超时；二是Redis连接池被耗尽，redis.clients.jedis.JedisPool抛出了Could not get a resource from the pool异常。

7.3 针对性的优化措施

第一轮优化方向是：

1. 调整Tomcat线程池参数。把server.tomcat.threads.max从默认的200调整到500，server.tomcat.accept-count从100调整到600。线程池太小会导致请求排队，但线程池也不是越大越好，太大的线程池会带来上下文切换开销和内存压力。

2. Redis连接池调优。JedisPool的maxTotal从默认的8调整到50，maxIdle从8调整到20，maxWaitMillis从-1调整到2000。同时把Jedis客户端替换成了Lettuce，因为Lettuce是异步的，连接利用率更高。

3. 去掉同步下单，启用MQ异步化。这是QPS提升最大的一个改动。

4. 本地缓存Caffeine的开启。商品详情接口原本直接查Redis，Redis的QPS成为瓶颈。加了一层本地缓存后，Redis的QPS降低了接近一半。

7.4 第二轮压测：达标的性能数据

优化后重新压测：

第二轮压测时，真正打到数据库的写请求只有每秒300个左右（因为MQ削峰的原因），数据库完全扛得住。系统能挺住3500 QPS的关键不是硬件有多强，而是大部分流量被Redis、本地缓存、限流这三层挡掉了。

7.5 压测中踩过的配置坑

压测过程中有一个印象很深的坑：JMeter的压测机本身成了瓶颈。2000个并发线程在JMeter里模拟时，压测机的CPU先到100%，导致请求发送速度达不到预期，压测结果失真。后来改用分布式压测，用3台压测机分摊压力，数据才可信。

另一个坑是连接池的maxWaitMillis设置问题。第一次压测时把它设置成了-1（无限等待），Redis连接池耗尽后所有线程都在永无止境地等待，看起来像系统挂了但实际是线程全部阻塞了。改成2000毫秒后，连接池满了就直接报错，快速失败反而让系统更健壮。

8. 上线后的监控告警与一些运维经验

8.1 Spring Boot Actuator与Micrometer的接入

热词里有人问"spring boot actuator漏洞""micrometer + spring boot actuator"怎么用，这里正好说一下我的实践。

秒杀系统上线后，监控是必须跟上的。我引入了Actuator和Micrometer，暴露健康检查、线程、内存、Tomcat连接数等指标，接入Prometheus + Grafana做可视化监控。

依赖配置：

xml复制<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

配置：

yaml复制management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus,metrics
  endpoint:
    health:
      show-details: always

Actuator在暴露监控指标的同时，也会暴露一些敏感信息。/actuator/env可以看到环境变量，/actuator/heapdump可以下载堆转储文件。生产环境必须限制访问：只暴露health和prometheus端点，env、beans、heapdump、shutdown全部关闭；同时通过Spring Security配置仅允许监控系统的IP访问/actuator/**路径。这是我一直在强调的安全底线，监控能力不能以泄露应用内部信息为代价。

8.2 秒杀期间需要盯紧的四个核心指标

秒杀进行中，我盯得最多的是四个指标：

• Redis的QPS和内存：QPS超过2万说明缓存层压力太大，需要排查是否本地缓存失效了；内存增长过快说明存在大key或缓存颗粒度问题。
• RocketMQ的积压消息数：消费者的消费能力跟不上生产者的发送速度时，消息会积压，订单创建会延迟。快速的办法是增加消费者实例数或提高消费线程数，但根本是要找到消费慢的原因。
• Sentinel的拒绝数：被限流拒绝的比例超过30%时，说明流量峰值远超预期，需要评估是否需要临时扩容。
• 订单服务的成功率：MQ消费者处理失败率超过5%时立即告警，重点排查是否是数据库慢SQL或唯一键冲突导致的重试风暴。

8.3 一次线上事故的复盘：Redis缓存雪崩的连锁反应

上线第三周遇到一次事故，印象很深刻。那天秒杀场次开始前，我做了一次Redis的内存清理操作，误删了一批没有设置过期时间的缓存key。因为秒杀商品的缓存key全部没有设TTL（原本设计是一劳永逸地存着），删掉之后所有请求同时回源查数据库，数据库瞬间被打到连接池耗尽，连带影响了其他业务。

复盘后的改进措施：

1. 所有缓存key必须设置过期时间，没有例外。商品详情可以设置5分钟过期，库存数据必须用Lua脚本保证一致性。
2. 缓存重建必须走互斥锁，防止缓存击穿。
3. 生产环境的Redis操作要双人复核，尤其是删除和清空这类高风险命令。

这次事故让我意识到，缓存层引入后，系统多了一个故障点。设计任何缓存操作时都要考虑"如果这个缓存失效，系统还能不能扛住"。

9. 这套方案可以怎么扩展和复用

秒杀系统的架构思路可以迁移到很多其他业务场景。它的核心方法论是：用缓存挡读流量，用MQ削写峰值，用限流保护下游，用兜底保数据一致。

你如果要做类似的活动系统，比如"限量优惠券抢领""新品限量预约""抽奖秒杀"，这套架构基本可以复用。只需要改一下业务字段和接口路径，不需要重新设计架构。

对这个项目我还想说一个看法：**微服务拆分不是目的，是手段。**如果你们的产品同时在线人数只有几百人，单体架构完全够用，强行上微服务反而增加了运维复杂度和问题排查的难度。我的实践体会是，当单体应用在压测中已经无法通过简单的横向扩容解决问题时，才需要认真考虑微服务架构。而这套秒杀系统的拆分设计，正是从单体应用无法承受的峰值流量出发，用实际需求倒逼出来的架构演进结果。

如果你正在做类似的方案，我建议你先想清楚三件事再动手：一是你到底需不需要微服务，二是你的Redis和MQ的基础设施是否已经成熟，三是团队对分布式事务、幂等等概念是否理解到位。这些想清楚之后，剩下的技术实现都是水到渠成的事。

秒杀系统做完之后有个很奇妙的感受：平时写代码追求的优雅和复用，在秒杀链路里反而要故意"写脏"一点——短路逻辑要快，分支判断要简单，能用local变量就不用查数据库，能提前返回就绝不绕弯。秒杀场景下，速度就是用户体验，简单就是最大的可靠。