削峰填谷：MQ 的第一性原理
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 3 · 异步与消息 · 第 16/49 篇 · 🚧 占位待学
上一篇：《同步链路的天花板：级联失败与延迟叠加》
下一篇：《亿级消息存储模型：CommitLog、零拷贝与页缓存》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 3 · 单元 3.2
一、本文要解决的问题
秒杀洪峰 10 万 QPS 持续 5 秒，数据库只能接 5000——中间需要一个蓄水池把瞬时洪峰摊平成匀速水流。这就是 MQ 的第一性原理：它不是「传消息的」，是「把时间维度上的流量重新分配」的。
二、知识点清单
- 削峰的数学：洪峰面积（∫QPS dt）、消费能力、排队深度 = 洪峰面积 − 已消费，最长等待 = 深度 ÷ 消费速率
- 用户体验设计：同步受理（返回受理号）+ 异步履约（轮询 / 推送结果），202 Accepted 的语义
- 消息可靠性三环节：发送端确认（失败重试）、Broker 持久化（刷盘）、消费端 ack（失败重投）
- 同步改异步后的状态机：受理中 → 已处理 / 已失败，状态查询接口的设计
- 削峰的副作用：用户等待、消息堆积（3.5 展开）、顺序与幂等（3.4 展开）
三、动手实验（学习时必须真跑）
- 写秒杀下单 demo 版本一：请求直接写库，wrk 压 5000 QPS 观察数据库崩溃
- 版本二：请求入 RocketMQ，消费者以 2000/s 匀速消费落库，重压测对比 DB 的 QPS 曲线（洪峰变平顶）
- 实测记录：排队深度变化、用户最长等待时间，与理论公式对比
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。