ActiveMQ_持久化机制

为了避免意外宕机以后信息丢失，需要坐到重启后可以恢复消息数据，消息系统一般都会采用持久化机制。

ActiveMQ的消息持久化机制有JDBC，AMQ，KahaDB和LevelDB，无论采用何种持久化方式，消息的存储逻辑都是相同的。

---

AMQ

是一种以文件储存的形式，适用于ActiveMQ5.3之前的版本，现在不用了。

KahaDB

基于日志文件，从ActiveMQ5.4开始，默认的持久化插件，写这篇文章时我把ActiveMQ 更新到了 5.15.10，依旧默认使用 KahaDB。

<!--
            Configure message persistence for the broker. The default persistence
            mechanism is the KahaDB store (identified by the kahaDB tag).
            For more information, see:

            http://activemq.apache.org/persistence.html
        -->
        <persistenceAdapter>
            <kahaDB directory="${activemq.data}/kahadb"/>
        </persistenceAdapter>

在${activemq.data}/kahadb目录下一般有5个文件

db-[number].log：
数据文件，当数据文件已满时，会创建一个新的文件，一般为32M一个文件。当不再引用到这个文件的数据时，会被删除或归档。

db.data：
该文件包含了持久化的 BTree 索引，它时db-.log的索引文件。

db.free：
记录当前db.data文件哪些页面是空闲的，文件内容是所有空闲页面的ID。

db.redo：
用来进行消息恢复的，如果KahaDB消息存储在强制退出后重启，用于恢复BTree索引。

lock：
文件锁，表示当前获得KahaDB读写权限的broker。

LevelDB

这种文件系统时从ActiveMQ5.8之后引进的，它和KahaDB非常相似，也是基于文件的数据库存储形式，但是它提供比KahaDB更快的持久性。不过要彻底取代KahaDB，还需要一个过程。官网上目前仍然推荐使用KahaDB。

JDBC

消息基于JDBC存储，目前大多数都使用此方式。下一篇文章，详细讲解ActiveMQ和MySql的整合。