我正在对 (Java) 消息传递和队列系统进行贸易研究，以便即将重新设计主要 Web 应用程序的后端框架（在 Amazon 的 EC2 云上，x-large 实例）。我目前正在评估 ActiveMQ 和 RabbitMQ。
计划是有 5 个不同的队列，其中一个是死信队列。每天发送的消息数量将在 40K 到 400K 之间。由于我计划将消息内容作为指向数据存储中 XML 文件位置的指针，因此我希望消息大约为 64 个字节。但是，出于评估目的，我还想考虑在消息中发送原始 XML，平均文件大小为 3KB。
我的主要问题：每天应该在什么时候/多少条消息被持久化？考虑到我上面指定的数量，保留所有消息是否合理？我知道坚持会降低性能，也许会降低很多。但是，由于不持久化，正在使用大量 RAM。你们中的一些人会推荐什么？
另外，我知道网上有很多关于 ActiveMQ (JMS) 与 RabbitMQ (AMQP) 的信息。我已经进行了大量的研究和测试。似乎任何一种实现都适合我的需求。考虑到我上面提供的信息（文件大小和消息数量），任何人都可以指出使用我可能错过的特定供应商的原因吗？
谢谢！
When/how many messages should be persisted on a daily basis? Is it reasonable to persist all messages, considering the amounts I specified above?
JMS persistence doesn't replace a database, it should be considered a short-lived buffer between producers and consumers of data. that said, the volume/size of messages you mention won't tax the persistence adapters on any modern JMS system (configured properly anyways) and can be used to buffer messages for extended durations as necessary (just use a reliable message store architecture)
I know that persisting will decrease performance, perhaps by a lot. But, by not persisting, a lot of RAM is being used. What would some of you recommend?
in my experience, enabling message persistence isn't a significant performance hit and is almost always done to guarantee messages. for most applications, the processes upstream (producers) or downstream (consumers) end up being the bottlenecks (especially database I/O)...not JMS persistence stores
Also, I know that there is a lot of information online regarding ActiveMQ (JMS) vs RabbitMQ (AMQP). I have done a ton of research and testing. It seems like either implementation would fit my needs. Considering the information that I provided above (file sizes and # of messages), can anyone point out a reason(s) to use a particular vendor that I may have missed?
I have successfully used ActiveMQ on many projects for both low and high volume messaging. I'd recommend using it along with a routing engine like Apache Camel to streamline integration and complex routing patterns
消息传递系统必须用作临时存储。应用程序应设计为尽快提取消息。消息数量越多，性能就越差。如果您正在提取消息，那么将有更好的性能以及更少的内存使用。是否仍将使用持久性内存，因为消息将保留在内存中以获得更好的性能，并且如果消息类型仅是持久性的，则会在磁盘上备份。
消息持久性的决定取决于消息的重要性以及它是否需要在消息传递提供程序重新启动后继续存在。
您可能想看看 IBM WebSphere MQ。它可以满足您的要求。它具有 JMS 以及用于开发应用程序的专有 API。
ActiveMQ 是开源 JMS 的不错选择，我可以推荐更昂贵的 TIBCO EMS 或 Solace。
但是 JMS 实际上是为一次性交付而构建的，规范中省略了更长的持久性。你当然可以去数据库，但这很重而且可能很昂贵。
我会推荐（注意：我为 CodeStreet 工作）是我们的“JMS 重播服务”。它让您可以将任何类型的 JMS 消息（或本机 WebSphere MQ 消息）存储在基于文件的高性能磁盘存储中。每条消息都会自动分配一个纳秒时间戳和一个您可以在发布时覆盖的 globalMsgID。因此，ReplayServer 可以记录 XML 消息，而您的实际消息可能只包含 globalMsgID 作为参考。也许还有一些属性？
一旦接收者接收到 globalMsgID，如果需要，它就可以从 ReplayServer 重播该消息。
但另一方面，400K*3KB 的 XML 消息对于 ActiveMQ 或其他人来说应该很容易实现。此外，您应该在发送之前压缩您的 XML 消息。