lit*_*leK 8 messaging activemq-classic jms amqp rabbitmq
我正在对(Java)消息传递和排队系统进行贸易研究,以便即将重新设计主要Web应用程序的后端框架(在Amazon的EC2 Cloud,x-large实例上).我目前正在评估ActiveMQ和RabbitMQ.
计划是有5个不同的队列,其中一个是死信队列.每天发送的邮件数量将介于40K到400K之间.由于我计划将消息内容作为指向数据存储上XML文件位置的指针,因此我希望消息大约为64字节.但是,出于评估目的,我还想考虑在消息中发送原始XML,平均文件大小为3KB.
我的主要问题:每天应该保留多少条消息/多少条消息？考虑到我上面指定的金额,坚持所有消息是否合理？我知道持久性会降低性能,也许会降低很多.但是,由于没有坚持,正在使用大量的RAM.你们有什么建议的？
此外,我知道在线有关于ActiveMQ(JMS)和RabbitMQ(AMQP)的大量信息.我做了大量的研究和测试.看起来这两种实现都符合我的需求.考虑到我上面提供的信息(文件大小和消息数量),任何人都可以指出使用我可能错过的特定供应商的原因吗？
谢谢!
每天应该保留多少条消息/多少条消息？考虑到我上面指定的金额,坚持所有消息是否合理？
JMS持久性不会替换数据库,它应该被视为生成者和数据使用者之间的短暂缓冲区.也就是说,你提到的消息的数量/大小不会对任何现代JMS系统上的持久性适配器征税(无论如何都正确配置),并且可以根据需要用于缓冲消息延长的持续时间(只需使用可靠的消息存储架构)
我知道持久性会降低性能,也许会降低很多.但是,由于没有坚持,正在使用大量的RAM.你们有什么建议的？
根据我的经验,启用消息持久性并不是一个重要的性能损失,并且几乎总是用来保证消息.对于大多数应用程序,上游(生产者)或下游(消费者)的流程最终成为瓶颈(尤其是数据库I/O)...而不是JMS持久性存储
此外,我知道在线有关于ActiveMQ(JMS)和RabbitMQ(AMQP)的大量信息.我做了大量的研究和测试.看起来这两种实现都符合我的需求.考虑到我上面提供的信息(文件大小和消息数量),任何人都可以指出使用我可能错过的特定供应商的原因吗？
我已成功在许多项目中使用ActiveMQ进行低容量和高容量消息传递.我建议将它与Apache Camel这样的路由引擎一起使用,以简化集成和复杂的路由模式