消息队列堆积、重复消费和消息丢失：生产级治理完整指南

问题现象：队列把同步故障变成了延迟故障

消息队列能削峰和解耦，但消费者速度低于生产速度时，问题不会消失，只会形成积压。排查应先计算生产速率、消费速率和剩余处理时间。如果生产每秒一万条、消费只能八千条，增加消费者前还要确认分区数、下游数据库和外部接口是否能够承受更高并发。

堆积处理先止血再追赶

突发积压时可以临时扩容消费者、增加分区或启用专用追赶任务，但必须限制对下游的压力。非关键消息可降级或批量处理，过期消息要依据业务价值决定丢弃还是补偿。消费者处理时间突然增长时，应检查慢 SQL、外部调用和锁竞争，而不是只调大拉取批次。

幂等是重复消费的基本前提

网络抖动、消费者重启和确认超时都可能导致同一消息再次投递。可使用业务唯一键、去重表、状态机或带条件的更新保证重复执行不产生额外结果。不要仅依赖短期缓存去重，因为缓存丢失或过期后重复仍会进入业务。

消息不丢需要端到端验证

生产端要确认消息已经被代理持久化，消费端应在业务事务完成后再确认。若业务写入与确认不在同一事务，需要使用本地消息表或可靠补偿。失败消息不要无限重试，应进入延迟重试和死信队列，记录错误原因、重试次数与原始上下文，并提供人工处理入口。

监控指标与演练

持续监控积压量、最老消息年龄、生产消费速率、失败率和死信数量。问：积压量多少算异常？答：要结合消费速率和业务时效，消息年龄通常比数量更直观。定期演练消费者停机、代理故障和下游限流，才能确认恢复流程真实可用。