非常棒的问题 ⚡️

“秒杀系统（下）”一般是秒杀专题的架构与优化篇，主要讨论在上篇（功能逻辑设计）之后，如何抗高并发、控库存、限流、削峰、保证一致性。

下面我带你完整梳理一份《秒杀系统（下）：高并发架构设计与优化实战指南》。

🚀 一、秒杀系统核心挑战

秒杀活动本质上是一次 极端高并发读写场景：

挑战点描述
⏱ 高并发在几秒内涌入大量请求（几十万甚至上百万 QPS）
⚖️ 库存竞争同一件商品只有有限库存，必须防止超卖
🧩 一致性库存扣减、订单创建、支付状态要保持一致
🧱 性能瓶颈数据库、缓存、队列成为瓶颈
🛡️ 安全性防止刷单、恶意请求、重复购买

🧠 二、总体架构设计思路

一个成熟的秒杀系统，一般采用“前后分层 + 异步削峰 + 限流降级”的思路：

用户请求
   ↓
CDN / Nginx
   ↓
网关限流（Token / 用户验证）
   ↓
缓存层（Redis）判断库存、用户资格
   ↓
异步队列（Kafka / RabbitMQ）削峰
   ↓
秒杀服务（库存扣减逻辑）
   ↓
数据库（MySQL）
   ↓
异步通知 / 订单系统

⚙️ 三、核心模块设计

1️⃣ 请求预处理与限流

  • CDN + Nginx 层限流
    • 通过 IP、User-Agent、Token 等做基础限流；
    • 可以使用 Nginx 的 limit_req_zone 模块或接入 API 网关（如 Kong、Nacos Gateway）。
  • 用户级限流
    • 每个用户在活动期间只能请求 N 次；
    • 例如 Redis + Lua 脚本计数： local key = KEYS[1] local limit = tonumber(ARGV[1]) local current = tonumber(redis.call("incr", key)) if current == 1 then redis.call("expire", key, 1) end if current > limit then return 0 end return 1

2️⃣ 库存预热与扣减

  • 活动前预热
    • 将商品库存预加载到 Redis；
    • 使用 SETNX 或 INCRBY 控制库存；
    • 实现“库存不落地数据库”。
  • Redis 原子扣减 # redis-cli 模拟 if redis.decr("stock:1001") >= 0: # 扣减成功 else: # 库存不足
  • 防止超卖
    • 使用 Redis Lua 脚本实现扣减 + 校验原子操作；
    • 异步写回数据库（通过 MQ 或定时任务）。

3️⃣ 异步削峰：消息队列

请求高峰期不直接写数据库，而是先写入消息队列：

  • Kafka / RabbitMQ / RocketMQ；
  • 消费端顺序扣减库存、创建订单。
用户请求 → Redis 判断库存 → MQ → 消费者 → MySQL 更新

好处：

  • ✅ 系统抗压；
  • ✅ 削峰填谷；
  • ✅ 异步处理、容错性强。

4️⃣ 数据库优化

  • 只存必要字段，减轻 IO；
  • 采用分库分表、读写分离；
  • 表结构优化： CREATE TABLE seckill_order ( id BIGINT PRIMARY KEY, user_id BIGINT, product_id BIGINT, status TINYINT, create_time DATETIME ) ENGINE=InnoDB;
  • 创建联合索引 (product_id, user_id) 防止重复下单；
  • 使用 乐观锁版本号 控制并发扣减： UPDATE product SET stock = stock - 1 WHERE id = #{id} AND stock > 0;

5️⃣ 防刷与安全策略

  • 验证码 + 动态请求路径
    防止脚本批量请求；
  • 请求签名 / Token 鉴权；
  • 防止重复下单：
    Redis 记录用户是否已下单； if redis.setnx(f"user:{uid}:product:{pid}", 1): # 允许购买 else: # 重复请求

6️⃣ 最终一致性与异步校准

秒杀系统通常采用 最终一致性 模型：

  • Redis → MQ → 数据库 是异步的；
  • 定时任务对库存、订单做补偿校验；
  • 异步通知（邮件 / 短信）可通过 MQ 实现。

🧩 七、典型技术栈

模块技术选型
前端缓存CDN / Nginx
反向代理Nginx + 限流模块
缓存层Redis Cluster
消息队列Kafka / RocketMQ / RabbitMQ
后端服务Spring Boot / Go / Node.js
数据库MySQL + 分库分表（ShardingSphere）
监控与日志ELK / Prometheus / Grafana

🔧 八、架构优化总结

问题解决方案
瞬时流量高Redis 缓存 + MQ 异步处理
超卖Redis 原子扣减 + Lua
一致性异步消息 + 定时补偿
重复下单Redis 唯一键限制
宕机消息队列持久化 + 冗余消费者
安全防刷验证码 + Token + 限流

🎯 九、延伸阅读 / 实战参考

是否希望我帮你画一张 完整的“秒杀系统高并发架构图”（带缓存、MQ、数据库流程箭头）？
这样你能直观看清整个请求从入口到落地的执行路径。