容量规划与性能分析

根据实测存储数据量、流入、消费完成、保留期和故障恢复需求规划容量。区分可持续吞吐与仅被内存、页缓存暂时吸收的短时突发。本文提供计算方法，算术示例不是性能测试结果。

按 Broker 组计算存储

定义：

变量	含义
λ	该 Broker 组持续接纳的每秒消息数
s	实测单条消息平均存储字节数，含编码开销与实际压缩效果
T	保留期，单位秒
R	该组完整副本数
Dextra	每个副本额外的索引、元数据、重试/DLQ/定时状态及运行日志，不重复计入 λ × s
H	每个副本为增长、清理延迟、恢复和维护预留的空间

每个副本保留的主数据近似为 Dlog = λ × s × T。每个副本至少按估算的 Dlog + Dextra + H 配置空间，并分别考虑拆分的文件系统。整个组的完整副本存储约为 R × (Dlog + Dextra + H)。按各 Broker 组实际流量分配容量，不能假定平均分布。

假设 1,000 条/秒、每条存储 1,000 字节、保留一天，则每个副本的 Dlog = 86.4 GB，这里使用十进制单位。三个副本的主数据共 259.2 GB，尚未包含额外状态和余量。这是假设输入，不代表受支持的吞吐或建议保留期。

在有代表性的时间内测量实际分段增长。系统主题、重试、延迟流量、大量属性和压缩比都会改变存储量。实测增长已包含系统流量时不要重复计算。分段预分配和清理会让实际磁盘用量不同于有效正文大小。

RocksDB 存储的元数据仍伴随本地 CommitLog。分层存储是另一个具有提供者、恢复约束的次级路径，选择它不会自动消除本地容量需求。见存储后端。

计算追平能力

积压为 B 条、当前流入为 λ、持续消费完成速率为 μ 时，只有 μ > λ，理想追平时间才为 B / (μ − λ)。若 μ ≤ λ，相同条件下积压不会消除。

假设积压一千万条，λ = 3,000/s、μ = 5,000/s，理想追平时间为 5,000 秒，约 83 分钟。还需考虑重试、再平衡、下游限流和热点队列。总容量充足不能解决某个串行顺序队列自身消费速率低于流入的问题。

检查整个追平过程中，保留期是否仍覆盖最早需要的数据。算得出追平时间不能恢复已经删除的分段。副本追平同样与实时流量争用磁盘、网络，并可能影响同步写入。

计算内存与网络

内存取决于保留的工作：在途发送、编码缓冲、消费批次、业务队列、响应流、缓存和运行时任务。消息大小差异很大时，只限制数量不够。在 API 支持时，同时限制并发与保留字节数。

将进程常驻内存与操作系统页缓存、容器内存记账结合观察。内存映射存储不代表全部数据驻留，应用堆较小也不代表总内存需求低。

网络容量应包含流入正文、协议开销、复制、消费流出、重试、路由/控制流量和追平。Proxy 增加一跳，并有自己的接纳和流保留开销。TLS、压缩会改变 CPU 成本，应测量实际选中的路径。

定位限制阶段

观察结果	调查方向	首个受控调整
客户端发起请求前等待	生产背压、应用并发、运行时/阻塞预算	限制未完成工作，对比排队等待与远端延迟
磁盘压力伴随追加/刷盘延迟上升	CommitLog 设备服务时间、刷盘策略、其他写入争用	消除争用或提供足够设备能力
HA ACK 延迟或复制落后增长	副本磁盘/网络、同步集合与写权限	恢复副本进度，保持所需持久性约定
消费者 CPU 忙	解码、过滤、业务计算和热点队列	优化实测热点，在顺序允许时划分工作
消费者主要等待下游 I/O	数据库/API 容量与处理并发	将有界并发调整到下游可承受范围
Proxy 拒绝请求或保留大量流	接纳限制、保留字节数、慢客户端/下游	先降低积压、定位阻塞的一跳，再决定是否提高限制

通过监控关联这些结果。把所有线程数、队列限制一并调高，往往只是把等待转移到内存，并不增加完成量。

执行可比较的负载

1. 固定场景：客户端模式、消息分布、正文/属性大小、队列/组数量、顺序、过滤、TLS、存储后端、刷盘与复制策略。
2. 记录软件/构建 feature、机器、存储设备、文件系统、网络、容器限制和背景负载。测量服务容量时，避免负载发生器争用服务关键资源。
3. 使用隔离主题、组。预热目标路径后，测量足够长的时间，覆盖刷盘、稳定资源使用、消费推进和相关维护活动。
4. 统计发送尝试、按状态区分的接纳结果、错误/超时、唯一业务完成、重复与剩余积压。报告延迟分位数和观察时长，不只报告发送调用平均耗时。
5. 每次修改一个因素，重复相同负载，对比完成量、尾延迟、持久性、错误与资源增长。

批处理可摊薄单次请求成本，提高 max_message_size 仅改变大小限制。压缩以 CPU 换取字节减少，效果取决于内容可压缩性。只有队列、工作可并行分配且下游跟得上时，增加消费者才有帮助。使用当前生产者、消费者 API，不使用缺少运行时接入的旧构造方式。

把 SYNC_FLUSH 改为 ASYNC_FLUSH，或降低副本要求，会改变写入成功的含义。应把这种变化作为负载条件报告，不能视为无代价提速。Linux sendfile、io_uring 和加载 feature 受编译与运行期条件约束；把结果归因于它们之前，检查实际引擎与回退观察。

保留策略与操作余量

检查实际存储设置，包括 fileReservedTime、deleteWhen、磁盘压力阈值和已启用的清理行为。保留期不承诺无限保留所有未消费消息；磁盘压力清理与分段回收条件会影响实际保留区间。

为备份目标、升级和临时合并副本单独预留空间。缩短保留期可能永久移除可重放数据。磁盘达到临界状态前，明确容量应对措施：限制流入、恢复消费、扩展受支持存储，或评估业务恢复需求后有意调整保留策略。

源码索引

存储配置、本地清理、存储性能观察、Proxy 运行限制。