我正在进行（Java）Messaging＆amp; amp;用于即将重新设计主要Web应用程序的后端框架的排队系统（在Amazon的EC2 Cloud，x-large实例上）。我目前正在评估ActiveMQ和RabbitMQ。
计划是有5个不同的队列，其中一个是死信队列。每天发送的邮件数量将介于40K到400K之间。由于我计划将消息内容作为指向数据存储上XML文件位置的指针，因此我希望消息大约为64字节。但是，出于评估目的，我还要考虑在消息中发送原始XML，平均文件大小为3KB。
我的主要问题：每天应该保留多少条消息/多少条消息？考虑到我上面指定的金额，坚持所有消息是否合理？我知道持久性会降低性能，也许会降低很多。但是，由于没有坚持，正在使用大量的RAM。你们有些人会推荐什么？
另外，我知道在线有很多关于ActiveMQ（JMS）和RabbitMQ（AMQP）的信息。我做了大量的研究和测试。看起来这两种实现都符合我的需求。考虑到我上面提供的信息（文件大小和消息数量），有人能指出使用我可能错过的特定供应商的原因吗？
谢谢！
答案 0 :(得分：5)
每天应该保留多少条消息/多少条消息？是吗 考虑到我的数量，合理地保留所有消息 上面指定的？
JMS持久性不会替换数据库，它应该被视为生成者和数据使用者之间的短暂缓冲区。也就是说，你提到的消息的数量/大小不会对任何现代JMS系统上的持久性适配器征税（无论如何都要正确配置），并且可以根据需要用于缓冲消息延长的持续时间（只需使用reliable message store architecture）
我知道坚持会降低性能，也许会降低很多。 但是，由于没有坚持，正在使用大量的RAM。会有什么 你推荐吗？
根据我的经验，启用消息持久性并不是一个重要的性能损失，并且几乎总是用来保证消息。对于大多数应用程序，上游（生产者）或下游（消费者）的流程最终成为瓶颈（尤其是数据库I / O）...而不是JMS持久性存储
另外，我知道网上有很多关于的信息 ActiveMQ（JMS）与RabbitMQ（AMQP）。我做了很多研究 测试。看起来这两种实现都符合我的需求。 考虑我上面提供的信息（文件大小和＃of 消息），任何人都可以指出使用特定供应商的原因 我可能错过了吗？
我已成功在许多项目中使用ActiveMQ进行低容量和高容量消息传递。我建议将其与Apache Camel之类的路由引擎一起使用，以简化integration和complex routing patterns
答案 1 :(得分：4)
必须将消息传递系统用作临时存储。应用程序应设计为尽快提取消息。消息数量越多，性能越差。如果您正在提取消息，那么将会有更好的性能以及更少的内存使用量。是否仍将使用持久性或非持久性内存，因为消息将保留在内存中以获得更好的性能，并且如果消息类型仅为持久性，则将备份在磁盘上。
有关消息持久性的决定取决于消息的重要性，以及消息提供程序重新启动后是否需要它。
您可能希望了解IBM WebSphere MQ。它可以满足您的要求。它具有JMS以及用于开发应用程序的专有API。
答案 2 :(得分：0)
ActiveMQ是开源JMS的不错选择，我推荐的更贵的是TIBCO EMS或Solace。
但JMS实际上是为一次性交付而构建的，并且更长的持久性被排除在规范之外。你当然可以去数据库，但这个重量很大，可能很贵。
我建议（注意：我为CodeStreet工作）是我们的JMS＆＃39; ReplayService。它允许您将任何类型的JMS消息（或本机WebSphere MQ消息）存储在基于文件的高性能磁盘存储中。每条消息都会自动分配一个纳秒时间戳和一个globalMsgID，您可以在发布时覆盖它。因此，ReplayServer可以记录XML消息，您的实际消息可能只包含globalMsgID作为参考。也许有些属性？
接收方收到globalMsgID后，如果需要，它可以从ReplayServer重播该消息。
但另一方面，对于ActiveMQ或其他人来说，400K * 3KB XML消息应该很容易实现。此外，您应该在发送之前压缩XML消息。