关键决策:设计过程中的关键决策点

设计就是做选择 🎯

在设计秒杀系统的过程中,我们遇到了无数个选择题。有些选择看似微小,却可能影响整个系统的命运。

今天,让我们一起回顾那些关键决策点,看看我们为什么这样选,以及有没有更好的选择。


决策 1:库存放在哪里?📦

问题

决策分析

维度MySQLRedisMySQL+Redis
读取性能1000 QPS100,000 QPS100,000 QPS
写入性能500 QPS50,000 QPS50,000 QPS
数据可靠性★★★★★★★★☆☆★★★★☆
实现复杂度★☆☆☆☆★★☆☆☆★★★★☆
一致性保证强一致最终一致最终一致

我们的选择:Redis 为主,MySQL 为辅 ✅

如果重来,会改变吗?

不会改变。这个方案在性能和可靠性之间取得了最佳平衡。对于秒杀场景,性能是第一位的,而通过异步对账可以弥补 Redis 的可靠性问题。


决策 2:如何防止超卖?🛡️

问题

决策分析

方案性能一致性实现复杂度适用场景
悲观锁★☆☆☆☆★★★★★★★☆☆☆低并发
乐观锁★★★☆☆★★★★☆★☆☆☆☆中低并发
Redis 原子★★★★★★★★☆☆★★☆☆☆高并发
Lua 脚本★★★★★★★★★☆★★★☆☆超高并发

我们的选择:Redis Lua 脚本 ✅

如果重来,会改变吗?

不会改变。Lua 脚本是防超卖的最佳实践,已经被业界广泛验证。


决策 3:同步下单还是异步下单?🔄

问题

决策分析

方案响应时间并发能力用户体验实现复杂度
同步下单500ms+1000 QPS★★★★★★☆☆☆☆
异步下单50ms50,000 QPS★★★☆☆★★☆☆☆
混合模式100ms30,000 QPS★★★★☆★★★★☆

我们的选择:混合模式 ✅

如果重来,会改变吗?

不会改变。混合模式是电商行业的标准做法,淘宝、京东都是这样做的。


决策 4:如何限流?🚦

问题

决策分析

方案性能影响灵活性配置复杂度防护效果
Nginx 限流★☆☆☆☆★★☆☆☆★☆☆☆☆★★★☆☆
网关限流★★☆☆☆★★★★☆★★☆☆☆★★★★☆
服务层限流★★★☆☆★★★★★★★★☆☆★★★★☆
多层限流★★★★☆★★★★★★★★★★★★★★★

我们的选择:多层限流 ✅

如果重来,会改变吗?

不会改变。多层限流虽然配置复杂,但在高并发场景下是必不可少的。每一层都有不同的职责,形成纵深防御。


决策 5:缓存策略怎么选?💾

问题

决策分析

方案读性能写性能一致性成本
单层 Redis5ms5ms★★★★☆
多级缓存1ms10ms★★★☆☆
只本地缓存0.1ms0.1ms★☆☆☆☆最低

我们的选择:多级缓存 ✅

如果重来,会改变吗?

基本不会改变。多级缓存是高性能系统的标配。但如果数据一致性要求极高,可能需要考虑使用 Redis 单层的方案。


决策 6:反欺诈做到什么程度?🔍

问题

决策分析

方案开发成本运维成本识别率误杀率
基础1 周50%< 0.1%
进阶1 月80%< 0.5%
深度3 月+95%< 1%

我们的选择:进阶反欺诈 ✅

如果重来,会改变吗?

可能会调整。如果预算充足,可以直接上深度反欺诈。但如果资源有限,进阶方案是最佳起点。


决策对比总表 📊


想一想

问题 1:如果预算只有现在的 1/10,哪些决策需要改变?

点击查看答案

精简方案:

  1. 库存存储:只用 Redis(去掉 MySQL 实时同步)
  2. 限流策略:只用 Nginx 限流
  3. 缓存策略:只用 Redis(去掉本地缓存)
  4. 反欺诈:只用基础方案(限流 + 验证码)
  5. 服务器:全部减半,用更低配置

核心原则:保证核心功能(库存扣减),砍掉辅助功能

问题 2:如果流量是现在的 10 倍,哪些决策需要改变?

点击查看答案

升级方案:

  1. 库存存储:Redis 集群扩容,增加分片
  2. 下单模式:更激进的异步,同步只返回令牌
  3. 限流策略:更严格,提前拦截
  4. 缓存策略:增加 L0 缓存(CPU 缓存级别)
  5. 反欺诈:上机器学习模型,提前识别

核心原则:用空间换时间,用预处理换实时性能

问题 3:这些决策中,哪个最可能后悔?

点击查看答案

可能后悔的:

  1. 多级缓存的一致性维护(容易出 bug)
  2. 混合下单模式的用户通知(容易遗漏)
  3. 反欺诈的误杀处理(用户投诉)

建议:

  • 做好监控和告警
  • 建立快速回滚机制
  • 准备应急预案