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的整合。