1

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

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

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

4

2 回答 2

2

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

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

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

于 2013-09-25T21:23:15.700 回答
1

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

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

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

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

于 2013-09-25T16:11:46.553 回答