大促期间，队列里有多少条消息只是表象：同样是几十万条，几百字的通知和数百 KB 的文件索引，对存储、网络与消费时间的压力并不相同。云端消息队列服务的容量规划，应先回答三个问题：消息以多快速度进入、消费者能处理多少、峰值过后多久必须清空。
先算积压会增长多少
记录平常流量和大促峰值的消息到达速率（条/秒），再测消费者在真实业务逻辑下的处理速率。若到达速率持续高于处理速率，积压就会增长。可用这个估算式：积压条数≈（峰值到达速率－同期处理速率）×持续秒数。若消费者处理能力高于到达速率，积压则可逐步消退。
例如，假设某次峰值持续20分钟，到达速率为每秒1200条，消费者合计每秒处理900条，则峰值期间新增积压约36万条。峰值结束后，如果到达降至每秒500条、处理能力仍是每秒900条，清空这批积压约需15分钟。这里的数字仅用于演示；实际处理速率会受消息逻辑、下游服务、批量拉取和重试影响，应以压测或生产监测数据替换。
容量不只有消息条数
| 指标 | 怎么估算或检查 | 规划时的意义 |
|---|---|---|
| 积压时长与条数 | 按分钟观察新增、消费和未处理消息 | 判断能否在业务允许时间内恢复 |
| 消息大小 | 统计平均值及较大消息所占比例 | 估算存储、传输和处理开销 |
| 消息保留期 | 核对未消费消息允许保留多久 | 避免积压超过服务的保留或存储限制 |
| 消费者并发 | 测量增加消费者后吞吐是否继续上升 | 识别分区、下游或服务配额瓶颈 |
假设平均消息体为4 KB，36万条消息的消息体约占1.44 GB。该数值不等于云服务实际占用或费用：消息属性、索引、复制策略、计量方式和保留时间都可能改变结果。应查所选服务的当前文档和账单口径，并为元数据及峰值波动留出余量，不能把估算值当作可用容量上限。
先认清服务的扩容方式
不同队列服务的容量单位和扩展机制并不相同。Amazon SQS 以托管队列方式提供服务，适合希望减少底层集群维护的场景，但仍需检查请求速率、消息大小等服务限制及账户配额。Apache Kafka 通常需要结合分区数、代理节点、磁盘和消费者组规划；分区有助于并行处理，但过多分区也会增加管理开销。选择时应以实际服务文档为准，不要把一家的配额或扩缩容规则套用到另一家。
无论选哪种方案，都要验证瓶颈是否在队列本身。若消费者依赖数据库、支付接口或外部 API，单纯增加消费者可能把压力转移到下游，导致超时和重试，反而进一步抬高积压。
按可执行步骤完成容量规划
- 采集基线：至少区分日常、促销高峰和突发尖峰，记录到达速率、消费速率、消息大小分布、积压量及最长处理时间。
- 设定恢复目标：明确允许积压持续多久，以及订单、通知等不同消息是否有不同优先级和保留要求。
- 计算峰值与存储：用峰值持续时间估算最大积压，再按消息大小和保留期核算资源；另为重试、短时波动和测量误差预留余量。余量大小需结合业务波动和服务限制确定，没有适用于所有场景的固定比例。
- 压测并检查配额：用接近真实大小的消息测试生产、消费和故障恢复，逐步增加并发，观察吞吐、延迟、错误率、磁盘或服务端限制，以及下游承载能力；必要时提前申请配额或调整分区。
- 设告警与降载方案：同时监控积压条数、最老消息年龄、生产与消费速率、失败重试和死信队列。预先确定暂停低优先级任务、限制生产速率或扩充消费者的条件。
容量规划的重点是可恢复
大促前不要只验证队列能否接住峰值，还要演练消费者故障后积压如何恢复，以及恢复时是否会冲击下游。云端消息队列服务的容量规划最终应落到可测量的吞吐、存储、保留期限和恢复时间，并由监控数据持续校正。
常见问题
队列条数没到上限，为什么仍然变慢？
可能是消息体较大、消费者处理变慢、请求受限或下游响应变差。应同时检查最老消息年龄、吞吐和错误情况。
消费者越多，积压就越容易清空吗？
不一定。只有在队列并行度允许、下游也有余量时，增加消费者才可能提升处理能力；否则可能加重限流与重试。
是否按大促最高流量直接购买容量？
先确认服务的弹性能力、配额和扩容时间，再用压测验证。若存在扩容延迟，应提前准备；若服务按实际使用计费，也需比较预留资源与峰值扩展的成本。
把峰值、积压和清空时间一起纳入评估，才能让云端消息队列服务的容量规划既接得住突发，也能在可接受时间内恢复。