ActiveMQ中的KahaDB消息日志的恢复机制和可靠性

         ActiveMQ很好的支持了消息的持久性(Persistence)。消息持久性对于可靠消息传递来说应该是一种比较好的方法，有了消息持久化，即使发送者和接受者不是同时在线或者消息中心在发送者发送消息后宕机了，在消息中心重新启动后仍然可以将消息发送出去，如果把这种持久化和ReliableMessaging结合起来应该是很好的保证了消息的可靠传送。

 

    消息持久性的原理很简单，就是在发送者将消息发送出去后，消息中心首先将消息存储到本地数据文件、内存数据库或者远程数据库等，然后试图将消息发送给接收者，发送成功则将消息从存储中删除，失败则继续尝试。消息中心启动以后首先要检查制定的存储位置，如果有未发送成功的消息，则需要把消息发送出去。

 

    对于ActiveMQ，消息的持久化同样是很简单的，仅仅通过配置信息就可以实现。这里主要介绍两种不同的持久化方法。

 

1。High performance journal

    这是ActiveMQ基于开源的HOWL(High-speed ObjectWeb Logger)，将HOWL扩展为可以存储任意大小的消息(HOWL只能存储固定大小的记录)，实现的一种消息持久化方法。它可以快速的将消息存储在本地文件中，且这种文件是以一种类似数据库的方式管理的。这样，如果你发送了10,000个消息，可能只有很少数的消息没有发送成功，当达到一个checkpoint的时候，journal将一批未成功消息通过JDBC存储到数据库，这样避免了多次的数据库操作，很大程度上提高了性能并且保证了可靠性。

    配置方法非常简单，就是无需配置，呵呵。ActiveMQ默认支持Journal，在activemq.xml配置文件中，可以找到如下信息：

<persistenceAdapter>

    <journaledJDBC journalLogFiles="5" journalLogFileSize="1024" dataDirectory="${activemq.home}/activemq-data"/>

</persistenceAdapter>

这里可以改动的就是journalLogFiles，这个属性是制定默认创建几个数据文件来存储消息。journalLogFileSize为数据文件大小，默认为20MB。dataDirectory指向了存储数据文件的位置。

 

2。使用MySQL进行消息持久化

    ActiveMQ持久几乎所有数据库(因为是通过JDBC把消息存储到数据库的)。方法同样简单，就是配置信息稍微有点变化。

<persistenceAdapter>

    <jdbcPersistenceAdapter dataSource="#mysql-ds"/>

</persistenceAdapter>

其中dataSource指定了所用数据源的名字为mysql-ds。需要在activemq.xml文件中的<broker>标签之外配置数据源。下面是MySql的配置信息。

<bean id="mysql-ds" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">

    <property name="driverClassName" value="com.mysql.jdbc.Driver"/>

    <property name="url" value="jdbc:mysql://localhost/activemq?relaxAutoCommit=true"/>

    <property name="username" value="gos2"/>

    <property name="password" value="gos2"/>

    <property name="poolPreparedStatements" value="true"/>

</bean>

 

         KahaDB 支持多种机制在系统异常关闭后重启并恢复。包括检测数据文件丢失和还原损坏的metadata。这些特性并不能完全保证系统异常关闭不造成消息丢失。如果需要保证系统的高可靠性，建议部署到容灾系统上。例如RAID磁盘阵列中。

当broker正常关闭时， KahaDB message store会将所有的缓存数据刷到文件系统中。尤其是这些数据：
1、所有未处理的日志数据
2、所有缓存的metadata
最后meta store中的信息与journal数据文件中的数据保持一致性。

正常情况下，在系统恢复时优先读取journal中的数据。因为metacache中的索引信息是周期性的更新到meta store中的。当系统异常关闭时，可能journal中有的数据meta store中并没有不存在索引。但是KahaDB在恢复时会先读取meta store中的数据，然后再读取journal有但是meta store不存在的数据（因为KahaDB根据meta store中的索引信息快速定位到metastore没有但是journal文件中包含的数据，然后根据这些数据重新在meta store中建立索引信息）

KahaDB会在更新metadata store之前，保存更新操作的概要信息到重做日志(db.redo)中。减少系统异常关闭时的风险。因为重做日志非常小，所以在系统异常关闭时能快速写入。当系统恢复时会判断重做日志中的信息是否需要更新到metadata中。

如果 metadata store 已被不可挽回的损坏了，可以删除metadata store文件（db.data）来强制恢复；只不过这个时候，broker会读取所有的journal文件来重建metadata store，需要一段比较长的时间。

KahaDB可以检测是否有journal文件丢失，如果有丢失，默认将会抛出一个异常然后关闭。便于管理员调查丢失的journal文件，并手动还原。可以通过设置ignoreMissingJournalfiles为true，让broker在启动时忽略这些丢失的journal文件。

KahaDB同样可以检测journal文件的完整性。不过这些特性需要明确的配置来启用。

Xml代码
1.<persistenceAdapter>  
2.  <kahaDB directory="activemq-data"  
3.          journalMaxFileLength="32mb"  
4.          checksumJournalFiles="true"  
5.          checkForCorruptJournalFiles="true"  
6.          />  
7.</persistenceAdapter>