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文件 |