Jms 消息可以有效地在MessageBroker Q中停留多长时间

我计划基于AMQP和JMS API的一些实现来创建持久消息队列。我想知道（从架构的角度）让消息在队列中停留数小时是否合适。最多一天

基本上，我计划将MessageBroker用作另一个持久层。这是否可行

---

我正在评估的技术是ActiveMQ、RabbitMQ或qupid。

有持久队列是可以的，如果消息在队列中徘徊也可以：客户端可能会因为更新、网络问题等而断开连接。这是队列的一个好处，可以将发送方和接收方解耦，而队列就是缓冲区。然而，这些用例不是正常的操作模式，而是一种例外情况

从技术上讲，使用消息代理作为“另一个持久层”是可能的，但在这种情况下，数据库可能更合适，因为快速消息传递/消息传递和长期存储/数据库是不同的工具/场景。因此，问问自己：它仍然是消息传递还是已经是一个数据库

如果在您的用例中，正常的消息延迟（=发送和接收之间的时间段）总是超过一小时，那么数据库可能会更好，因为JMS选择器通常比使用where子句的数据库查询更慢、更不舒适

还有另一个方面：考虑在JMS提供程序中对消息进行在线备份的必要性，特别是在HA集群模式中。使用数据库可能更容易做到这一点

我计划将MessageBroker用作另一个持久层 基本上。这是否可行

代理用于消息保留的持久性机制通常是基于文件的，或JDBC；任何一个都可以。是否可行？当然，这是代理的一个特性，将其用于预期目的没有什么错，假设临时消息保留是您的目标；一天没什么大不了的

---

但是，如果您计划将邮件保留一天或更长时间，我建议您根据平均邮件大小和每天可能会排在队列中的邮件总数进行一些计算。默认情况下，队列深度通常是一个较低的数字，比如10Mb，如果超过这个数字，代理可能会删除后续消息；你想防止这种情况发生。供应商以不同的方式处理此问题，因此请与RabbitMq和ActiveMQ联系，了解详细信息以及用于控制深度的配置参数。我知道SonicMq有所谓的“DeadMessage”队列，它是过期或无法传递消息的目的地；其他产品可能也有类似的功能

请注意，运行带有持久消息的消息代理（如RabbitMQ）的服务器实际上是一个数据库服务器，您应该相应地规划它。例如，如果您使用虚拟化服务器，请确保它使用本地硬盘作为持久消息存储，因为I/O负载与数据库服务器的负载相似。