Skip to content

容量规划

本页结论:容量规划先算三笔账——存储(峰值速率 × 保留期 × 副本数)、吞吐余量(≥ 峰值的 2 倍)、积压预算(允许积压多久决定消费者下限),再按各产品的扩容路径(分区/队列/消费者关系)决定扩容动作。本仓库所有实验数字都是单机学习环境的结果,不得当作生产基准;任何压测报告必须按规格 §12.4 记录完整环境,标题只能是「该固定环境下的实验结果」,不做产品性能排名。

第一笔账:存储容量

text
日消息量   = 峰值 msg/s × 86400
日存储量   = 日消息量 × 平均消息大小
总存储     = 日存储量 × 保留期(天) × 副本数 × 冗余系数(≥1.2)

示例(仅示意算法):峰值 5,000 msg/s、平均 1 KB、保留 7 天、3 副本:

text
5,000 × 86,400 ≈ 4.32 亿条/天 × 1 KB ≈ 0.4 TB/天
0.4 TB × 7 天 × 3 副本 × 1.2 ≈ 10 TB 磁盘预算

注意:

  • 峰值而不是均值:按日均值规划的系统必然在大促/活动日写满磁盘。
  • 副本数不是浪费:它是可靠性配置的一部分(Kafka replication factor、Pulsar 副本/写 ack 配置、RabbitMQ quorum 复制),减副本换容量是在拿数据安全换空间。
  • 存储型系统(Kafka/RocketMQ/Pulsar)按保留期计;队列型(RabbitMQ)正常情况队列接近空,积压时可能瞬时吞掉全部内存/磁盘——两者都要设水位(见故障剧本)。

第二笔账:吞吐余量与积压预算

  • 吞吐余量:Broker 与消费者的能力按 ≥ 2 倍峰值规划。消费者追赶积压时,消费速率必须同时覆盖「当前生产 + 消化存量」,没有余量就永远追不上。
  • 积压预算:业务能容忍峰值流量积压多久(T 分钟)?则消费者下限为:
text
所需消费速率 ≥ 峰值速率 × (1 + 积压消化要求)
例:峰值 5,000 msg/s,要求 10 分钟内消化一次 5 分钟的完全停摆积压
    → 需要额外 5,000 × 300 / 600 = 2,500 msg/s 的余量

积压预算直接转化为可观测性里的告警阈值:mq_backlog 超过预算即告警。

第三笔账:消费者扩容路径(四产品不同)

产品并行度单位扩容路径先扩谁
RabbitMQ队列上的消费者数加消费者实例;单队列到顶后拆分队列/用一致性哈希 exchange 分片先加消费者,再拆队列
Kafka分区组内消费者 ≤ 分区数才有效;不够则先加分区(注意分区变更影响顺序与再均衡成本)先确认分区数,再加消费者
RocketMQmessage queue与 Kafka 类似:队列数限制组内并行度同上
Pulsar订阅类型 + 分区Shared/Key_Shared 订阅可多消费者;单 topic 到顶后改分区 topic先看订阅类型,再看分区

共性结论:「加消费者」不一定能扩容。Kafka/RocketMQ 受分区/队列数约束(见工作队列的分发形状一节),扩容方案要先回答并行度单位够不够。

压测记录规范(规格 §12.4)

任何性能结果必须完整记录以下要素,缺一项都不得作为容量依据:

  • 环境:CPU、内存、磁盘类型(HDD/SSD/NVMe 与文件系统)、操作系统、Docker 版本;
  • 版本与配置:Broker/客户端版本、完整关键配置(副本数、acks/确认级别、刷盘与持久化条件、压缩、批大小、消息大小);
  • 拓扑:节点数、分区/队列数、生产者/消费者数;
  • 方法:热身时间、测试时长、P50/P95/P99、错误率;
  • 干扰项:是否发生 GC、页缓存升温、磁盘写满或限流。

两条红线:

  1. 报告标题必须是「该固定环境下的实验结果」,不得使用「产品绝对性能排名」式表述——不同环境下的数字不可比,排名没有意义。
  2. 不把单机 Demo 数字当生产基准。本仓库实验(见实验室)运行在单节点 Docker、无认证、小数据量条件下,其价值是验证语义与失败模式(证据等级 E2,见证据政策),不是吞吐能力证明。

常见误区

  • 「Demo 里跑到 10 万 msg/s,生产照这个规划」——Demo 环境无副本、无 TLS、消息极小、页缓存全热,与生产形状完全不同。
  • 「积压了先加消费者」——并行度单位(分区/队列)不够时加了也无效;先走积压决策树
  • 「磁盘按当前用量规划」——保留期 × 副本数的乘法效应和峰值突增都会击穿「当前用量」外推。

官方资料

以统一实验验证消息系统语义边界