java JMS消息。模型是否包含数据或指向数据的指针？

Question

我试图解决我们两人都没有JMS经验的设计分歧

我们希望在发生新事件时使用JMS在j2ee应用程序和独立应用程序之间进行通信。我们将使用单点对点队列。双方都是基于Java的。问题在于是在JMS消息体中发送事件数据本身，还是发送指向数据的指针，以便独立程序可以检索它。详情如下

我有一个j2ee应用程序，它支持新的和更新的人员以及相关事件的数据输入。人员记录和相关事件将写入Oracle数据库。还有一些独立的、独立的程序向数据库提供新的人员和事件记录。当通过5-10个不同的应用程序功能中的任何一个发生新事件时，我需要使用行业特定的标准消息传递协议通过出站接口通知远程系统。出站接口被设计为一个独立的应用程序，通过异步操作和将其移动到单独的服务器来支持可伸缩性

在输入事件时，j2ee应用程序当前在内存中拥有大部分数据。数据将由大约6个不同的对象组成；一个person对象，有些对象具有多个实例，平均大小在3000到20000字节之间。一些特殊情况下可能是这个数量的许多倍

从性能和可靠性的角度来看，我应该对JMS消息进行建模以传递创建接口消息所需的所有数据，还是对JMS消息进行建模以包含数据的记录键并让独立Java应用程序检索数据以创建接口消息

Answer 1

队列处理数据不会有问题，队列中的消息无论如何都会被持久化（内存、文件或数据库持久化，任何适合队列大小的都可以）

如果您只是将句柄放在队列中，那么处理队列的应用程序将进行不必要的工作，以获取发送方已经拥有的数据

Answer 2

发送数据，而不是指针。我不会认为你的信息是一个无法处理的特殊大小。

Answer 3

我不会只关注决策的性能，还会关注其他非功能性因素

我一直在开发一个系统，我们决定不发送消息中的数据，而是发送数据库中数据的PK。我们的方法更接近command message模式。我们的选择出于以下原因：

• 数据大小：我们会将数据存储在BLOB中，因为它可能会影响hughe。在您的情况下，数据的大小可能适合消息分析
• 消息丢失：我们的计划是更糟的。如果消息丢失，我们可以恢复数据，我们有一个恢复过程来重新提交消息。看起来可能有点偏执，但有两种情况可能会导致某些消息丢失：（1）队列被错误清除（2）发生错误，消息长时间无法传递。它们进入死消息队列（DMQ），该队列最终达到其极限，如果配置不正确，则开始丢弃消息
• 监控：不同的消息/命令可能会更新数据库中的同一行。这很容易监控和排除故障

但是，使用JMS+数据库确实会使设计变得复杂一些：

• 分布式事务：这增加了一些复杂性，有时some problems。分布式事务与“常规”事务（如分布式超时）有细微的区别
• 持久性：代码不够直观。数据必须首先被持久化才能有PK，如果使用ORM，这会导致代码的复杂性

我想这两种方法都能奏效。我已经描述了导致我们在消息中发送数据的原因，但您的系统和要求可能不同，因此在您的情况下，在消息中发送数据可能更容易。我不能提供一个明确的答案，但我希望它能帮助你做出决定

Answer 4

根据你的问题，我不能说在你的情况下什么是最好的。当然，由于消息的大小和内容，会对性能产生影响，但首先您需要知道哪些信息需要由消息使用者发送到远程系统，特别是在可能对相同数据同时进行更新的系统中

这与您是否需要将存储在远程系统中的信息与刚刚存储在数据库中的记录版本保持同步，以及是否要将完整的历史记录传播到远程系统（由消息接收器更新）有关。因为在消息发送和队列另一端的处理之间可能会经过很多时间

假设（出于某种原因）队列中有大量消息，并且在几秒钟或几分钟内，相同对象上的三到四个更新通知到达了队列。假设第一条消息是在对记录的第四次更新完成后处理的，并且它的更新通知被放入队列中。当您只传递记录的ID时，所有四条消息将在远程系统上执行完全相同的操作，这对于其中一条来说是绝对多余的。此外，远程系统会看到四个更新，所有更新都相同，但没有对象三个中间状态的信息，因此，该系统的历史记录，如果相关，将丢失

除了这些语义含义之外，传递id或整个数据的技术原因是从消息体中打开更新的信息或从数据库中加载更新的信息是否更便宜。这取决于您希望如何序列化/反序列化内容。当您想要发送数据时，您提供的消息大小对于体面的JMS实现应该没有问题

将java对象序列化为消息时，您需要在发送者和使用者之间保持类格式的同步，并且必须清空队列，然后才能在使用者站点上更新到类的较新版本。当然，当您只是传递id时，数据库更新也同样重要

当您只是将ID发送给使用者时，您将拥有额外的数据库连接，这可能还与数据库上的负载以及获取对象所需执行的查询的复杂程度有关