消息队列削峰，需要把生产速度、消费速度和等待预算放在一起

队列问题优先看什么

适用边界：队列适合允许延迟的工作

通知、图片处理、部分报表、批量同步和可查询状态的后台任务适合异步化。必须在用户操作时立刻确认的权限、余额或库存约束，不能仅因入队成功就省略最终判断。

先和业务确定“已受理”与“已完成”的区别，给任务分配稳定标识和查询入口。任务可能包含多个阶段，每个阶段需要明确可重试与不可重试的动作。消息中只放必要标识和版本，超大数据可以由受控存储引用，避免大消息放大网络、存储和重投成本。

等待预算应覆盖生产受理、代理存储、消费执行和结果持久化，不能只统计从消费者取到消息后的时间。对于定时或有失效时间的任务，过期后是否继续执行由业务确定；消息过期、业务过期和永久失败需要不同结果，才能向用户解释任务去向。

• 注明最长允许等待、最终结果保存方式与失败通知规则。
• 按任务优先级和依赖区分队列，避免长任务挡住紧急任务。

从净处理能力计算积压与恢复预算

应同时观察生产量、成功消费量、失败重试量和最老消息年龄。只看消息数量可能误判：不同任务处理成本差异很大，少量慢任务也可能占满消费者，等待年龄更能说明业务是否延误。

在近似稳定的处理能力下，可以用积压工作量与峰后净处理余量估算清空时间；如果生产仍大于或等于有效消费，就没有可用的清空余量。估算必须按任务类型和实际耗时校正，不能把多台消费者的理论速度简单相加，共享数据库可能已经成为上限。

• 记录不同任务大小与耗时分布，建立等待预算。
• 为峰值长度、存储增长和峰后恢复时间分别设置停止条件。

发布确认与消费确认是两个独立事实

以 RabbitMQ 为例，发布确认说明代理接收消息的相应责任，消费确认说明消费者处理交付；两者互不代表对方阶段。消息发到网络套接字并不证明已经可靠存储，更不说明最终业务完成。

确认前后可能断网，生产者与消费者需能识别结果未知和重复处理。任务提交和消息发送跨越不同存储时，要记录待发布或受理状态，并有恢复扫描，避免数据库已提交但消息没有发出。消息被重复交付后，业务副作用应通过稳定标识和状态约束保持幂等。

• 建立已受理、已发布、处理中、完成与终止失败的可查询状态。
• 按客户端与队列类型验证确认、持久化和不可路由消息处理。

预取、并发和背压要受同一资源预算约束

预取过多会将积压从队列搬到消费者内存，未必提升业务处理速度。配置有限预取和执行并发时，应结合单任务内存、耗时、数据库连接与外部调用限额，避免消费者多领少做。

队列长度或字节上限也要有溢出语义。某些默认策略可能丢弃或死信较早的消息，不能在关键任务中不经评估采用。等待达到预算后，生产端应减速、拒绝或返回真实延期状态；监控平台显示积压不是背压本身，背压必须改变接收或调度行为。

• 压测不同预取与消费并发，按有效完成量选择配置。
• 明确队列满、存储告急和依赖变慢时生产端的响应。

实施步骤：先补状态闭环，再处理峰值

先定义任务状态与等待目标，再实现发布和消费确认、业务幂等与失败终止；随后测单消费者有效能力，配置预取与并发，建立入口背压，最后验证多消费者扩容与峰后恢复。

将输入错误、永久业务失败和短暂依赖失败分开。短暂失败可延后有限重试，永久失败进入可检查状态；立即无限重投会挤占正常任务。恢复扫描、死信重放与人工补偿也需要限速和权限，批量重放前先确认任务是否已经产生副作用。

• 每个失败记录带任务标识、错误分类、尝试次数与下一步动作。
• 扩消费者前检查下游净余量，不能只按队列深度无限扩容。

验收：峰值期间受理与峰后完成都要成立

验收覆盖生产突增、消费者停机、依赖变慢、重复交付、队列满和恢复重放。峰值结束后应在约定时间内完成积压，关键任务没有静默丢弃，已完成状态与业务数据相符。

对未完成任务逐项说明是在等待、失败、过期还是人工处理，避免把消费速率当成交付率。消费者退出后重新启动，检查重复任务没有重复执行关键副作用。测试结果应包含最老任务年龄、有效消费量与资源占用，以及队列服务或网络异常时的受理边界。

如果任务要求按业务对象顺序处理，需要单独验证分区或同对象串行规则。多个消费者、重试与死信重放可能改变完成顺序，不能假设消息先发送就一定先完成。把顺序约束写入状态更新逻辑，再确认这种约束对吞吐与热点任务等待的影响。

• 核对生产记录、代理确认、业务完成与失败清单的数量关系。
• 验证长任务、错误任务和恢复重放不会挤占正常任务预算。

需求讨论中的问题