ActiveMQ中,持久化是指对消息数据的持久化。在ActiveMQ中,默认的消息是保存在内存中的,当内存容量不足,或ActiveMQ正常关闭的时候,会将内存中未处理的消息持久化到磁盘中。具体的持久化策略由配置文件中的具体配置决定。
ActiveMQ的默认存储策略是kahaDB
如果使用JDBC作为持久化策略,则会将所有需要持久化的消息保存到数据库中。
所有的持久化配置都在 conf\activemq.xml 配置文件中,配置信息都在 broker 标签内部定义。
kahaDB方式
是ActiveMQ默认的持久化策略,kahaDB是一个文件型数据库,是使用内存+文件保证数据的持久化。
kahaDB可以限制每个数据文件的大小,不代表总计数据容量。
特性:
- 日志形式存储消息
- 消息索引以B-Tree结构存储,可以快速更新
- 完全支持JMS事务
- 支持多种恢复机制
<persistenceAdapter>
<kahaDB directory="${activemq.data}/kahadb" journalMaxFileLength="16mb"/>
</persistenceAdapter>
kahaDB的配置选项如下
属性 | 默认值 | 描述 |
indexWriteBatchSize | 1000 | 当Metadata Cache中更新的索引到达了1000时,才同步到磁盘上的Metadata Store中。不是每次更新都写磁盘,而是批量更新写磁盘,比较写磁盘的代价是很大的 |
indexCacheSize | 10000 | (number of index pages cached in memory),在内存中最多分配多个页面来缓存index。缓存的index越多,命中的概率就越大,检索的效率就越高 |
journalMaxFileLength | 32MB | 当存储的消息达到32MB时,新建一个新文件来保存消息。这个配置对生产者或消息者的速率有影响。比如,生产者速率很快而消费者速率很慢时,将它配置得大一点比较好 |
enableJournalDiskSyncs | true | 默认采用同步写磁盘,即消息先存储到磁盘中再向Producer返回ACK |
cleanupInterval | 30000ms | 当消息被消息者成功消费之后,Broker就可以将消息删除了 |
checkpointInterval | 5s | 每隔5s将内存中的Index(Metadata Cache)更新到磁盘的Index文件中(Metadata Store) |
一个实际的ActiveMQ的KahaDB存储方式下的数据目录如下
可以看出,上面directory一共有四个文件
db.data | 它是消息的索引文件。本质上是B-Tree的实现,使用B-Tree作为索引指向db-*.log里面存储的消息 |
db.redo | 主要用来进行消息恢复 |
db-*.log | 存储消息的内容。对于一个消息而言,不仅仅有消息本身的数据(message data),而且还有(Destinations、订阅关系、事务...) |
lock | lock文件 |