本文深入剖析 IBM MQ 中 persistent 与 non-persistent 消息在事务提交机制、资源占用、日志行为及队列管理器（QMGR）内部调度上的本质区别，解释为何相同配置下非持久化场景可绕过 MQRC_Q_FULL 错误，而持久化场景易触发队列满异常。
本文深入剖析 ibm mq 中 persistent 与 non-persistent 消息在事务提交机制、资源占用、日志行为及队列管理器（qmgr）内部调度上的本质区别，解释为何相同配置下非持久化场景可绕过 `mqrc_q_full` 错误，而持久化场景易触发队列满异常。
在 IBM MQ 的事务模型中，“持久化（Persistent）”与“非持久化（Non-Persistent）”绝非仅关乎“重启后消息是否丢失”这一表层特性——其根本差异深植于事务生命周期管理、磁盘 I/O 路径、日志同步策略以及队列管理器对未提交消息的资源预留机制之中。
一、事务语义的本质分野
-
Persistent 消息：必须经由 事务日志（Linear Log）严格落盘并完成 fsync 才被视为“可提交”。在
MQPMO_SYNCPOINT（或隐式 syncpoint）事务上下文中，每条持久化消息在MQPUT后即被写入日志缓冲区，并在MQCMIT时触发日志强制刷盘（log commit）。此时，QMGR 会为该事务内所有未提交消息预留队列空间 + 日志空间双重资源。 -
Non-Persistent 消息：不写入事务日志，仅暂存于内存页（message pages）或共享内存中。即使处于事务内，
MQCMIT仅需将消息从暂存区移至目标队列的内存索引结构，无需磁盘 I/O 等待。因此，其资源开销极低，且不受日志空间与MAXUNCOMMITTED的强耦合约束。
✅ 关键事实：
MAXUNCOMMITTED参数（如您设置的 1000）仅对持久化消息生效。MQ 文档明确指出：“This attribute applies only to persistent messages. Non-persistent messages are not counted toward the maximum.”（IBM MQ v9.3 Docs）
这直接解释了您的 第2次运行成功的原因：当 QMGR 默认设为 DEFPSIST(NO) 或应用显式发送 MQPER_NOT_PERSISTENT 消息时，两条并发批处理线程产生的消息均不计入 MAXUNCOMMITTED 限额——它们在内存中快速流转，无日志压力，自然不会触发 MQRC_Q_FULL（队列满）错误。
二、为什么第1次运行失败？——持久化事务的“双重水位线”
当 DEFPSIST(YES) 且消息标记为 MQPER_PERSISTENT 时，QMGR 对事务施加两层资源控制：
| 控制维度 | 行为说明 |
|---|---|
| 队列深度水位 |
CURDEPTH 实时统计已入队（含未提交）消息数，受 MAXDEPTH 限制 |
| 未提交配额水位 |
MAXUNCOMMITTED 限制单个事务内最大未提交持久化消息数（默认 1000） |
在您的场景中：
- 每个批处理线程在事务内
MQPUT1000 条持久化消息 → 触发MAXUNCOMMITTED = 1000阈值； - 此时若另一线程也尝试
MQPUT第1条消息，QMGR 判定其事务已超配额，拒绝入队并返回MQRC_Q_FULL（注意：这不是队列物理满，而是事务配额满）； - 即使
MAXDEPTH远高于 2000，该错误仍会发生——因MAXUNCOMMITTED是独立于MAXDEPTH的硬性事务级闸门。
✅ 第3次运行成功（MAXUNCOMMITTED=10000）印证了这一点：提升该参数后，两个 1000 条消息的事务均可被容纳。
三、代码实践建议：显式控制，避免隐式陷阱
切勿依赖隐式 syncpoint（如未传 MQPMO_SYNCPOINT 但开启 MQOO_OUTPUT 时可能自动启用），务必显式声明：
// Java/JMS 示例：显式事务 + 持久化控制
MQQueue queue = qMgr.accessQueue("MY.QUEUE",
MQC.MQOO_OUTPUT | MQC.MQOO_FAIL_IF_QUIESCING);
MQPutMessageOptions pmo = new MQPutMessageOptions();
pmo.options = MQC.MQPMO_SYNCPOINT; // 显式开启事务
MQMessage msg = new MQMessage();
msg.messageFlags = MQC.MQMF_MSG_IN_GROUP;
msg.persistence = MQC.MQPER_PERSISTENT; // 或 MQC.MQPER_NOT_PERSISTENT
queue.put(msg, pmo);
qMgr.commit(); // 或 rollback()
⚠️ 注意事项：
-
MAXUNCOMMITTED是队列管理器级全局参数，修改需runmqsc命令并重启 QMGR 生效：ALTER QMGR MAXUNCOMMITTED(10000) REFRESH SECURITY TYPE(CONNAUTH)
- 非持久化消息虽规避配额限制，但牺牲可靠性：QMGR 异常崩溃或主机断电将导致内存中未消费消息永久丢失；
- 混合使用 persistent/non-persistent 消息时，需确保业务语义一致——例如，DB 更新与 MQ 发送必须同为 persistent，否则无法实现“要么全成功、要么全回滚”的分布式事务一致性。
总结
IBM MQ 的持久化事务本质是一套日志驱动、资源预占、强一致性保障的机制；而非持久化事务则是内存导向、零日志、高吞吐但弱可靠性的轻量路径。MQRC_Q_FULL 在您的案例中并非磁盘或队列空间不足，而是 MAXUNCOMMITTED 对持久化事务的精准拦截。理解这一设计哲学，是构建高可靠、可伸缩 MQ 应用的基石。
