持久性在ActiveMQ Artemis中如何工作？

问题描述

在ActiveMQ 5.x中，使用kahadb进行持久化时，所有文件都在单个数据库中进行管理。这可能会带来严重的后果。

我有数百个队列，每天看到数百万条消息。如果出于维护原因临时停止队列的使用者，则队列将继续填充并排空，并且其使用者被挂起的队列将看到消息堆积。但是在光盘上却有所不同。 Kahadb确实标记了已删除（已使用）的消息，但是如果数据库中保留了更多的当前消息，则无法释放该位置。对于那些在暂停队列中累积的情况就是这种情况。 很快磁盘空间已满。 为了解决这个问题，您必须更改配置并使用mkahadb。在这种情况下，每个队列只有一个数据库，因此在磁盘上只有挂起的队列会占用空间。

我正在考虑改用Artemis。但是持久性已被完全重新设计。那么，在暂停使用方时，在磁盘占用方面会发生什么？

解决方法

这个问题范围很广，但是我会解决的...

默认情况下，ActiveMQ Artemis使用基于文件的日志。日志由可以根据配置增长和收缩的文件池组成（请参阅the documentation中的journal-min-files和journal-pool-files）。每个文件的大小也是可以配置的（即通过journal-file-size）。

当代理启动时，将在存储消息时创建初始文件池，并且初始文件池已满，然后将创建其他文件。随着消息的消耗，池可以通过称为“压缩”的过程来收缩，该过程也是可配置的（请参见the documentation中的journal-compact-min-files和journal-compact-percentage）。只要日志文件中的1条记录被视为“实时”（例如，未使用的消息），则整个日志文件将保留。但是，您可以调整此操作的影响以适合您的环境（例如，降低journal-file-size，使压缩更加积极，等等）。要明确的是，如果运行压缩并且有一个日记文件只有1个“活动”记录，则意味着所有其他日记文件都是“已满”，并且最多您将只有1个这样的日记文件。

此外，您可以配置max-disk-usage来阻止生产者在磁盘利用率达到某一点时发送更多消息。

最终，如果使用者变为非活动状态（无论出于何种原因），则该使用者应接收的消息将堆积在队列中（并可能在磁盘上）。如果您想首先避免消息堆积，则可以为生产者实现flow control或blocking。但是，即使它们确实积累了基于文件的日志，也应该能够根据需要进行增大和缩小。

,

如果我理解正确，则无法保证仅保留有效负载。 （与mkahadb一样） 但是我们可以限制页面的大小并固定页面的数量。

考虑到我必须管理的大量队列，我认为最好的方法是将其划分为一个集群。但是我很担心。因为当一个应用程序处于维护状态（我有1万个）时，其他应用程序的消息无法删除，因为这些消息在队列中累积。显然，无论如何配置，我都会在几秒钟内崩溃或停止。

我很惊讶地看到两个应用程序之间停止通信，因为另外两个应用程序不再相互通信。与ActiveMQ相比，这是一个强大的限制。

,

这会限制问题，但不能解决问题。 使用 mkahadb，如果我有 2 个队列 A 和 B，则 A 每秒接收一条消息，B 接收 5000/s，B 的使用者立即使用它们。队列 B 总是空的或几乎是空的，占用的磁盘很少。如果 A 的消费者停止。队列A增加但队列B没有占用更多的磁盘。

如果我将日志大小减少到 5000，使用 Artemis。每秒一个日志文件已满并被删除。如果 A 停止，则日志中必须有来自 A 的 1 条消息。因此，我们每秒在磁盘上保留 5000 条消息。尽管队列 B 几乎总是空的。如果我将日志大小减少到 500，我会保留更少的消息，但它的增长速度仍然比使用 mkahaDB 快 500 倍。如果我将日志减少到 1 以获得与 mkahadb 相同的结果，但我会强制 Artemis 处理数百万个文件，这会导致性能崩溃。

我的印象是，Artémis 并没有像 ActiveMQ 那样拥有非常多的队列。 谢谢