这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
完整架构：秒杀系统的最终架构图
回顾：我们走过了怎样的旅程？🎬
经过前面六章的学习，我们已经掌握了秒杀系统的各个核心模块。现在，让我们把这些拼图组合起来，看看最终的完整架构是什么样子的！🚀
完整架构图 🏗️
最简单的三层架构，直接访问数据库
用户层
用户请求 Web / App / 小程序
应用层
应用服务器 处理业务逻辑
数据层
MySQL 订单、库存数据
增加 Redis 缓存层，提升性能
用户层
用户请求 高并发访问
应用层
应用服务器 ×10 库存扣减逻辑
缓存层
Redis 集群 ×6 库存预扣减
数据层
MySQL 主从 ×3 订单持久化
引入消息队列，削峰填谷
用户层
用户请求 10万 QPS
接入层
API Gateway ×9 限流、鉴权
服务层
秒杀服务 ×10 库存扣减
订单服务 ×5 异步下单
数据层
Redis 集群 ×6 库存缓存
Kafka ×3 消息队列
MySQL ×3 持久化
高可用、高性能的完整秒杀系统
用户层
用户请求 Web / App / 小程序 / H5
CDN 层
CDN 静态资源加速
接入层
Nginx LB ×4 负载均衡
API Gateway ×9 限流、鉴权、黑名单
服务层
秒杀服务 ×10 库存扣减、订单创建
商品服务 ×5 商品信息、库存查询
用户服务 ×5 用户信息、实名认证
数据层
Redis 集群 ×6 库存缓存、分布式锁
Kafka ×3 异步下单、日志
MySQL 主从 ×6 订单、用户数据
辅助系统
反欺诈系统 设备指纹、行为分析
监控系统 Prometheus + Grafana
日志系统 ELK Stack
核心流程详解 🔄
1. 秒杀请求处理流程
2. 库存扣减流程
3. 异步订单创建流程
数据流向图 📊
用户请求
│
▼
┌──────────────────────────────────────────┐
│ CDN (静态资源直接返回) │
└──────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Nginx (负载均衡) │
└──────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ API Gateway │
│ ├─ 限流检查 → Redis │
│ ├─ 黑名单检查 → Redis │
│ └─ 鉴权 → JWT │
└──────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ 反欺诈系统 │
│ ├─ 设备指纹 → Redis │
│ ├─ 行为分析 → 实时计算 │
│ └─ 风险评分 │
└──────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ 秒杀服务 │
│ ├─ 库存预检查 → Redis │
│ ├─ 库存扣减 → Redis (Lua 脚本) │
│ └─ 发送消息 → Kafka │
└──────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Kafka (消息队列) │
└──────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ 订单服务 (Consumer) │
│ ├─ 创建订单 → MySQL │
│ ├─ 扣减库存 → MySQL (乐观锁) │
│ └─ 发送通知 → 消息推送 │
└──────────────────────────────────────────┘
│
▼
用户收到结果系统容量规划 📈
服务器配置
| 组件 | 数量 | 配置 | 用途 |
|---|---|---|---|
| Nginx | 4 台 | 8C16G | 负载均衡 |
| API Gateway | 9 台 | 8C16G | 网关服务 |
| 秒杀服务 | 10 台 | 16C32G | 核心业务逻辑 |
| 商品服务 | 5 台 | 8C16G | 商品查询 |
| 用户服务 | 5 台 | 8C16G | 用户信息 |
| Redis Master | 3 台 | 16C64G | 主节点 |
| Redis Slave | 3 台 | 16C64G | 从节点 |
| MySQL Master | 3 台 | 32C128G | 主库 |
| MySQL Slave | 3 台 | 32C128G | 从库 |
| Kafka Broker | 3 台 | 16C64G | 消息队列 |
性能指标
| 指标 | 目标值 | 说明 |
|---|---|---|
| QPS | 100,000+ | 峰值处理能力 |
| P99 延迟 | < 100ms | 99% 请求在 100ms 内返回 |
| 可用性 | 99.99% | 年停机时间 < 53 分钟 |
| 库存准确率 | 100% | 零超卖 |
| 反欺诈准确率 | > 95% | 黄牛识别率 |
关键技术栈 🛠️
配置要点
- 配置表达的是环境差异和运行参数，不是业务规则本身。
- 队列、缓存、存储和服务参数决定系统在高峰期的缓冲能力。
想一想
问题 1：如果 Redis 集群宕机，系统还能工作吗？
点击查看答案
降级策略：
- 本地缓存兜底（Guava Cache / Caffeine）
- 直接查数据库（性能下降，但可用）
- 限流更严格（保护数据库）
- 页面提示”系统繁忙，请稍后再试”
核心原则：保证可用性 > 保证性能
问题 2：如何保证 Redis 和 MySQL 的库存一致性？
点击查看答案
最终一致性方案：
- Redis 先扣减（快速响应用户）
- 异步消息同步到 MySQL
- 定时对账任务检查差异
- 发现不一致时，以 MySQL 为准回滚
关键点：允许短暂不一致，但最终必须一致
问题 3：如果秒杀流量超过预期 10 倍，怎么办？
点击查看答案
应急方案：
- 立即启动更严格的限流（降级到 1 万 QPS）
- 静态页面直接返回”已售罄”（如果库存已完）
- 关闭非核心功能（评论、推荐等）
- 扩容（如果有预留资源）
- 启用备用集群（如果有灾备）
预防方案：
- 提前压力测试，了解系统上限
- 预留 50% 以上的资源余量
- 制定详细的应急预案