消息分组可以做消息分段的作用吗？答案

【问题标题】：Can message grouping do what message segmentation does?消息分组可以做消息分段的作用吗？
【发布时间】：2021-05-02 19:35:32
【问题描述】：

我正在使用 java 中的微服务来将消息放入队列中。由于我使用 JMS，因此无法使用消息分段来处理大消息。我想知道，消息分组是否也允许我处理大消息？大消息是指大于 MaxMsgLength 的消息。

【问题讨论】：

当您说“由于我使用 JMS，消息分段无法用于处理大消息”时，您是在说自动消息分段（即自动中断将大于特定大小的消息合并为较小的单个消息）？如果不是，请详细说明“消息分段”是什么意思。谢谢！
另外，您对消息分组的想法是，组中的每条消息都可以是整个更大消息的一部分，并且一旦您消费了组中的每条消息，您就可以重新组装原始的大消息?
@JustinBertram 1. 是的，我说的是自动完成消息分段。 2. 是的，我就是这么想的。这可能吗？
您可以使用消息分组，但接收端需要知道如何将其重新组合在一起。与自动分段的不同之处在于，只要应用程序使用正确的 GET 选项，IBM MQ 队列管理器就会自动将分段放在一起。

标签： java spring-boot jms websphere ibm-mq

【解决方案1】：

JMS 本身不支持“消息分段”。但是，JMS 实现可以实现超出规范的功能。例如，ActiveMQ Artemis supports arbitrarily large messages 接收单个大消息并将其分解成块，然后通过网络传输到磁盘上，这样消息就不会立即保存在内存中。当然，这一切都是在幕后完成的。客户端应用程序只是像往常一样使用 JMS API。

现在，如果您想手动拆分大消息并发送尽可能多的较小的单独 JMS 消息，那么我可以看到消息分组有助于重新组装消息的位置，因为组将由单个消费者连续消费。但是，消费者也有可能在消费整个组的过程中中途失败，因此您需要确保在确认任何之前消费组中的所有消息> 否则，您可能会丢失无法找回的大信息片段。在任何情况下，消费者都必须知道如何在将所有部分组合在一起后重新组装消息，但这可能就像将每个消息的字节按顺序附加到缓冲区中一样简单。

【讨论】：

感谢您的建议！如果我还有任何问题，我会进一步调查并返回这篇文章！
消息分组是否与分页配合得很好？我一直在阅读并且发现它可能不适用于分页。在我的微服务中，它从 API 中获取 json 数据并遍历页面，直到到达最后一页。
我不太确定你在问什么。 JMS 并没有真正的分页概念。为什么消息分组不能很好地与分页实现配合使用？
access.redhat.com/documentation/en-us/… 我正在阅读这个。有一个重要的通知指出应该禁用分页。我已经编写了微服务来处理分页，这是否意味着我必须禁用它？
该文档中讨论的 paging 也是explained in the documentation。简而言之，就是broker在地址到达配置的max-size-bytes时进行的分页。它与您在微服务中实现的分页无关。有关代理分页（及其替代方案）的更多详细信息，请参阅文档。

【解决方案2】：

大型消息处理和消息分块与产品限制和实际最佳实践相交。 IBM MQ 对消息大小的产品限制为 100MB。 JMS 确实提供了使用 StreamMessage 类型流式传输数据的选项，但不建议将其用于任何分布式 - 这是您的用例。超时、重新连接和任何其他不愉快的路径情况都会使其难以处理。

尝试压缩数据。文本数据具有很高的压缩率，您可能能够满足 100MB 的 IBM MQ 产品限制。

IBM MQ 确实可以无限浏览队列，并且能够执行类似分页的行为。如果您使用原生 MQI API MQGMO match options（而不是 JMS），您可以使用消息组的序列号查找和访问消息（您可以像 kafka 一样消费，具有更好的持久性！）。

在消息组中分解消息很难重新组合，b/c 很多代码假定消息是按顺序接收的。要正确处理它，您需要返回 seek()'n 文件位置并跟踪是否有任何“块”没有成功。

【讨论】：