虽然它们（ActiveMQ & Artemis）的设计目的是做同样的工作，但内部的工作方式却不同。以下是您在规划迁移时需要注意的一些最显着的体系结构差异。
在ActiveMQ中，我们有一些IO连接层的不同实现，如TCP（阻塞的）和NIO（非阻塞的）。在Artemis中，IO层是使用Netty实现的，Netty是一个NIO框架。这意味着不再需要在不同的实现之间进行选择，因为默认情况下使用非阻塞实现。
每个broker都是一个重要消息存储。大多数ActiveMQ用户都应该熟悉KahaDB。它由一个消息日志组成，用于快速存储消息（和其他命令包）日志，以及在需要时用于检索取回消息。
Artemis有自己的消息存储。它只包含仅追加的消息日志。由于分页方式的不同，不需要使用消息索引。我们一会儿再谈。在这一点上，很重要的一点是，这两个存储是不能互换的，如果需要的话，必须仔细规划数据迁移。
我们所说的分页差异是什么意思？分页是当broker无法在其内存中保存所有传入消息时发生的过程。如何处理这种情况的策略在两个broker之间是不同的。ActiveMQ有一些游标，这些游标基本上是准备发送给使用者的消息的缓存。它将尝试将所有传入的消息保存在缓存。当可用内存用完时，消息会添加到存储中，但缓存会停止。当空间再次可用时，broker将通过批量从存储中提取消息来再次填充缓存。因此，我们需要在broker运行时，经常地读取日志。为了做到这一点，我们需要维护日志索引，以便在日志中跟踪消息的位置。
在Artemis中，在这方面的工作是不同的。整个消息日志保存在内存中，并直接从中发送消息。当内存耗尽时，消息会在生产者端进行分页（在消息到达broker之前）。它们按到达时的顺序存储在连续的页面文件中。一旦释放内存，消息就会从这些页面文件移到日志中。对于这样的分页工作，只有在broker启动时才从文件日志读取消息，以便在内存中重新创建日志的这个版本。在这种情况下，日志只能按顺序读取，这意味着不需要在日志中保留消息索引。
近期评论