activemq -kahadb

最新推荐文章于 2023-12-30 08:20:34 发布

转载最新推荐文章于 2023-12-30 08:20:34 发布 · 1.4k 阅读

ActiveMQ 专栏收录该内容

5 篇文章

订阅专栏

自ActiveMQ5.4版本起，KahaDB成为其默认的持久化存储方式，相较于AMQ存储，KahaDB使用更少的文件描述符并提供更快的存储恢复。本文深入解析KahaDB的配置与底层实现，包括数据存储结构、日志文件、恢复机制等关键信息。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一，介绍

自ActiveMQ5.4以来，KahaDB成为了ActiveMQ默认的持久化存储方式。相比于原来的AMQ存储方式，官方宣称KahaDB使用了更少的文件描述符，并且提供了更快的存储恢复机制。

二，KahaDB存储配置

在 conf/activemq.xml 中配置如下：

<broker brokerName="broker" ... >
   <persistenceAdapter>
     <kahaDB directory="activemq-data" journalMaxFileLength="32mb"/>
   </persistenceAdapter>
   ...
</broker>

<persistenceAdapter>中指定了kahaDB，并表明数据存储在 "activemq-data"目录下，日志文件最大长度是32MB。

比如一个实际的ActiveMQ的KahaDB存储方式下的数据目录如下：

可以看出，上面directory一共有四个文件：

①db.data

它是消息的索引文件。本质上是B-Tree的实现，使用B-Tree作为索引指向db-*.log里面存储的消息。

②db.redo

主要用来进行消息恢复。

③db-*.log 存储消息的内容。对于一个消息而言，不仅仅有消息本身的数据(message data)，而且还有(Destinations、订阅关系、事务...)

the data logs contain all of the message data and all of the information about destinations, subscriptions, transactions, etc..

data log以日志形式存储消息，而且新的数据总是以APPEND的方式追加到日志文件末尾。因此，消息的存储是很快的。比如，对于持久化消息，Producer把消息发送给Broker，Broker先把消息存储到磁盘中(enableJournalDiskSyncs配置选项)，然后再向Producer返回Acknowledge。Append方式在一定程度上减少了Broker向Producer返回Acknowledge的时间。

④lock文件

另外，一些关于KahaDB的配置选项如下：

1. director: KahaDB存放的路径，默认值activemq-data
2. indexWriteBatchSize: 批量写入磁盘的索引page数量,默认值为1000
3. indexCacheSize: 内存中缓存索引page的数量,默认值10000
4. enableIndexWriteAsync: 是否异步写出索引,默认false
5. journalMaxFileLength: 设置每个消息data log的大小，默认是32MB
6. enableJournalDiskSyncs: 设置是否保证每个没有事务的内容，被同步写入磁盘，JMS持久化的时候需要，默认为true
7. cleanupInterval: 在检查到不再使用的消息后,在具体删除消息前的时间,默认30000
8. checkpointInterval: checkpoint的间隔时间，默认是5000
9. ignoreMissingJournalfiles: 是否忽略丢失的消息日志文件，默认false
10. checkForCorruptJournalFiles: 在启动的时候，将会验证消息文件是否损坏，默认false
11. checksumJournalFiles: 是否为每个消息日志文件提供checksum,默认false
12. archiveDataLogs: 是否移动文件到特定的路径，而不是删除它们，默认false
13. directoryArchive: 定义消息已经被消费过后，移动data log到的路径，默认null
14. databaseLockedWaitDelay: 获得数据库锁的等待时间(used by shared master/slave),默认10000
15. maxAsyncJobs: 设置最大的可以存储的异步消息队列，默认值10000，可以和concurrent MessageProducers设置成一样的值。
16. concurrentStoreAndDispatchTransactions:是否分发消息到客户端，同时事务存储消息，默认true
17. concurrentStoreAndDispatchTopics: 是否分发Topic消息到客户端，同时进行存储，默认true
18. concurrentStoreAndDispatchQueues: 是否分发queue消息到客户端，同时进行存储，默认true

三， KahaDB存储底层实现简单分析

下图是KahaDB的Architecture：

persist_01 (1)

从上图中可以看出：图中各个部分与KahaDB配置的存储目录下的文件是一一对应的。

①在内存(cache)中的那部分B-Tree是Metadata Cache

通过将索引缓存到内存中，可以加快查询的速度(quick retrival of message data)。但是需要定时将 Metadata Cache 与 Metadata Store同步。

这个同步过程就称为：check point。由checkpointInterval选项 决定每隔多久时间进行一次checkpoint操作。

②BTree Indexes则是保存在磁盘上的，称为Metadata Store，它对应于文件db.data，它就是对Data Logs以B树的形式索引。

有了它，Broker（消息服务器）可以快速地重启恢复，因为它是消息的索引，根据它就能恢复出每条消息的location。

如果Metadata Store被损坏，则只能扫描整个Data Logs来重建B树了，这个过程是很复杂且缓慢的。

The presence of the metadata store, however, enables the broker instance to restart rapidly. 
If the metadata store got damaged or was accidentally deleted, the broker could recover by reading the data logs,
but the restart would then take a considerable length of time.

③Data Logs则对应于文件 db-*.log，默认是32MB

Data Logs以日志形式存储消息，它是生产者生产的数据的真正载体。

The data logs are used to store data in the form of journals, 
where events of all kinds—messages, acknowledgments, subscriptions, subscription cancellations, transaction boundaries, etc.
---are stored in a rolling log

④Redo Log则对应于文件 db.redo

redo log的原理用到了“Double Write”。关于“Double Write”可参考

简要记录下自己的理解：因为磁盘的页大小与操作系统的页大小不一样，磁盘的页大小一般是16KB，而OS的页大小是4KB。而数据写入磁盘是以磁盘页大小为单位进行的，即一次写一个磁盘页大小，这就需要4个OS的页大小（4*4=16）。如果在写入过程中出现故障(突然断电)就会导致只写入了一部分数据(partial page write)

而采用了“Double Write”之后，将数据写入磁盘时，先写到一个Recovery Buffer中，然后再写到真正的目的文件中。在ActiveMQ的源码PageFile.java中有相应的实现。