单独限制 ActiveMQ 中队列的磁盘存储大小答案

【问题标题】：Individually limit disk storage size for queues in ActiveMQ单独限制 ActiveMQ 中队列的磁盘存储大小
【发布时间】：2015-08-25 22:59:14
【问题描述】：

ActiveMQ 是否可以使用 KahaDB 单独限制持久队列的存储大小？

我们正在使用这样的设置与 ActiveMQ 进行应用程序之间的数据交换：

[App1] ==> (Queue1) ==> [App2] ==> (Queue2) ==> [App3]

数据流是从 App1 通过 Q1（持久）从 App1 到 App2，然后从 App2 通过 Q2（也是持久）从 App2 到 App3。现在，当 App2 确认消息时，来自 Q1 的消息被删除，当 App3 确认时，来自 Q2 的消息被删除。当 App2 不可用时 App1 填满队列时，就会出现问题。然后，当它再次可用时，App2 将缓冲的消息并尝试将它们发送给 App3，但是由于一些开销，放入 Q2 的消息比 Q1 上的消息大，并且 App2 仅在成功放入 Q1 时才 ACK 消息进入 Q2 并阻塞，直到后者成为可能。因此，系统处于死锁状态，因为没有消息从 Q1 和 Q2 中取出。

现在，我们想到的这个问题的一个解决方案是单独限制队列的存储空间（例如 Q1 和 Q2 各使用 10 GB），这样完整的 Q1 就不会干扰 Q2，但我们是无法配置 ActiveMQ 来执行此操作，而不是使用 mKahaDB（仍然是相同的死锁）或使用生产者流控制。我们找到的几乎所有设置都用于内存，并且似乎不适用于磁盘存储。有没有办法实现这种分离？

【问题讨论】：

标签： activemq

【解决方案1】：

虽然似乎不存在限制每个队列的实际磁盘存储使用的配置，但通过对不同的队列使用不同的storeUsageHighWaterMark 目标策略，我们能够避免死锁，因为现在总是为 Q2 保留一些空间。

【讨论】：

【解决方案2】：

您应该使用流控制根据您的阈值待处理消息计数在 Q1 中停止接受消息，这样 Q2 仍然可以继续。您还可以为队列 Q1 和 Q2 使用不同的 KahaDB 文件（如果您的 activeMQ 版本支持）对 DB 文件大小尚无可用控制。

【讨论】：