何时在 Java 消息传递和队列系统中使用持久性

Posted 2023-03-10

【中文标题】何时在 Java 消息传递和队列系统中使用持久性

【英文标题】：When to use persistence with Java Messaging and Queuing Systems

【发布时间】：2012-09-22 07:43:03

【问题描述】：

我正在对 (Java) 消息传递和队列系统进行贸易研究，以便即将重新设计主要 Web 应用程序的后端框架（在 Amazon 的 EC2 云上，x-large 实例）。我目前正在评估 ActiveMQ 和 RabbitMQ。

计划有 5 个不同的队列，其中一个是死信队列。每天发送的消息数量将在 40K 到 400K 之间。由于我计划将消息内容作为指向数据存储中 XML 文件位置的指针，因此我希望消息大约为 64 个字节。但是，出于评估目的，我还想考虑在消息中发送原始 XML，平均文件大小为 3KB。

我的主要问题：每天应该在什么时候/多少条消息被持久化？考虑到我上面指定的数量，保留所有消息是否合理？我知道坚持会降低性能，也许会降低很多。但是，由于不持久化，正在使用大量 RAM。你们中的一些人会推荐什么？

另外，我知道网上有很多关于 ActiveMQ (JMS) 与 RabbitMQ (AMQP) 的信息。我已经进行了大量的研究和测试。似乎任何一种实现都适合我的需求。考虑到我在上面提供的信息（文件大小和消息数量），任何人都可以指出使用我可能错过的特定供应商的原因吗？

谢谢！

【参考方案1】：

ActiveMQ 是开源 JMS 的不错选择，我可以推荐更昂贵的 TIBCO EMS 或 Solace。

但 JMS 实际上是为一次性交付而构建的，规范中省略了更长的持久性。您当然可以使用数据库，但这很重而且可能很昂贵。

我会推荐（注意：我为 CodeStreet 工作）的是我们的“JMS 重播服务”。它让您可以将任何类型的 JMS 消息（或本机 WebSphere MQ 消息）存储在基于文件的高性能磁盘存储中。每条消息都会自动分配一个纳秒时间戳和一个您可以在发布时覆盖的 globalMsgID。因此，ReplayServer 可以记录 XML 消息，而您的实际消息可能只包含 globalMsgID 作为参考。也许还有一些属性？

一旦接收者接收到 globalMsgID，如果需要，它就可以从 ReplayServer 重播该消息。

但另一方面，400K*3KB 的 XML 消息对于 ActiveMQ 或其他人来说应该很容易实现。此外，您应该在发送之前压缩您的 XML 消息。

【参考方案2】：

消息传递系统必须用作临时存储。应用程序应设计为尽快提取消息。消息数量越多，性能就越差。如果您正在提取消息，那么将有更好的性能以及更少的内存使用。是否仍将使用持久性内存，因为消息将保留在内存中以获得更好的性能，并且如果消息类型仅是持久性的，则会在磁盘上备份。

关于消息持久性的决定取决于消息的重要性以及它是否需要在消息传递提供程序重新启动后继续存在。

您可能想看看 IBM WebSphere MQ。它可以满足您的要求。它具有 JMS 以及用于开发应用程序的专有 API。

【参考方案3】：

每天应该在什么时候/多少条消息被持久化？是吗 合理地持久化所有消息，考虑到我的数量 上面指定了吗？

JMS 持久性不会取代数据库，它应该被视为数据的生产者和消费者之间的短期缓冲区。也就是说，您提到的消息的数量/大小不会对任何现代 JMS 系统（无论如何配置正确）上的持久性适配器征税，并且可用于根据需要在更长的时间内缓冲消息（只需使用 reliable message store architecture）

我知道坚持会降低性能，也许会降低很多。 但是，由于不持久化，正在使用大量 RAM。会有些什么 你推荐？

根据我的经验，启用消息持久性不会对性能造成重大影响，而且几乎总是为了保证消息而这样做。对于大多数应用程序，上游（生产者）或下游（消费者）的流程最终成为瓶颈（尤其是数据库 I/O）...而不是 JMS 持久性存储

另外，我知道网上有很多关于 ActiveMQ (JMS) 与 RabbitMQ (AMQP)。我做了很多研究和 测试。似乎任何一种实现都适合我的需求。 考虑到我上面提供的信息（文件大小和# 消息），任何人都可以指出使用特定供应商的原因 我可能错过了？

我已在许多项目中成功使用 ActiveMQ 进行低容量和高容量消息传递。我建议将它与 Apache Camel 这样的路由引擎一起使用，以简化 integration 和 complex routing patterns