我正在设计一个系统，该系统使用 ETL 工具来检索成批数据，即插入/更新/删除一个或多个表，并将它们放在一个 JMS 主题上，以便稍后由多个客户端处理。现在，关于该主题的每条消息都代表一个单独的记录 I/U/D，我们有一条特殊的消息来分隔批处理的结尾。在单个事务中处理批处理很重要，因此用一个特殊的消息分隔一堆消息并不理想:发布和接收消息的 session 都必须为多条消息设计；批定界符消息是一个困惑的解决方案(每次我们收到一条消息时，我们都需要检查它是否是最后一条消息)并且非常容易出错；系统难以调试和维护；有关该主题的消息数量迅速变得庞大(高达数百万)。
现在，我认为改进架构的下一个自然步骤是将所有记录打包到单个 JMS 消息中，这样当收到消息时，它包含单个事务，很容易检测到故障，没有关于该主题的“孤儿”记录等。我只看到这样做的好处!现在这是我的问题:
- 创建如此紧凑的消息的最佳方式是什么？我认为我的选择是
StreamMessage、ByteMessage或ObjectMessage。我排除了文本和 map 消息，因为第一个需要文本解析，这会降低性能，而且我认为第二个似乎不适合这种情况。我有点倾向于StreamMessage，因为它看起来非常紧凑，尽管它需要大量工作来编写自定义序列化代码(对于 ByteMessage 来说更糟)。不确定 ObjectMessage，它的性能如何？是否有开箱即用的解决方案？ - 每封邮件允许的最大大小是多少？可能是数百 KB 甚至几 MB 的数量级？
谢谢你的想法!
乔瓦尼
最佳答案
您可以使用两个(或更多)队列、相关 ID 和一个消息选择器，而不是使用一条大消息。
排队:
- 将通知消息发布到“通知队列”以指示应该开始处理
- 将相关 ID 设置为通知消息消息 ID 的命令消息发布到“命令队列”(如果队列深度太高，您可以使用多个命令队列)
- 提交交易
处理:
- 从“通知队列”接收通知消息(例如使用消息驱动的 bean)
- 使用消息选择器接收并处理来自“命令队列”的所有相关消息
- 提交交易
关于java - 如何设计包含大量数据的JMS消息，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15662146/