Activemq中的KahaDB消息日志的恢复机制
    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文件的完整性。不过这些特性需要明确的配置来启用。

<persistenceAdapter>
  <kahaDB directory="activemq-data"
          journalMaxFileLength="32mb"
          checksumJournalFiles="true"
          checkForCorruptJournalFiles="true"
          />
</persistenceAdapter>

KahaDB的各个可配置属性：

属性	默认值	描述
directory	activemq-data	保存message store数据文件的目录
indexWriteBatchSize	1000	批量更新索引的阀值，当要更新的索引到达这个索引时，批量更新到metadata store中
indexCacheSize	10000	指定metadata cache的大小
enableIndexWriteAsync	false	写入索引文件到metadata store中的方式是否采用异步写入
journalMaxFileLength	32mb	消息持久数据文件的大小
enableJournalDiskSyncs	true	如果为true，保证使用同步写入的方式持久化消息到journal文件中
cleanupInterval	30000	清除（清除或归档）不再使用的journal 文件的时间周期（毫秒）。
checkpointInterval	5000	写入索引信息到metadata store中的时间周期（毫秒）
ignoreMissingJournalfiles	false	是否忽略丢失的journal文件。如果为false，当丢失了journal文件时，broker启动时会抛异常并关闭
checkForCorruptJournalFiles	false	如果为true，broker在启动的时候会检测journal文件是否损坏，若损坏便尝试恢复它。
checksumJournalFiles	false	如果为true。KahaDB为journal文件生产一个checksum，以便能够检测journal文件是否损坏。
archiveDataLogs	false	如果为true，当达到cleanupInterval周期时，会归档journal文件而不是删除
directoryArchive	null	指定归档journal文件存放的路径
databaseLockedWaitDelay	10000	在使用主从数据库备份时，等待获取DB上的lock的延迟时间。
maxAsyncJobs	10000	等待写入journal文件的任务队列的最大数量。应该大于或等于最大并发producer的数量。配合并行存储转发属性使用。
concurrentStoreAndDispatchTransactions	false	如果为true，转发消息的时候同时提交事务
concurrentStoreAndDispatchTopics	false	如果为true，转发Topic消息的时候同时存储消息的message store中。
concurrentStoreAndDispatchQueues	true	如果为true，转发Queue消息的时候同时存储消息到message store中。