使用Get调用时IBM MQ队列出现消息跳过问题咨询

一、怎么判断被跳过的消息是未提交/延迟提交状态 #

未提交的消息属于「飞行中」状态，只有事务提交后才会变成可正常获取的状态；延迟提交就是消息已经进入队列，但生产者事务未完成，暂未正式提交到队列。可以从这两点判断：

• 查看消息状态：未提交消息的状态为MQMSG_STATE_IN_FLIGHT，提交后会变为MQMSG_STATE_COMMITTED；
• 查看事务关联：未提交消息绑定了未完成的事务，普通的Browse/Get操作无法获取，必须使用事务相关的操作选项才能查看。

二、查看消息状态的IBM MQ命令 #

1. 使用runmqsc命令行工具 #

先连接到目标队列管理器，再执行以下命令：

• 查看队列未提交消息数量：

  DISPLAY QLOCAL(你的队列名) CURDEPTH UNCOM
  

  输出中的UNCOM字段即为队列内未提交的消息数量，若数值大于0，说明存在未提交消息；
• 查询单条消息的详细状态（需提前获取消息ID）：

  DISPLAY MSGSTATUS(你的队列名) MSGID(消息ID) ALL
  

  查看输出的STATE字段，IN_FLIGHT代表未提交状态，COMMITTED代表已提交状态。

2. 使用MQ Explorer图形工具 #

找到目标队列，右键选择「浏览消息」，消息列表的「状态」列会将未提交消息标记为「正在处理」；也可查看队列属性的「统计信息」标签页，其中的「未提交的消息数」可直接查看相关数据。

三、代码问题分析与缓解方案 #

你提供的Java代码中使用了MQGMO_BROWSE_NEXT选项，该选项会让Browse游标每次向后移动一位——如果遇到未提交的消息，游标会直接跳过它，后续的Browse操作只会从当前游标位置往后查找，不会回头扫描队列头部的滞留消息，这正是你遇到「第一条消息被跳过、后续消息正常获取」的核心原因。

具体解决办法： #

1. 定期将游标重置到队列头部
   可以在每循环N次操作后，或Get操作超时后，使用MQGMO_BROWSE_FIRST将游标拉回队列开头，确保不会遗漏已提交的滞留消息：

   // 示例：自定义判断逻辑，比如每10次操作或超时后重置游标
   boolean needResetCursor = checkNeedReset(); 
   if (needResetCursor) {
       MQMessageOptions.Options = MQC.MQGMO_BROWSE_FIRST + MQC.MQGMO_WAIT + MQC.MQGMO_FAIL_IF_QUIESCING;
       queueIn.Get(queueMessage, MQMessageOptions);
       // 重置完成后切回BROWSE_NEXT模式
       MQMessageOptions.Options = MQC.MQGMO_BROWSE_NEXT + MQC.MQGMO_WAIT + MQC.MQGMO_FAIL_IF_QUIESCING;
   } else {
       queueIn.Get(queueMessage, MQMessageOptions);
   }
   

2. 添加MQGMO_ALL_MSGS_AVAILABLE选项
   该选项会让MQ在Get操作时扫描所有可用消息，包括之前因未提交被跳过、现已提交的消息，避免游标遗漏：

   MQMessageOptions.Options = MQC.MQGMO_BROWSE_NEXT + MQC.MQGMO_WAIT + MQC.MQGMO_FAIL_IF_QUIESCING + MQC.MQGMO_ALL_MSGS_AVAILABLE;
   

3. 缩短未提交事务的时长
   排查SAP端或消息生产者的事务逻辑，确保消息发送后及时提交；若为消费者端问题，也要保证Get消息后及时确认或提交事务，避免消息长时间处于未提交状态。

4. 按需用MQOO_INPUT_EXCLUSIVE替代MQOO_INPUT_SHARED
   如果队列不需要多消费者共享访问，使用排他访问模式可减少共享访问带来的消息状态不一致问题，但注意该模式会限制队列只能被一个消费者访问。

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