消息在消息代理 Q 中可以有效停留多长时间答案

【问题标题】：How long could effectively message stay in Message broker Q消息在消息代理 Q 中可以有效停留多长时间
【发布时间】：2013-10-01 03:37:24
【问题描述】：

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

我基本上打算将消息代理用作另一个持久层。这可行吗？

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

【问题讨论】：

标签： jms persistence message-queue amqp middleware

【解决方案1】：

我打算使用消息代理作为另一个持久层基本上。这可行吗？

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

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

【讨论】：

【解决方案2】：

拥有持久队列是可以的，如果消息在队列中徘徊也没关系：客户端可能由于更新、网络问题等而断开连接。这是队列将发送者与接收者分离的好处之一，队列是缓冲。然而，这些用例并不是正常的操作模式，而是一种特殊情况。

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

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

还有另一个方面：考虑需要在 JMS 提供程序中在线备份您的消息，尤其是在 HA 集群模式下。使用数据库可能更容易做到这一点。

【讨论】：

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