这是 Beta 探索课程,内容结构、实验步骤和示例可能会继续调整。
关键决策:设计过程中的关键决策点
设计就是做选择 🎯
在设计秒杀系统的过程中,我们遇到了无数个选择题。有些选择看似微小,却可能影响整个系统的命运。
今天,让我们一起回顾那些关键决策点,看看我们为什么这样选,以及有没有更好的选择。
决策 1:库存放在哪里?📦
问题
决策分析
| 维度 | MySQL | Redis | MySQL+Redis |
|---|---|---|---|
| 读取性能 | 1000 QPS | 100,000 QPS | 100,000 QPS |
| 写入性能 | 500 QPS | 50,000 QPS | 50,000 QPS |
| 数据可靠性 | ★★★★★ | ★★★☆☆ | ★★★★☆ |
| 实现复杂度 | ★☆☆☆☆ | ★★☆☆☆ | ★★★★☆ |
| 一致性保证 | 强一致 | 最终一致 | 最终一致 |
我们的选择:Redis 为主,MySQL 为辅 ✅
如果重来,会改变吗?
不会改变。这个方案在性能和可靠性之间取得了最佳平衡。对于秒杀场景,性能是第一位的,而通过异步对账可以弥补 Redis 的可靠性问题。
决策 2:如何防止超卖?🛡️
问题
决策分析
| 方案 | 性能 | 一致性 | 实现复杂度 | 适用场景 |
|---|---|---|---|---|
| 悲观锁 | ★☆☆☆☆ | ★★★★★ | ★★☆☆☆ | 低并发 |
| 乐观锁 | ★★★☆☆ | ★★★★☆ | ★☆☆☆☆ | 中低并发 |
| Redis 原子 | ★★★★★ | ★★★☆☆ | ★★☆☆☆ | 高并发 |
| Lua 脚本 | ★★★★★ | ★★★★☆ | ★★★☆☆ | 超高并发 |
我们的选择:Redis Lua 脚本 ✅
如果重来,会改变吗?
不会改变。Lua 脚本是防超卖的最佳实践,已经被业界广泛验证。
决策 3:同步下单还是异步下单?🔄
问题
决策分析
| 方案 | 响应时间 | 并发能力 | 用户体验 | 实现复杂度 |
|---|---|---|---|---|
| 同步下单 | 500ms+ | 1000 QPS | ★★★★★ | ★☆☆☆☆ |
| 异步下单 | 50ms | 50,000 QPS | ★★★☆☆ | ★★☆☆☆ |
| 混合模式 | 100ms | 30,000 QPS | ★★★★☆ | ★★★★☆ |
我们的选择:混合模式 ✅
如果重来,会改变吗?
不会改变。混合模式是电商行业的标准做法,淘宝、京东都是这样做的。
决策 4:如何限流?🚦
问题
决策分析
| 方案 | 性能影响 | 灵活性 | 配置复杂度 | 防护效果 |
|---|---|---|---|---|
| Nginx 限流 | ★☆☆☆☆ | ★★☆☆☆ | ★☆☆☆☆ | ★★★☆☆ |
| 网关限流 | ★★☆☆☆ | ★★★★☆ | ★★☆☆☆ | ★★★★☆ |
| 服务层限流 | ★★★☆☆ | ★★★★★ | ★★★☆☆ | ★★★★☆ |
| 多层限流 | ★★★★☆ | ★★★★★ | ★★★★★ | ★★★★★ |
我们的选择:多层限流 ✅
如果重来,会改变吗?
不会改变。多层限流虽然配置复杂,但在高并发场景下是必不可少的。每一层都有不同的职责,形成纵深防御。
决策 5:缓存策略怎么选?💾
问题
决策分析
| 方案 | 读性能 | 写性能 | 一致性 | 成本 |
|---|---|---|---|---|
| 单层 Redis | 5ms | 5ms | ★★★★☆ | 中 |
| 多级缓存 | 1ms | 10ms | ★★★☆☆ | 低 |
| 只本地缓存 | 0.1ms | 0.1ms | ★☆☆☆☆ | 最低 |
我们的选择:多级缓存 ✅
如果重来,会改变吗?
基本不会改变。多级缓存是高性能系统的标配。但如果数据一致性要求极高,可能需要考虑使用 Redis 单层的方案。
决策 6:反欺诈做到什么程度?🔍
问题
决策分析
| 方案 | 开发成本 | 运维成本 | 识别率 | 误杀率 |
|---|---|---|---|---|
| 基础 | 1 周 | 低 | 50% | < 0.1% |
| 进阶 | 1 月 | 中 | 80% | < 0.5% |
| 深度 | 3 月+ | 高 | 95% | < 1% |
我们的选择:进阶反欺诈 ✅
如果重来,会改变吗?
可能会调整。如果预算充足,可以直接上深度反欺诈。但如果资源有限,进阶方案是最佳起点。
决策对比总表 📊
想一想
问题 1:如果预算只有现在的 1/10,哪些决策需要改变?
点击查看答案
精简方案:
- 库存存储:只用 Redis(去掉 MySQL 实时同步)
- 限流策略:只用 Nginx 限流
- 缓存策略:只用 Redis(去掉本地缓存)
- 反欺诈:只用基础方案(限流 + 验证码)
- 服务器:全部减半,用更低配置
核心原则:保证核心功能(库存扣减),砍掉辅助功能
问题 2:如果流量是现在的 10 倍,哪些决策需要改变?
点击查看答案
升级方案:
- 库存存储:Redis 集群扩容,增加分片
- 下单模式:更激进的异步,同步只返回令牌
- 限流策略:更严格,提前拦截
- 缓存策略:增加 L0 缓存(CPU 缓存级别)
- 反欺诈:上机器学习模型,提前识别
核心原则:用空间换时间,用预处理换实时性能
问题 3:这些决策中,哪个最可能后悔?
点击查看答案
可能后悔的:
- 多级缓存的一致性维护(容易出 bug)
- 混合下单模式的用户通知(容易遗漏)
- 反欺诈的误杀处理(用户投诉)
建议:
- 做好监控和告警
- 建立快速回滚机制
- 准备应急预案