JMS Listener随机选取消息处理结果不一致问题咨询

根因定位 #

你遇到的随机消费、部分消息不处理的场景，本质是JMS队列的多实例负载均衡消费机制触发的，和单测验证的代码正确性无关，常见触发原因如下：

• 多节点重复部署了旧版监听器：测试/正式环境存在多个未下线的旧版服务实例同时监听同一个JMS队列，JMS默认会将队列消息轮询/随机分发给所有监听的消费者实例，你同事本地未更新代码的实例、后台未追踪到的存量旧实例都会分到一部分消息，这部分消息走旧逻辑自然不会展示用户详情；你本地单测时只有1个消费者，所以所有消息都走新逻辑完全正常。
• 监听器配置了错误的消息确认机制：如果配置了CLIENT_ACKNOWLEDGE但代码中未调用Message.acknowledge()，或者DUPS_OK_ACKNOWLEDGE模式下服务异常退出，未消费的消息会被重新投递，看起来就像随机漏处理消息。
• 消息过滤规则被意外配置：检查监听器是否设置了messageSelector，过滤掉了部分符合规则的消息。

排查步骤 #

• 先定位所有监听当前队列的消费者实例：如果使用ActiveMQ可以直接在控制台「Queues」页面对应队列的「Number Of Consumers」入口查看所有消费者的IP、客户端ID；如果是RabbitMQ的JMS客户端可以在控制台「Connections」菜单筛选绑定对应队列的连接；如果是RocketMQ的JMS兼容实现可以通过mqadmin consumerStatus命令查询消费组下所有实例IP。
• 确认所有实例的代码版本：找到所有消费者实例后核对部署包的版本，下线所有未更新你代码变更的旧实例、同事本地启动的测试实例后再推送测试消息验证，确认是否所有消息都能正常展示用户详情。
• 检查监听器配置项：核对配置文件中监听器的确认模式、消息过滤规则、并发消费参数，确认没有配置错误导致消息漏消费：

  # 错误示例：配置了客户端确认但代码没做ack
  spring.jms.listener.acknowledge-mode=client
  # 验证用配置：简单业务场景可以先改成自动确认验证逻辑是否正常
  spring.jms.listener.acknowledge-mode=auto
  

解决方案 #

• 统一消费组版本管理：上线前确认所有旧版本实例完全下线，测试环境禁止多人员同时启动同一个消费组的实例监听公共队列，可以给本地测试的监听器加独立的消费组前缀，避免和公共环境的消费组冲突抢消息。
• 补全消息确认逻辑：如果使用客户端确认模式，必须在业务逻辑处理完成后显式调用message.acknowledge()，异常场景不要调用ack让消息重新投递或者进死信队列。
• 新增消息轨迹埋点：在消息头中添加唯一的traceId，消费逻辑入口和出口都打印traceId、消费者实例IP、处理结果，后续出现消息异常可以直接通过traceId定位到处理该消息的实例。

内容的提问来源于stack exchange，提问作者Priyadharshini Gopalakishnan