这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
系统设计实战第 6 卷
系统设计实战
系统设计 - 秒杀抢购
流量入口
消息队列
库存
Redis预扣库存
限流降级
从一次限量抢购活动出发，构建覆盖流量削峰、库存扣减、Redis 队列、数据库锁、库存同步和防刷风控的秒杀系统
系统演进路线
从数据库扣库存到秒杀活动作战平台
第 1 版
数据库扣库存
第一次限量活动只有几百人参与，用事务扣库存。
商品库存表订单表乐观锁
能防超卖，但高峰期数据库锁冲突会迅速放大。
第 2 版
Redis 预扣库存
活动入口流量暴涨，需要把库存判断前置到内存。
库存预热Redis 扣减资格校验下单队列
核心链路变快，但 Redis 与数据库库存必须对账。
第 3 版
流量削峰排队
无效请求远大于库存，系统要先保护入口。
限流排队页令牌防刷异步下单
秒杀不再追求所有请求进系统，而是让有效用户有序进入。
生产版
活动作战平台
多场活动、黑产、支付超时和客服补偿进入日常。
活动配置库存同步风控监控大盘应急开关
生产秒杀系统要可预演、可观测、可止损。
最简单的三层架构，直接访问数据库
用户层
用户请求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
课程简介
系统总览
秒杀系统总览
把流量削峰、库存扣减、异步下单和防刷治理拆成可控链路。
入口
活动页
答题/验证码
限流
库存
Redis 扣减
队列串行化
最终校准
订单
异步创建
支付超时
风控拦截
秒杀系统是高并发系统设计里最典型的场景之一：短时间内大量用户争抢有限库存，系统既不能超卖，也不能让核心链路被流量打垮。真正困难的不是“扣库存”这一行代码，而是如何在流量洪峰、库存一致性、用户体验、防刷和下单可靠性之间做取舍。
这门课从一次限量抢购活动开始，逐步构建一套可上线的秒杀系统。
学习路线
- 秒杀系统概述：理解秒杀活动的业务目标、流量特征和核心风险。
- 特性分析：拆解瞬时高并发、库存稀缺、防刷和下单链路。
- 数据库锁方案：从悲观锁、乐观锁看第一版防超卖设计的边界。
- Redis 队列方案：把库存扣减前置到内存，并通过队列串行化下单。
- 限流削峰：使用令牌桶、排队、答题门槛等方式保护核心链路。
- 库存同步：处理 Redis 库存、数据库库存、订单状态之间的一致性。
- 防刷风控：识别脚本、黑产账号和异常设备，减少无效流量。
- 完整系统：总结最终架构、关键决策和上线检查清单。
读完后，你应该能解释秒杀系统为什么要把“流量进入、资格校验、库存扣减、订单创建、支付确认”拆成不同阶段，并能判断每一阶段需要强一致还是最终一致。
第一章 / CHAPTER 01