RocketMQNotes

第 21 章：容量规划

zjc 于 2026-01-21 发布

这是《RocketMQ 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 容量规划是把“业务量”翻译成“机器、磁盘、网络、队列、线程和人员流程”的过程。RocketMQ 集群出问题，常见原因不是峰值 TPS 本身，而是保留时间、消费落后、重试风暴和冷读查询没有被纳入模型。

21.1 输入指标

规划前先收集：

指标 说明
peak TPS 分钟或秒级峰值
message size 平均值和 P99
consumer lag 正常和异常峰值
retention 数据保留时间
topic count Topic 和队列数量
burst factor 促销、重试、重放
recovery window 故障恢复时间
replica count 副本数
query load 消息查询和轨迹

不要只用日均值规划。消息系统容量通常被峰值、尾部延迟和故障恢复场景压垮。

21.2 写入容量

估算：

write throughput = peak tps × avg message size × replica count
daily bytes = average bytes per second × time
disk required = daily bytes × retention days × expansion factor

示例：

peak tps = 20,000 msg/s
avg size = 1 KiB
replicas = 2
write throughput = 40 MiB/s

还要叠加：

  1. 网络协议开销；
  2. 索引开销；
  3. 轨迹消息；
  4. 重试消息；
  5. 峰值持续时间；
  6. 磁盘写入放大。

21.3 磁盘容量

磁盘水位建议：

水位 动作
60% 关注增长趋势
70% 评估扩容或治理
80% 高优处理
90% 冻结非关键变更，启动预案
拒写水位 保护数据一致性

预留空间要覆盖：

  1. 最长消费积压周期；
  2. 磁盘故障恢复时间；
  3. 备份和迁移窗口；
  4. 突发流量；
  5. 系统文件和日志；
  6. 轨迹与死信；
  7. 一个可控告警响应周期。

21.4 队列与消费并行度

估算：

required consumers = target tps / per-consumer tps
queues >= consumer instances × useful parallelism

示例：

target = 8,000 msg/s
one consumer instance = 1,000 msg/s
instances = 8
queues = 16 or 32

如果单条消息依赖数据库事务，消费能力通常先到数据库连接池或下游 RPC 上限，而不是客户端线程上限。

21.5 网络容量

单条消息产生的流量不止 body：

client -> broker request
broker -> replica replication
broker -> consumer delivery
consumer -> broker ack
metrics and trace

规划：

  1. 生产带宽；
  2. 复制带宽；
  3. 消费带宽；
  4. 跨可用区带宽；
  5. 备份带宽；
  6. 管理和查询流量。

跨机房同步副本时，网络延迟直接影响同步复制写入延迟。

21.6 高可用余量

N+1 原则示例：

normal load = 60% capacity
one broker down = remaining can hold 100% peak

需要验证：

  1. 剩余磁盘增长速度；
  2. 剩余 Broker 写入延迟；
  3. 副本数量是否下降；
  4. 消费者是否重平衡；
  5. 故障恢复窗口；
  6. Controller 仲裁是否健康。

21.7 多租户隔离

不同业务风险不同：

级别 示例 策略
核心 支付、订单 独立集群或独立 Broker 组
重要 用户通知 配额和优先级
普通 行为日志 采样、限流、低成本盘
批量 重放、补偿 独立窗口和限速

至少要做到：

  1. Topic 配额；
  2. 消息大小限制；
  3. 消费组隔离；
  4. 重试风暴熔断；
  5. 查询限流；
  6. 关键业务不与批处理混部。

21.8 压测模型

压测场景：

  1. 峰值写入；
  2. 峰值消费；
  3. 写读混合；
  4. 冷查询；
  5. 重试风暴；
  6. Broker 故障；
  7. 磁盘高水位；
  8. 消费者重平衡；
  9. 长时间稳定性。

记录结果：

tps
p95 / p99 latency
disk throughput
network throughput
cpu usage
page cache behavior
lag recovery time
error rate

压测数据要保留，作为容量模型修正依据。

21.9 容量评审清单

  1. 峰值 TPS 和消息大小；
  2. 保留时间与最大 lag；
  3. 副本和跨可用区拓扑；
  4. 队列数与消费并行度；
  5. 磁盘和网络余量；
  6. 轨迹、重试、死信、系统 Topic；
  7. 备份和迁移窗口；
  8. 多租户隔离；
  9. 故障演练结果；
  10. 扩容触发条件。

本章小结

容量规划要把业务峰值、消息大小、保留时间、副本数、消费能力、重试流量、查询负载和故障恢复窗口全部纳入模型。磁盘不是唯一指标，队列数、网络、下游数据库和多租户隔离同样关键。模型必须通过压测和真实流量持续修正。

思考题

  1. 为什么日均值不适合作为唯一容量依据？
  2. 副本数如何影响磁盘和网络？
  3. 消费者数量为什么常受下游限制？
  4. 重试风暴如何纳入容量模型？
  5. N+1 余量如何验证？