当阅读artemis时，文档了解-artemis将整个当前活动消息存储在内存中，并可以根据设置将消息卸载到给定队列/主题的分页区域&artemis期刊仅为附后。
关于此
- broker如何以及何时将消息同步到日志以及从日志同步消息(仅在重新启动期间？(
- 它如何识别要从日志中删除的消息(例如：如果日志是仅追加模式，如果持久消息的使用者确认消息，那么broker如何在不保持索引的情况下从日志中移除单个消息(
- 将每一条活动消息都保存在内存中，甚至使broker耗尽内存，这难道不是一个性能打击吗。为了避免这种情况，必须在配置中设置每个队列/主题分页设置，否则代理可能会填充所有消息。如果错了，请纠正我
任何可以解释消息同步和这些信息的参考链接都很有用。Artemis文档解释了仅附加模式，但可能是解释这些存储概念的任何章节/文章，我可能会遗漏。
默认情况下，在代理接收到持久消息之后，在代理向客户端发送收到消息的响应之前，持久消息将持久保存到磁盘。通过这种方式，客户端可以确信，如果它从代理接收到响应，则它发送的持久消息已被接收并持久化到磁盘。
当使用broker.xml中的NIOjournal-type(即默认配置(时，使用java.nio.cahannels.FileChannel.force(布尔值(.将数据同步到磁盘
由于日志仅在正常操作期间附加，因此当确认消息时，它实际上不会从日志中删除。代理程序只是将一条删除记录附加到该特定消息的日志中。该消息随后将在"删除"期间从日志中物理删除；压实"；。该过程由CCD_ 4&CCD_ 6中的CCD_。有关详细信息，请参阅文档。
将消息数据保留在内存中实际上大大提高了性能，而不是将其从内存中逐出，然后再从磁盘中读回。正如您所注意到的，这可能会导致内存消耗问题，这就是为什么代理支持分页、阻塞等。需要记住的主要一点是，消息代理不像数据库那样是存储介质。寻呼是一种缓和措施，旨在作为保持经纪人运作的最后手段。理想情况下，应该将代理配置为在不分页的情况下处理预期负载(例如，获取更多RAM、分配更多堆(。换句话说，消息生产和消息消费应该是平衡的。代理程序是为消息流经而设计的。它当然可以缓冲消息(根据配置和硬件的不同，可能有数百万条(，但当它被迫分页时，性能会大幅下降，因为磁盘比RAM慢几个数量级。