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

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

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

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

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

---

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

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

队列处理数据不会有问题，队列中的消息无论如何都是持久的（内存、文件或数据库持久性，不管你的队列大小是否合适）。

---

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

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

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

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

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

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

---

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

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

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

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

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