消息队列问题排查指南：消息丢失、重复消费与积压治理

做后端这些年，消息队列大概是我见过最典型的“平时岁月静好，一出事就是大事”的组件了。功能看起来很简单，生产端发一条消息，消费端收一条消息，中间加一层缓冲，好像没什么技术含量。可真到生产环境里跑起来，消息丢失、重复消费、积压告警、顺序错乱，一个个问题全冒出来了，而且往往都是在半夜三更冒出来。

这篇文章把我这几年在各类项目里反复遇到的MQ常见问题做一次完整梳理。不会只讲“是什么”，重点放在“为什么发生”和“怎么排查、怎么解决”。每一条都尽量用实际场景讲透，不管是刚接触消息队列的新手，还是已经维护过一段时间的老手，应该都能找到对你有用的那一段。

1. 先看清消息队列的本质

1.1 消息队列到底解决什么问题

很多人对消息队列的第一印象是“用来做异步的”，这没问题，但只说对了一小半。异步只是表象，它真正解决的是三个问题：解耦、削峰、缓冲。

解耦比较好理解。订单服务创建订单后，不需要自己去调用积分服务、短信服务、库存服务，只要把“订单已创建”这个事件发到队列里，其他服务自己去订阅就行了。订单服务不需要知道下游到底有谁，下游增加或减少都不影响订单主链路。

削峰和缓冲更像同一个问题的两面。瞬时流量上来的时候，如果所有请求直接打到数据库，数据库基本扛不住。消息队列在中间拦一道，生产者把消息高速写入，消费者按自己的处理能力慢慢消费，等于给系统装了一个“蓄水池”。我见过一个真实场景，某个活动开场一分钟内的请求量是平时的几十倍，数据库连接池当场被打满，后来在前面加了一层队列，数据库压力瞬间就平缓了。

但问题也随之而来：队列引入之后，系统的链路变长了，出故障的点也变多了。消息发不出去怎么办、消息丢了怎么办、消息重复了怎么办、消费者挂了怎么办，这些都是消息队列使用的核心问题，也是本文后面要展开的内容。

1.2 选型时的常见误区

选型是很多人第一个踩坑的地方。我记得有个项目，技术负责人只看某款组件吞吐量高，就直接定了它做所有场景的默认队列。结果业务里有大量需要延迟队列、死信重试的场景，那个组件的延迟队列实现非常别扭，最后只能自己造轮子。

选消息队列不能只看性能指标，要看场景匹配度。我一般会把需求先拆成下面几类：

当然这里说的都是方向性建议，具体选型还要考虑团队熟悉度、运维成本、现有技术栈的兼容性。我的经验是：先想清楚你要的到底是“高吞吐”还是“高可靠”，这两个目标很多时候是冲突的，吞吐拉满往往意味着可靠性妥协，可靠性做到极致又会牺牲一部分性能。没有完美的队列，只有匹配你场景的选择。

再补充一个容易被忽略的问题：不是所有地方都适合用消息队列。微服务之间简单的同步调用就能搞定的事情，非要硬塞一个队列进去，只会让链路变长、问题变多。数据一致性要求极高、必须强一致读写的场景，也不适合。这三类情况我建议直接用普通接口调用，别为了“架构先进”而制造麻烦。

2. 消息丢失：生产环境最怕的“静默故障”

2.1 丢失发生的三个环节与排查思路

消息丢失是所有消息队列问题里最隐蔽、最难排查的，因为它不像积压那样有明确告警，也不像重复消费那样可以在日志里发现。业务看起来一切正常，但某些消息就是无声无息地没了，等到对账才发现数据不对，这时候再回溯已经晚了好几天。

一条消息从产生到被消费，经过三个环节：生产端发送、Broker存储、消费端处理。消息丢失只可能发生在这三个环节中的某一个，排查思路也按这个链路走。

生产端的问题通常是发送后没有确认机制。有些客户端库默认是异步发送，消息发出去就返回了，网络闪断、Broker暂不可用、请求超时，消息直接丢弃，但生产端毫不知情。解决思路很明确：开启写入确认，同步等待Broker返回成功结果，失败则重试。很多消息队列客户端都提供了确认机制，核心参数包括acks、retries、max.in.flight.requests等。我之前在一个项目里就遇到过一次：开发为了方便把确认机制关掉了，上线一个月之后对账发现少了一千多条消息，就是因为高峰期网络抖动时消息静默丢了。

Broker端的问题在存储环节。Broker收到消息后，先写内存再异步刷盘，如果刷盘前宕机，内存里的数据就全丢了。副本同步也分同步和异步，异步副本在节点故障时会有数据差。所以Broker端的核心配置是刷盘策略和副本数，可靠性要求高的场景必须同步复制，并且把刷盘设置为强制刷盘，牺牲一点吞吐换数据安全。

消费端的丢失往往容易被忽视。很多人以为消费端丢消息只能是“没保存就报错”，实际上还有更隐蔽的情况：自动提交位移。有些消费者默认是处理完消息后自动提交消费位移，但如果你在处理逻辑里有异步操作，或者处理线程和提交线程不是同一个，就可能出现“消息还没处理完，位移已经提交了”的情况。这时候消费者一重启，没处理完的消息就不会再被拉取，消息就在消费端丢了。

2.2 一条经过验证的排查清单

我在实际排查消息丢失时，会按下面的顺序逐项检查，效率最高：

• 生产端有没有开启确认机制？确认参数是什么级别？
• 生产端有没有配置合理的重试次数？重试之间有没有退避？
• Broker刷盘模式是什么？副本同步是同步还是异步？
• Broker宕机后有没有选举机制？未同步的数据会怎么处理？
• 消费者是否关闭了自动提交位移？提交位移的时机是否在处理成功之后？
• 消费者的处理逻辑里有没有异步提交、线程池直接传递消息对象？
• 有没有对生产、消费做消息对账？有没有全链路追踪？

其中最后一条最关键。我自己的习惯是让生产端在消息里带上全局唯一ID，消费端处理成功后把ID记录到日志，定期做跨端对账。这个对账逻辑虽然要额外开发，但在可靠性要求高的核心链路上非常值得，它能让你第一时间发现“消息消失了”而不是等业务对账发现问题。

注意，消息丢失问题有一个很讨厌的特点：重现率低。线上偶尔丢几条，测试环境基本不出问题。所以不要抱侥幸心理，所有核心链路的消息发送，必须基于“会丢”的前提去设计。

下面给一段生产端和消费端的关键配置参考，不同组件配置略有差异，核心思想是通用的：

# 生产端配置（示意） acks: all # 等待所有副本确认 retries: 3 # 失败重试3次 max.in.flight.requests.per.connection: 1 # 保证分区内消息顺序 enable.idempotence: true # 开启幂等发送 # 消费端配置（示意） enable.auto.commit: false # 关闭自动提交 max.poll.interval.ms: 300000 # 单次拉取处理超时上限

配置完之后，还要用日志确认每次消息的发送结果和消费结果。曾经有同事问我，开启同步确认后性能是不是会变差？确实会有损耗，但核心链路的数据安全比那几毫秒的延迟重要得多。如果你真的对性能极其敏感，可以做分级处理：核心业务走强可靠模式，非核心日志类消息走异步模式。

3. 重复消费：无法根除，只能设计

3.1 为什么重复消费一定会发生

消息队列的投递语义通常是“至少一次”，也就是说一条消息被消费一次以上是允许的，丢消息才是不允许的。再加上生产端重试、消费端重启、消费者组再平衡等机制，重复消费几乎不可避免。

举个例子：消费者处理完业务逻辑，还没提交位移，突然宕机了。重启之后，消费位移还停留在处理之前的位置，Broker会重新把这条消息投递过来，消费者自然就再处理一遍。如果处理逻辑不是幂等的——比如扣减库存、发优惠券、累加积分——就会产生重复计算。

还有一类容易被忽略的重复来自生产端。生产者发送消息后网络超时，实际Broker已经写入成功了，但生产者没收到确认，于是重试发送，Broker里就会存在两条一模一样的消息。即便开启幂等发送，也只能解决单个生产会话内的重复，跨会话的场景不一定完全覆盖。

我见过一个很典型的线上事故：一个积分系统消费订单消息，处理逻辑是“订单金额每满100元加10积分”，重复消费了三次，用户积分直接多加了20。排查半天才发现是消费端有一个网络超时重试逻辑，和消息队列自带的重试叠加了，导致一条消息处理了三次。

3.2 幂等设计的核心思路

既然重复无法根除，唯一的出路就是让消费逻辑天然具备幂等性。所谓幂等，就是“无论执行一次还是执行多次，结果都一样”。

实现幂等最常用的三种方式：

• 唯一业务键 + 去重表：每条消息里带一个业务唯一键，消费时先查去重表，存在就跳过。
• 版本号控制：给业务数据加版本字段，更新时校验版本号，旧版本不覆盖新版本。
• 数据库唯一索引：把业务唯一标识作为数据库唯一索引，重复插入直接报错，由异常捕获逻辑来处理。

我比较推荐的是“唯一业务键 + 去重表”的方式，因为实现简单而且覆盖大部分场景。下面是一段伪代码：

def consume_order_message(message): # 从消息里取业务唯一键和消息唯一ID msg_id = message["msg_id"] biz_key = message["order_id"] # 幂等判重：成功插入说明之前没处理过 try: insert_into_idempotent_table(msg_id, biz_key) except DuplicateKeyError: # 已处理过，直接跳过 log_duplicate(msg_id) return # 执行真正的业务处理 try: process_order(biz_key) except Exception: # 处理失败删除幂等记录，等待MQ重试 delete_idempotent_record(msg_id) raise

这里有个细节值得注意：幂等表的插入动作必须和业务处理放在同一个事务里，或者至少保证业务处理成功后再提交幂等记录。如果两个动作不在一个事务里，可能会出现幂等记录已经写入但业务处理失败的情况，导致消息被永久跳过。反过来，如果先执行业务再写幂等记录，又会出现业务处理成功但幂等记录没写入的窗口期，重复消费还是会穿透。

我的经验是：如果下游是关系型数据库，直接用数据库唯一索引做幂等最稳妥，比自己去写去重表更可靠，也少了一层数据一致性维护成本。如果是非关系型存储，再结合消息唯一ID和业务唯一键做去重。总之，幂等不是“要不要做”的问题，而是“怎么做才不漏”的问题。

4. 消息积压：从告警到恢复的完整处理路径

4.1 积压问题的定位方法

消息积压是最“有存在感”的MQ问题，因为它通常伴随着监控告警而来。消费延迟持续增大，堆积的消息越来越多，磁盘占用不断上升，严重的时候会触发消息过期清理，造成大面积消息丢失。

积压的排查思路，我一般按下面的顺序来：

先看消费者有没有报错。消费者组的日志里如果有持续的异常，比如反序列化失败、数据库超时、下游接口报错，通常就是积压的根因。要知道消息队列只负责投递，不负责业务成功，消费端处理失败时如果不停地重试，就会阻塞后续消息。

再看单个消息的处理耗时。消息队列的消费者默认是拉取一批消息，然后逐条处理。如果单条消息处理耗时过长，消费者会一直停留在当前批次，新消息根本进不来，表现为消费速率极低。

接着看消费线程数和消费实例数。消息队列的分区消费模型决定了并行度上限：一个分区在同一时刻只能被一个消费者实例消费。如果你只有3个分区，就算你部署了10个消费者实例，也只有3个在干活。

最后看下游依赖。消费链路里如果依赖数据库、Redis、外部RPC，任何一个下游抖动，消费都会被拖慢。

按这个顺序排查，大多数积压问题能在半小时内定位到根因。我遇到过最快的积压定位是一次数据库死锁导致的：某个批量更新语句在高并发下产生了大量锁等待，消费者线程全部卡在数据库操作上，消息越积越多，数据库压力越大，形成恶性循环。

4.2 应急处理与根因修复

积压处理的黄金法则是：先止损，再找根因。不要一上来就研究代码逻辑哪里写得不好，先把堆积的消息处理掉，让系统恢复服务，然后再慢慢复盘。

应急操作按优先级排列：

• 提升消费并行度：增加分区数、增加消费者实例。注意增加实例的前提是分区数足够，分区数不够加实例是没用的。
• 如果消息处理逻辑里有耗时操作，比如调用外部RPC，可以临时调大消费者的批量拉取数量，或者暂时把业务逻辑简化，只做核心字段处理。
• 如果积压量实在太大，可以考虑临时把堆积的消息转发到另一个空闲队列，用额外的消费者集群专门处理，处理完再回归主链路。
• 如果积压已经触发了消息过期丢弃，那就只能接受现实，启动数据补偿流程。

这里有一个常见的误区：很多人一看到积压，第一反应就是加消费者。但积压的本质是“生产速率大于消费速率”，加了消费者之后只提升了消费端接收能力，如果瓶颈在下游数据库或者外部依赖，加再多消费者也没用，反而会把下游打得更死。

我经历过一次比较典型的事件：消费者线程全部阻塞在外部接口调用上，那个接口平均响应时间5秒，超时时间设成了30秒，一个线程一分钟只能处理12条消息，而生产速率是一分钟几千条。当时没有仔细分析，直接扩容到20个消费者实例，结果对外部系统造成了更大压力，接口变得更慢，积压更严重了。后来紧急把外部调用的超时时间改成2秒，再针对失败的消息走重试队列，积压才慢慢降下来。

还有一个实操经验：在消费逻辑里给每条消息的处理加一个最大耗时阈值，超过阈值直接转死信队列或重试队列。单个消息卡死会影响后续所有消息，这种“害群之马”必须快速隔离。

5. 顺序消费与最终一致性：被低估的两块硬骨头

5.1 顺序性到底怎么保证

顺序消息是很多人容易理解偏的问题。一说“消息要顺序”，就想着所有消息都要严格按生产顺序消费，这其实不太现实。更合理的思路是区分全局顺序和分区顺序。

全局顺序意味着所有消息在所有队列里都保持严格先后，这基本等于抛弃了并行消费，吞吐量会掉到非常低，一般只在极少数强顺序业务里才会用到。大多数业务场景只需要分区顺序就够了，也就是“同一个业务实体的消息有序”。比如订单状态流转：创建、支付、发货、完成，这些事件必须按顺序处理，但不同订单之间完全可以并行。

实现分区顺序的关键点有两个：

第一，同一个业务实体的消息要发到同一个分区。一般通过消息里的某个key来计算分区号，比如用订单ID作为key，订单ID相同的消息自然落到同一个分区。

第二，单个分区只能被一个消费者线程处理，并且一条消息处理完再处理下一条。如果消费者内部用了多线程并行处理同一个分区的消息，顺序必然会被打乱。

我见过一个很经典的坑：某个团队实现了顺序发送，消息日志显示到达顺序也是对的，但消费者里用了一个线程池来处理消息。怎么保证顺序呢？他们当时用的是“按key哈希后丢给不同的线程”这种思路，认为同一个key的哈希值一样就会进同一个线程。听起来好像没错，但线程池里任务是排队不是同步执行，如果同一个key连续两条消息，第一条还没处理完就轮到第二条，第二个线程也可以同时处理同key的第二个消息，顺序就乱了。正确做法是一个分区一个处理线程，不要试图用哈希去分摊负载。

这里要提醒一句：顺序消费是需要付出代价的。一旦同一个分区的消息只能串行处理，吞吐量会明显下降。所以不要把顺序性当成默认需求，先问业务：真的需要顺序吗？允许乱序之后用补偿机制恢复吗？大多数场景里，最终一致性是比全局顺序更合适的答案。

5.2 事务场景的通用解：本地消息表

分布式事务是消息队列使用中另一个硬骨头。举个例子：用户下单后要扣库存、加积分、发优惠券，这些操作分布在多个服务里。如果其中一个服务失败了，其他服务的数据怎么回滚？使用消息队列做最终一致性是常见方案，但很多人一开始会直接使用“事务消息”，然后发现各种限制。

事务消息本身是解决“本地事务和消息发送不一致”问题的，它通过半消息机制保证“要么消息不发送，要么消息最终一定会发送”，但它在某些组件中实现复杂，版本差异大，用起来反而容易踩坑。我更推荐一种通用性更强的方案：本地消息表。

思路是这样的：业务操作和消息写入在同一个本地事务里完成。比如订单服务在创建订单的同时，往本地消息表里插入一条“订单已创建”的消息记录，两个操作在同一个数据库事务里，要么都成功，要么都失败。然后由一个后台任务定期扫描消息表，把未发送的消息发送到消息队列，发送成功之后把消息状态标记为“已发送”。

消费端如果处理成功，可以回执给生产端，生产端把消息状态更新为“已消费”。如果消费端一直没回执，生产端的扫描任务会重新发送，所以消费端必须做幂等。

这个方案的优点有几个：理解成本低，不依赖特殊组件特性；过程透明，消息状态全在表里，排查问题很方便；可靠性高，只要数据库不丢数据，消息就不会丢。

缺点也很明显：消息表会随着业务增长越来越大，需要定期清理；存在一定的发送延迟，因为依赖后台扫描，实时性不如直接发送高。但对大多数秒级最终一致性的场景来说，这点延迟完全可接受。

我在实际项目里使用过这种方案，稳定性比直接用事务消息还高。有一段时间线上网络抖动频繁，事务消息经常出现消息状态不明的情况，需要人工介入确认；换成本地消息表之后，至少消息状态是可以查的，出现异常时通过表数据判断，处理成本低很多。

6. 监控告警与故障应急：把“踩坑”变成“预案”

6.1 必盯的关键指标

很多团队的消息队列上线之后，监控基本只关心“消息是否报错”，这远远不够。消息队列的性能和健康度需要从多个维度观察，我整理了一个常用的监控指标清单：

其中消费延迟是最需要盯紧的，它比消费速率更能反映问题。消费速率是一个平均值的概念，偶尔抖动看不出来，但延迟会一直累积。延迟超过一定阈值，基本就意味着积压已经形成，需要立即介入。

另外，死信队列也是重点。死信消息代表消费端已经多次重试仍然失败，正常情况下不应该频繁出现。如果死信数量持续增长，说明系统里有功能Bug或者外部依赖出了严重问题。我见过一个团队，死信队列里堆了几万条消息却没人看，直到业务对账发现问题去查，才发现一个字段格式变更导致反序列化失败，已经持续了整整一周。

6.2 故障应急的实操流程

消息队列发生故障时，人的判断容易乱。尤其是大半夜被告警吵醒，手里一堆指标不知道先看哪个。我自己的习惯是提前把应急流程固化下来，步骤如下：

• 第一步，确认影响面：先看延迟指标、死信数量、消息堆积量，确认哪些链路受到影响，影响多少条消息。
• 第二步，止血：如果是消费端处理失败，先考虑关闭消费者或切换流量，避免影响范围扩大。
• 第三步，定位根因：拉消费者日志、看最近的代码变更、查下游依赖状态，快速定位问题源头。
• 第四步，恢复处理：修复问题后，手动触发积压消息的消费，观察延迟是否下降。如果积压量极大，考虑扩容或临时队列。
• 第五步，复盘：无论故障多大多小，结束后都要复盘，把问题原因、恢复过程、改进项记录下来。

这套流程看起来简单，但真正执行起来需要平时做演练。很多团队连“消费者挂了怎么重启”“消息积压了怎么扩容”都没有提前验证过，真到故障现场才现查文档，效率极低。

有一个我一直强调的习惯：故障恢复不等于问题解决。线上恢复了，如果根因没有找到，同样的问题大概率会在几周后重新出现。复盘记录里一定要写清楚“为什么会发生”和“下次怎么更快发现”，而不是只写“恢复了”。

再分享一个排查技巧：当消费延迟突然升高时，先去看最近的发布记录。消息队列相关的问题，绝大多数不是组件本身坏了，而是某一次代码发布引入的。回滚往往比修复更快更安全。

提示：不要在生产环境直接做压测验证。如果真的想验证某个配置的效果，先在预发环境复制一份线上场景，模拟流量后观察指标再决定。

收尾的一点个人体会

做消息队列的维护时间久了，你会发现一个规律：大部分问题不是组件不够好，而是使用方对机制理解不够深。确认、位移、重试、幂等这些概念，看起来都不难，但组合在一起就是很多事故的根源。

我的建议很简单：设计阶段想清楚可靠性级别，上线前完整走一遍“发送、消费、重复、积压、重启”这几个流程的模拟演练，把可能出现的问题提前暴露出来。真到了线上出问题的时刻，第一反应永远是看监控、确认影响面，而不是急着重启消费者。重启只能让你线上恢复，不一定能让问题不再发生。

最后再说一个实用小技巧：给生产端的每条消息都带上一个业务追踪ID，给消费端处理结果也记录同样的ID。看起来只是多了一个字段，但排查消息丢失、重复、乱序问题时，这个ID就是你的路标，能帮你省下大量翻日志的时间。每次排查耗时超过一小时我都会问一句：如果当时有全链路追踪数据，是不是五分钟就能定位到问题？答案几乎都是肯定的。