当前位置：首页 > article >正文

如何设计一个高效、稳定的秒杀系统？

article 2025/2/13 21:38:25

今天，我们将从后端架构的角度深入探讨 “如何设计一个高效、稳定的秒杀系统”。

秒杀系统是电商领域中最具挑战性的场景之一，其核心特点是在极短时间内（通常是几秒到几分钟）处理海量用户的并发请求，同时确保系统的稳定性、数据的一致性以及用户体验的流畅性。这种场景对系统的架构设计、性能优化和容错能力提出了极高的要求。

秒杀系统的难点并不在于业务逻辑的复杂性（通常只是简单的下单和库存扣减），而在于如何在高并发、高性能、高可用以及数据一致性之间找到平衡点。具体来说，秒杀系统需要解决以下几个核心问题：

高并发：如何在短时间内处理数百万甚至上千万的用户请求？
高性能：如何确保每个请求都能在极短的时间内得到响应？
高可用：如何在系统压力剧增的情况下，依然保证服务的稳定性？
数据一致性：如何避免超卖、重复下单等问题，确保库存和订单数据的准确性？

接下来，我们将从实战角度出发，详细拆解秒杀系统的设计要点，涵盖从流量控制、数据存储、缓存优化到容错机制等多个方面，帮助你构建一个能够应对极端场景的秒杀系统。

一、应对流量洪峰的四大策略

在设计秒杀系统时，首要任务是应对瞬间爆发的流量洪峰。以下是四种核心策略：

1. 动静分离术

秒杀系统中的请求可以分为静态请求（如商品图片、CSS、JS等）和动态请求（如库存查询、下单等）。

静态资源可以通过CDN（内容分发网络） 进行分发，将资源缓存到离用户最近的边缘节点，从而大幅减少源站的压力。例如，某电商平台通过CDN分发静态资源，成功将带宽成本降低了60%。
对于动态数据，可以采用多级缓存策略：将全局库存数据存储在Redis集群中，同时将热点数据（如商品基础信息）缓存在本地JVM内存中。小米的秒杀系统就采用了Guava Cache实现本地热点缓存，访问速度可达百万QPS。

为什么还要放在 jvm 内存一份? 因为放在 jvm 内存中的数据访问速度是最快的，不存在什么网络开销。

在这里插入图片描述

2. 流量削峰三板斧

答题验证码：在用户发起秒杀请求之前，可以要求其完成答题或输入验证码。这种方式不仅能够缓解瞬时高并发请求压力，还能有效防止用户利用脚本作弊。对于回答问题或验证码的校验，除了检查正确性，还应对用户的提交时间进行检测，例如，如果提交时间过短（<1s），很可能是脚本自动处理的，从而可以进一步提高防刷效果。
异步下单：用户提交订单请求后，系统先把请求放入 Kafka 队列，并立即返回“排队中”的提示。后台会异步处理这些订单，按顺序执行下单操作。类似 12306，在高峰期时，把瞬时 200 万 QPS 的流量平缓地控制在 5 万 QPS 进行处理，避免系统崩溃。
分级漏斗：先通过预约筛选用户，只有符合条件的用户才能参与秒杀，并在正式抢购时分批放开库存。比如某手机品牌采用分时段 Token 机制，让用户在不同时间段进入抢购，成功降低 70% 的系统压力。

3. 熔断自保机制

在高并发场景下，系统必须具备自我保护能力。可以通过以下方式实现：

动态限流：使用Sentinel等限流工具，根据系统负载动态调整流量。Sentinel 是阿里巴巴推出的一款面向分布式服务架构的流量控制组件，经过淘宝近十年双 11 购物节的核心场景（如秒杀活动）的充分验证。它以流量管理为核心，提供流量控制、熔断降级、系统自适应保护等功能，旨在保障系统的稳定性和高可用性。
服务降级：降级是一种应对系统高负载的策略，主要目的是在服务器资源紧张时，通过有选择地减少或关闭某些非核心功能，确保关键业务的稳定运行。本质上就是 “牺牲次要，保全主要” 。
🌰当系统流量激增时，我们可以临时关闭一些非关键功能，如个性化推荐、历史订单查询等，以释放服务器资源，确保核心的秒杀功能能够流畅执行。

熔断： 熔断的作用是防止系统因外部依赖的异常而陷入雪崩式故障。它主要针对系统依赖的外部服务或第三方接口，一旦检测到这些依赖响应变慢或故障频发，就会主动中断请求，避免整个系统被拖垮。
🌰假设秒杀服务 (A) 还提供商品管理功能，如果商品管理接口变得极其缓慢，熔断机制可以让其他服务暂停对该接口的请求，从而避免因一个功能异常导致整个系统性能下降甚至崩溃。

4. 集群化部署

1. Redis 部分：

Redis 用了 Codis 集群和哨兵机制，这种架构可以让一个集群轻松处理每秒上百万的请求。举个例子，有人用了三主六从的架构（就是 3 个主节点 + 6 个从节点），结果这个集群能扛住每秒 500 万次的库存查询。简单来说，就是 Redis 通过这种集群和主从复制的方式，既能分担压力，又能保证高可用性。
在这里插入图片描述

2. MySQL 部分：

MySQL 用了 MHA（主从切换工具）和 Keepalived（高可用工具）来保证数据库的稳定性，同时还做了分库分表。分库分表的意思就是把一个大表拆成很多小表，分散到不同的数据库里。比如有个平台把订单表按照用户 ID 分成 256 个库，结果系统的处理能力（TPS）直接提升了 20 倍。说白了，就是通过拆分数据和路由查询，让数据库的压力分散开，性能自然就上去了。
在这里插入图片描述

二、数据一致性的攻防战

1. 库存防超卖方案

local stock = redis.call('get', KEYS[1])
if tonumber(stock) > 0 then
    redis.call('decr', KEYS[1])
    return 1
end
return 0

Redis+Lua实现原子扣减，某测试显示万次并发0误差
异步对账机制：通过Binlog将Redis库存同步至MySQL，设置5秒延迟容忍窗口

不过，如果 Lua 脚本在执行过程中出错并中途停止，那么出错之后的命令是不会被执行的。而且，出错之前已经执行的命令也无法撤销，也就是说，Lua 脚本并不能像关系型数据库那样，实现执行失败后回滚的原子性效果。所以，严格来说，通过 Lua 脚本来批量执行 Redis 命令并不能完全保证原子性。如果想要确保 Lua 脚本中的所有命令都能执行，必须确保脚本中的语法和命令都是正确的，不能有任何错误。

⚠️注意： 使用乐观锁来防止超卖并不适合高并发场景，比如秒杀系统。虽然很多同学在项目经历中提到使用乐观锁，可能是从某些培训机构学来的，但在实际应用中，乐观锁在高并发环境下表现不佳。
在秒杀系统中，大量用户同时抢购少量商品，乐观锁的冲突率会非常高。这意味着很多请求会更新失败，需要不断重试，导致效率低下，数据库压力剧增，甚至可能引发性能瓶颈。因此，乐观锁并不是解决超卖问题的理想方案。
相比之下，悲观锁或分布式锁在高并发场景中更为合适，能够更好地控制并发访问，避免超卖问题。

2. 资金安全锁

START TRANSACTION;
SELECT balance FROM account WHERE user_id=123 FOR UPDATE;
UPDATE account SET balance=balance-100 WHERE user_id=123;
COMMIT;

悲观锁确保资金准确，某银行系统实测可承受5万TPS
补偿机制：每小时跑对账任务，修复异常交易

3. 幂等性保障

令牌机制：
这个机制的核心是为了防止重复提交或者重复操作。比如在秒杀场景中，系统会提前生成一批全局唯一的 ID（可以理解为一个“令牌”），然后把这些 ID 存到 Redis 里。当用户发起请求时，系统会先检查这个 ID 是否在 Redis 中存在。如果存在，就允许操作，并且把这个 ID 从 Redis 里删掉，防止别人再用；如果不存在，就说明这个请求可能是重复的，直接拒绝掉。这种方式可以有效地防止重复提交或者恶意刷单，保证每个操作都是唯一的。
状态机设计：
状态机是用来管理订单状态的，它的核心思想是让订单状态严格按照规定的流程走，不能乱跳。比如订单的状态只能是“待支付 -> 已支付”，不能从“待支付”直接跳到“已完成”，或者从“已支付”退回到“待支付”。这种方式可以避免订单状态混乱，比如防止用户没支付就确认收货，或者支付后又莫名其妙退回到待支付状态。通过状态机的设计，系统的业务流程会更加清晰和可控。

三、全链路压测实践

1. 压测工具选型

JMeter：某电商用300台压测机模拟千万级并发
Gatling：某社交平台实现实时压测报告生成

2. 黄金指标体系

服务端：CPU<70%，GC停顿<100ms，Redis OPS<80%阈值
数据库：连接数<max_connections*80%，慢查询<10/分钟
中间件：Kafka堆积量<1000，RocketMQ P99<200ms

四、运维监控体系

1. 全链路追踪：

接入SkyWalking，实时显示调用拓扑

2. 智能预警：

基于时序数据库实现5分钟级故障预测

3. 流量调度：

通过DNS+SLB实现跨机房流量切换

五、典型架构演进

某头部电商秒杀系统演进路线：

版本	关键技术	瓶颈 & 目标	QPS
1.0 时代	Tomcat + MySQL 行锁	数据库锁竞争，500 QPS 崩溃	500
2.0 时代	Redis 缓存库存	解决 MySQL 压力问题，减少锁竞争	1 万+
3.0 时代	Sentinel 限流 + 本地缓存 + MQ	限流优化，降低 Redis 压力，防止超卖	10 万+
4.0 时代	全链路异步化 + 分库分表	支撑大促活动，高并发稳定运行	百万级