消息分组可以做消息分段做的事情吗？

Question

我正在开发一个用java编写的微服务，它将消息放到一个队列中。由于我使用的是JMS，因此无法使用消息分段来处理大消息。我想知道，消息分组是否也允许我处理大消息？所谓大消息，我指的是比MaxMsgLength更大的消息。

Answer 1

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

现在，如果您希望手动拆分大消息，并将其作为多个较小的单独JMS消息发送，那么我可以看到消息分组在哪里有助于重新组装消息，因为组中的每个消息都将由单个使用者串行使用。然而，消费者也有可能在消费整个组的过程中部分失败，因此在确认任何消息之前，您需要确保使用组中的所有消息，否则您可能会丢失无法找回的大消息的一部分。在任何情况下，消费者都必须知道如何在获得所有片段后重新组装消息，但这可以像按顺序将每个消息的字节添加到缓冲区中一样简单。

Answer 2

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

尝试压缩数据。文本数据具有很高的压缩率，您可以将其限制在100MB的IBM MQ产品限制之下。

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

分解消息组中的消息很难重组，b/c很多代码都假定消息是按顺序接收的。为了正确地处理它，你需要返回seek()'n文件的位置，并跟踪是否有任何‘块’不符合它。