这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
业务特点：秒杀业务的独特特点和挑战
场景：双十一零点的狂欢 🎉
想象一下这个场景：
2024年11月11日 00:00:00
你正在参加天猫双十一秒杀活动，准备抢购一台原价5999元、秒杀价2999元的iPhone 15 Pro。
你的准备：
- 📱 双手紧握手机
- 👆 手指悬停在”立即抢购”按钮上
- ⏰ 眼睛盯着倒计时：00:00:03… 00:00:02… 00:00:01…
- 💪 肌肉紧绷，准备点击
系统面临的挑战：
输出结果：
📊 秒杀流量特征：
平时 QPS: 1,000
秒杀 QPS: 500,000
流量激增: 500倍
时间集中: 几秒钟内
用户集中: 同一商品
🔥 服务器压力：
正常情况: 10 台服务器
秒杀需要: 5000 台服务器
成本增加: 500.0倍
⚠️ 现实问题：
不能为了几秒钟的秒杀，准备500倍的服务器！
成本太高，资源浪费严重！秒杀业务的核心特点
1. ⚡ 瞬时高并发
秒杀最显著的特点就是瞬时流量激增：
流量对比表：
| 时间点 | 正常业务 QPS | 秒杀业务 QPS | 倍数 |
|---|---|---|---|
| 10:00 | 1,000 | 1,000 | 1x |
| 10:05 | 1,200 | 1,000 | 1x |
| 10:09 | 1,100 | 50,000 | 45x |
| 10:09:30 | 1,000 | 500,000 | 500x |
| 10:10:00 | 1,100 | 500,000 | 455x |
| 10:10:10 | 1,200 | 250,000 | 208x |
2. 📦 库存有限且热点集中
秒杀商品的库存通常很少，但关注度极高：
库存竞争示意：
用户请求队列：
[用户1] → [用户2] → [用户3] → ... → [用户500000]
↓
数据库行锁 🔒
↓
[库存: 100] ← 同一行记录被所有人竞争
↓
串行更新，一次只能一个人改3. ⏰ 时间限制严格
秒杀有严格的开始和结束时间：
4. 🎯 结果确定性强
秒杀结果只有两种：成功或失败，没有中间状态：
与普通电商的对比
让我们对比秒杀和普通电商的区别：
| 维度 | 普通电商 | 秒杀活动 | 差异程度 |
|---|---|---|---|
| 流量特征 | 平稳波动 | 瞬时暴增500倍 | 🔥🔥🔥 |
| 库存热点 | 分散到多个商品 | 集中在少量商品 | 🔥🔥🔥 |
| 并发量 | QPS 1000-5000 | QPS 50万-100万 | 🔥🔥🔥 |
| 持续时间 | 全天24小时 | 几秒到几分钟 | 🔥🔥🔥 |
| 用户耐心 | 几秒到几分钟 | 必须即时响应 | 🔥🔥 |
| 一致性要求 | 最终一致 | 强一致不能超卖 | 🔥🔥🔥 |
| 可降级性 | 部分功能可降级 | 核心功能不能降级 | 🔥🔥 |
| 技术难度 | 常规缓存+负载均衡 | 专用架构+特殊优化 | 🔥🔥🔥 |
真实案例分析
让我们看几个真实的秒杀案例：
想一想
在继续学习之前，请思考以下问题：
问题 1：流量激增500倍怎么办？
如果平时QPS是1000，秒杀时达到50万QPS，你会如何应对？
提示：
- 能否增加500倍的服务器？
- 如何利用现有的资源？
- 有没有办法”削峰填谷”？
问题 2：库存热点如何解决？
50万人抢购100台手机，都访问同一条库存记录，数据库怎么办？
提示：
- 数据库行锁是串行的
- 能否把压力转移？
- 如何保证不超卖？
问题 3：如何保证公平性？
如何确保所有用户在同一时间开始抢购，没有人能作弊？
提示：
- 时间同步问题
- 提前知道库存信息
- 如何防止脚本抢购？