备案站点的消息队列与异步任务运维

一个「先返回成功，稍后再做」的承诺

注册后发短信、上传后转码、下单后扣库存——把慢操作从请求链路里挪走，用户体验立刻变好。代价是你引入了一个必须被运维的中间系统：消息队列平时非常安静，安静到没人监控它，等到有人发现异常时，队列里往往已经堆了几十万条消息，业务数据延迟了好几个小时。

关键要点

• 队列的核心指标不是长度，而是消费延迟：最老的那条消息已经等了多久。
• 消费端必须幂等。实际投递语义几乎都是「至少一次」，重复消费是常态而不是异常。
• 每个队列都要配死信队列（DLQ），并且要有人负责处理它，否则 DLQ 只是另一个垃圾桶。
• 扩容消费者之前，先确认瓶颈在消费速度，而不是在下游数据库。

先分清三种「积压」

现象	根因	正确处理方向
生产端突增	活动、批量导入	临时扩消费者、削峰限速
消费端变慢	下游超时、慢查询、GC	先修下游，扩容无效
消费者不干活	进程崩溃、被 OOM 杀掉、卡死	先恢复实例，再查根因

盲目扩容消费者是最常见的误操作：如果瓶颈是数据库写入，增加消费者只会把数据库压得更死，积压反而涨得更快，数据库侧的排查见 数据库运维与高可用。判断方法很简单——看消费者的 CPU 与等待时间，如果消费者大部分时间在等下游响应，那扩容解决不了问题。

幂等：重复消费是常态

消费者处理完业务、但在提交 ack 前崩溃，这条消息就会被重新投递。所以「同一条消息被处理两次」不是 bug，而是必然会发生的情况，消费逻辑必须自己扛住。

做法	实现方式	适用场景
唯一索引去重	把消息 ID 或业务单号建唯一键	写入型操作，最可靠
状态机流转	仅允许「待处理 → 已处理」	有明确状态字段的单据
缓存去重键	Redis 记录已处理 ID 并设过期	轻量场景，需容忍缓存丢失

缓存方案要注意过期时间必须大于消息最大重试窗口，否则去重键先过期、消息再重放就失效了，缓存本身的运维见 缓存与 Redis 运维。

重试、退避与死信队列

失败消息立刻重试，对「下游过载」这类故障等于火上浇油。正确做法是指数退避加随机抖动，并且给重试次数封顶，超过上限就进 DLQ，退避策略的细节见 超时设置与重试策略。

进 DLQ 时要一并保留：原始消息体、失败原因、已重试次数、首次失败时间。缺了这些，DLQ 里的消息就是一堆无法排查也无法重放的死数据。DLQ 还必须配两样东西：新增即告警，以及一键重放的工具。

顺序、分区与消费者数量

绝大多数队列只保证分区内有序，跨分区无序。需要顺序时，用业务键（如订单号）把相关消息路由到同一分区，而不是把整个队列退化成单分区——那样吞吐直接被锁死在一个消费者上。

还有个容易踩的坑：消费者数量超过分区数时，多出来的消费者只会空转。扩容前先确认分区数是否足够，容量评估方法见 容量规划与弹性伸缩。

发版时别直接 kill 消费者

直接杀进程会让处理到一半的消息既没完成、也没 ack，轻则重复处理，重则业务处于中间状态。正确顺序是：停止拉取新消息 → 处理完在途消息 → 提交位点 → 退出，做法见 优雅停机与健康检查。

必须监控的四个指标

指标	含义	告警建议
消费延迟	最老消息的等待时长	超过业务容忍上限即告警
积压条数	待处理消息总量	持续单调增长即告警
失败率/重试率	消费稳定性	突增告警，常是下游先出问题
DLQ 新增量	兜底信号	大于 0 就要有人跟进

只看积压条数会漏掉慢速积压：条数看着不多，但最老那条已经等了两小时。告警落地见 备案网站监控告警体系，链路追踪与日志关联见 可观测性建设。

和定时任务的分工

队列负责实时性要求高的异步处理，定时任务负责兜底对账与补偿——两者是互补关系。只靠队列没有对账，一旦消息丢了就永远发现不了，对账任务的写法见 定时任务运维：幂等、防重与补偿。

常见坑

• 只监控队列长度不监控延迟：慢速积压完全看不见。
• 消费端没有幂等：一次重投就产生重复订单或重复扣款。
• 无限重试没有上限：一条毒消息能把整个队列卡死。
• DLQ 建了但没人看：等于没建。
• 消息体塞大文件：应只存引用，文件放对象存储，见 对象存储与静态资源托管。

常见问题

队列积压了几十万条，应该先扩容消费者吗？

先判断类型。如果是生产端突增、消费者本身还有余力，扩容有效；如果是下游数据库或第三方接口变慢，扩容只会加剧下游压力，应该先修下游或临时降低消费并发。

为什么消费端一定要做幂等？

因为主流队列的投递语义是「至少一次」：消费者在提交确认前崩溃、超时重投、运维手动重放，都会导致同一条消息被处理多次。幂等是消费端的基本要求，不是可选优化。

死信队列里的消息可以直接清掉吗？

不建议直接清空。先看失败原因分类：代码 bug 修复后应重放，脏数据应记录后归档。清空前至少要导出留档，否则这部分业务数据就真的丢了。

顺序消费和高吞吐能同时要吗？

只能在「同一业务键有序」的粒度上兼顾：按订单号哈希到固定分区，分区之间并行。要求全局严格有序就必然牺牲吞吐。

资料来源

Kafka、RabbitMQ、RocketMQ 等主流消息中间件官方文档中关于投递语义、消费位点、死信队列与分区模型的公开说明。本文为通用运维说明，仅供参考，具体以实际中间件版本与业务架构为准。