极限场景处理
2019 年双十一，某电商公司的秒杀系统在零点零分被流量冲垮。故障持续了 47 分钟，直接损失超过 800 万元。事后复盘发现，峰值流量是平时的 300 倍，而系统在 50 万 QPS 时就已经开始雪崩。
这家公司不是技术不行——他们的日常系统跑得很稳。只是秒杀和日常运营是完全不同的战场，日常的「够用」到了秒杀就是「灾难」。
极限场景的核心矛盾在于：业务价值极高（一次秒杀活动可能带来数亿GMV），但技术代价极大。不是所有系统都需要设计成这样，但一旦需要，必须理解每个决策的代价。
四类极限场景的核心矛盾
极限场景不是一个模糊的概念，它背后对应着四种不同的技术矛盾。理解矛盾，才能知道设计重点在哪里：
学习路径
路径一：按问题深度递进（推荐）
如果你之前没有完整设计过极限场景，按这个顺序阅读：
- 秒杀系统：先理解最简单的高并发场景——准点抢、单库存、库存清零即结束。这个场景的逻辑最清晰，适合建立感觉。
- 高并发抢购：在秒杀基础上加入公平性要求（一人一号一单）、实时库存可见、持续时间更长等变量，复杂度上升一个台阶。
- 海量数据处理：从「单次请求」切换到「持续数据流」，理解数据平台如何用分层架构在成本和性能之间找平衡。
- 跨机房多活：理解高可用的终态——不只是「别宕机」，而是「任何单点故障都不影响用户」，这是成本最高的设计。
路径二：按业务需求切入
- 电商促销、限量活动 → 秒杀系统 + 高并发抢购
- 日志平台、数据分析 → 海量数据处理
- 金融、医疗、核心交易系统 → 跨机房多活
四篇文章的统一结构
每篇文章都遵循「问题 → 方案 → 代价 → 决策」的逻辑链，不会只讲「怎么设计」，更会讲「什么情况下不该这样设计」：
- 业务背景：这个场景为什么会产生，技术挑战的核心在哪
- 方案演进：从最简方案到生产方案的逐步改进，展示踩坑过程
- 关键代码：核心逻辑的完整实现，不是碎片化代码
- 真实代价：超时机制、数据一致性、性能拐点……这些是真正让架构师头疼的东西
- 决策边界：什么场景适合这样设计，什么场景是过度设计
这四篇文章能帮你回答什么
秒杀系统能帮你回答：如何用 Redis 原子扣减解决库存超卖？为什么不能把库存扣减放在数据库里做？多层限流的颗粒度怎么控制？
高并发抢购能帮你回答：公平性和性能如何平衡？分布式锁 vs Redis 原子扣减各自适用于什么场景？为什么队列机制会引入额外延迟？
海量数据处理能帮你回答：ODS → DWD → DWS → ADS 每层解决什么问题？为什么 ClickHouse 比 MySQL 快 100 倍却依然不够？预聚合和实时计算哪个更划算？
跨机房多活能帮你回答：冷备、热备、同城双活、异地多活怎么选？单元化架构的代价是什么？为什么 CAP 理论在这里是活的？RTO 和 RPO 到底意味着多少数据丢失？
正式开始之前
在开始之前，需要明确一个前提：极限场景的成本极高，不是所有系统都需要设计成这样。
这四篇文章的定位是帮助你理解原理和代价，具体落地时一定要根据业务的真实需求和投入产出比来决策。
准备好了？让我们从秒杀系统开始——这是互联网公司最容易踩坑、也最需要系统化设计的场景。