初始场景：
生产者非常多、消费者非常少，核心问题不是“怎么消费得更快”，而是 怎么高吞吐接住写入，以及怎么处理持续积压。
- 多 Broker：单机写入扛不住大量生产者 → Broker 水平扩容，把写压力分散到多台机器
- 多 Partition：单个 Topic 单分区吞吐有限 → 拆多个 Partition，让不同分区并行写入
- 顺序日志：大量随机写磁盘效率低 → 每个 Partition 采用 append-only 顺序写
- 批量写 / 刷盘：每条消息单独落盘开销太大 → 批量聚合后写入，提高吞吐
- 消息积压：生产速度明显高于消费速度 → MQ 依靠磁盘持久化先把消息存下来，消费者按自身速度慢慢拉
- 容量规划：持续积压最终会把磁盘写满 → 扩容 Broker / 磁盘，并设置明确的保留策略
- 保留策略：磁盘满了以后必须决定保谁 → 消息不能丢就扩容或拒绝新写；允许丢历史则按时间/容量淘汰旧消息
- 系统边界：消费者只有一个，而且长期
生产速率 > 消费速率→ 无论 MQ 怎么设计，积压最终都会持续增长，只能延缓，不能根治
最后主线就是：
大量生产者 → Broker 水平扩容 → Partition 分散写入 → 顺序日志高吞吐 → 磁盘承接积压 → 容量/保留策略兜底 → 明确单消费者的吞吐上限。