生死时速：高并发秒杀系统的架构设计与防超卖实战

"秒杀"（Seckill）是电商系统中最为极端的场景之一：在极短的时间内（通常是毫秒级），海量的用户请求瞬间涌入，试图争夺极其有限的库存。

对于系统设计者而言，秒杀是一场关于一致性 与可用性 的极限挑战。如果只靠简单的缓存和消息队列，往往难以抵挡洪峰，更无法从根本上杜绝"超卖"这一致命问题。本文将深入探讨如何构建一个坚不可摧的秒杀系统，重点剖析Redis原子操作 、库存扣减策略 、动静分离 以及限流熔断等核心技术。

一、核心痛点：为什么传统的"查后改"会超卖？

在传统业务中，扣减库存的逻辑通常是：

查询数据库剩余库存 SELECT stock FROM goods WHERE id = 1。
判断 if (stock > 0)。
更新数据库 UPDATE goods SET stock = stock - 1 WHERE id = 1。

在高并发下，成千上万个线程同时执行步骤1，都会读到 stock = 100。接着它们都通过步骤2的判断，最后同时执行步骤3。结果就是：100个商品被卖出了1000次，这就是典型的超卖。

即使加上数据库的行锁（SELECT ... FOR UPDATE），巨大的锁竞争也会导致数据库吞吐量急剧下降，甚至直接宕机。因此，必须将库存扣减的战场从数据库转移到内存，并利用原子性保证安全。

二、防超卖的终极武器：Redis原子操作与Lua脚本

为了防止超卖，库存扣减操作必须是原子性的（Atomic），即"读取-判断-扣减"这三个动作必须作为一个不可分割的整体执行。

1. 为什么不用Redis原生命令？

虽然Redis的 DECR 命令是原子的，但它无法满足复杂的业务逻辑（例如：库存不足时返回特定错误码、检查用户是否重复购买、校验活动时间等）。如果将这些逻辑拆分成多个Redis命令调用，在网络传输过程中依然可能被其他请求插入，破坏原子性。

2. Lua脚本：服务端的事务

Redis支持使用Lua脚本 。当客户端发送一段Lua脚本给Redis时，Redis会将整个脚本放入一个队列中串行执行。在脚本执行期间，不会有任何其他命令插入。这完美实现了"检查 + 扣减"的原子性。

防超卖Lua脚本示例：

复制代码

-- KEYS[1]: 库存Key (e.g., "seckill:stock:1001")
-- ARGV[1]: 扣减数量 (e.g., "1")
-- ARGV[2]: 用户ID (用于防止重复购买，可选)

local stock = tonumber(redis.call('GET', KEYS[1]))

-- 1. 检查库存
if not stock or stock <= 0 then
    return -1 -- 库存不足
end

-- 2. (可选) 检查用户是否已购买，防止刷单
-- local user_key = "seckill:user:" .. ARGV[2]
-- if redis.call('EXISTS', user_key) == 1 then
--     return -2 -- 重复购买
-- end

-- 3. 执行扣减
redis.call('DECRBY', KEYS[1], ARGV[1])

-- 4. (可选) 记录用户购买状态
-- redis.call('SETNX', user_key, "1")
-- redis.call('EXPIRE', user_key, 3600)

return stock - 1 -- 返回剩余库存

执行流程：

用户请求到达后端，不直接查库。
后端将上述Lua脚本发送给Redis。
Redis串行执行脚本：若库存>0，则扣减并返回成功；否则返回失败。
只有Redis返回成功，后端才认为抢购成功，并将订单消息写入消息队列（MQ），异步通知数据库最终扣减和创建订单。
若Redis返回失败，直接向前端返回"已售罄"，请求在此处被拦截，根本不会打到数据库。

关键点 ：通过这种方式，超卖在内存层就被彻底杜绝了。数据库只负责处理最终成功的、流量已经大幅削峰的订单写入。

三、应对热点数据：多层防御与动静分离

秒杀商品的ID是典型的热点数据（Hot Key）。即使有Redis，如果每秒百万级的请求全部打在同一个Redis Key上，也可能导致单分片网卡打满或CPU飙升。我们需要构建多层防御体系。

1. 动静分离：让静态流量不进后端

秒杀页面的大部分内容（商品图片、介绍、倒计时）是静态的，只有"库存数量"和"按钮状态"是动态的。

策略：将静态资源上传至CDN（内容分发网络）。
效果：90%以上的读请求（页面加载、图片获取）直接被CDN边缘节点拦截，完全不需要经过应用服务器和数据库。
动态部分 ：对于库存数字，可以采用前端本地缓存 + 轮询，或者通过WebSocket推送，减少HTTP请求频率。

2. 令牌桶限流：控制入口流量

在网关层（如Nginx、Spring Cloud Gateway）或应用入口处实施严格的限流。

算法：使用令牌桶算法 或漏桶算法。
策略：假设系统处理能力是1000 QPS，那么网关只放行1000个请求，多余的请求直接返回"排队中"或"系统繁忙"。
意义：保护下游的Redis和数据库不被突发流量冲垮。

3. 库存预热与分段锁（进阶优化）

如果单个Redis Key依然是瓶颈，可以采用库存分段策略：

方法：将1000个库存拆分为10个Key（stock_0 到 stock_9），每个存100个。
路由：用户请求到来时，通过 userId % 10 路由到具体的某个Key。
优势：将热点分散到Redis集群的不同分片上，利用多核CPU和多网卡带宽，大幅提升吞吐量。
注意：这需要处理"某段库存卖完但其他段还有"的复杂逻辑，通常配合前端随机路由或后端自动切换段来实现。

四、系统兜底：熔断与降级

在极端情况下，即使做了所有优化，依赖的服务（如Redis集群、消息队列）仍可能出现故障或响应超时。此时必须有熔断机制。

熔断器模式（Circuit Breaker） ：
- 当检测到某个服务（如Redis）的错误率或响应时间超过阈值时，熔断器自动"跳闸"。
- 后续请求不再调用该服务，而是直接执行降级逻辑（如直接返回"活动太火爆，请稍后再试"）。
- 经过一段时间（如30秒）后，尝试放行少量请求探测服务是否恢复（半开状态）。
价值：防止因单个组件故障导致整个系统雪崩（级联失败），保住系统的核心可用性。

五、完整链路总结

一个成熟的秒杀系统，其请求流转路径如下：

用户层：点击秒杀按钮。
CDN层 ：静态页面、图片直接从边缘节点返回（动静分离）。
网关层 ：进行身份校验、黑名单过滤，并执行限流，拦截超出系统承载能力的流量。
应用服务层 ：
- 执行熔断检测，若依赖服务异常则快速失败。
- 调用Redis Lua脚本 执行原子性库存扣减（防超卖核心）。
- 若扣减失败，直接返回"售罄"。
- 若扣减成功，发送消息到消息队列（削峰填谷），并立即返回"排队中/抢购成功"给前端。
异步消费层 ：
- 消费者从MQ拉取订单消息。
- 以可控的速度（数据库能承受的QPS）写入数据库，完成最终的订单创建和库存持久化。
- 若数据库写入失败（极低概率），触发补偿机制或回滚Redis库存。

结语

设计高并发秒杀系统，本质上是在空间换时间 （用内存换速度）和异步换同步（用队列换即时性）之间寻找平衡。

防超卖 靠的是将复杂的逻辑收敛到Redis Lua脚本中，利用其单线程串行执行的特性保证原子性。
抗压力 靠的是动静分离 将流量挡在门外，靠限流控制入口，靠消息队列平滑后端写入。
高可用 靠的是熔断降级，确保系统在部分组件失效时仍能体面地拒绝服务，而不是崩溃。

没有银弹，只有层层设防。正是这些精妙的架构设计，让我们在"双11"的零点，既能感受到抢货的激情，又能确信每一笔交易都准确无误。