轉自：http://www.iteye.com/topic/1121713
前幾天看到淘寶開源了Meta，估計notify也要開源了。其實消息中間件的一個非常重要的核心部件就是持久化存儲，可能Meta的功能定位使得它在這一塊的實現相對notify和activemq就簡單些。趁着有點時間，把activeMQ的kahadb存儲引擎做了個分析，希望能對jms實現感興趣的朋友有點幫助。
1． 概述
Kahadb是activemq從版本5.4之後的默認消息存儲引擎。消息存儲機制是消息中間件最重要的核心部件和性能提升點。一直想對它做一個完整分析，這次趁有時間對kahadb做一個較完整分析。
Kahadb是基於B-tree算法的，具體原理fusesource給了個原理說明(http://fusesource.com/docs/broker/5.4/persistence/KahaDB-Overview.html)，下面我們從代碼實現角度進行一個較深入的分析。下面所有的分析都是基於activeMQ 5.4.3版本源碼，該版本里的kahadb版本是V3，且是基於queue進行的源碼分析，topic的實現雖然有不少差異，但整體可參考queue的。
2． 每個磁盤文件的作用和詳細存儲格式
首先kahadb在消息保存目錄中只有4類文件和一個lock，跟ActiveMQ的其他幾種文件存儲引擎相比這就非常簡潔了。
每種文件的具體作用：
#db-*.log:
存放完整的每條消息(包括事務、目的地、id、優先級、具體內容等)和producerSequenceIdTracker(用來驗證每個消息生成者發送的消息是否重複的數據結構)。它隨着消息數量的增多，如每32M一個文件，文件名按照數字進行編號，如db-1.log、db-2.log、db-3.log …
#db.data:
通過存放多個Btree數據結構來保存各類重要信息，下面一一進行介紹：
Metadata類的destinations：用來保存該broker上有哪些Queue或隊列
StoredDestination類的orderIndex屬性中的
defaultPriorityIndex、lowPriorityIndex、highPriorityIndex，這3個btree是爲消息優先級排序而設計的(應該是版本5.4引入的，唉，有時候一個功能的引入帶來的代價可能比較大)。它們的主要作用是爲AbstractStoreCursor類的doFillBatch方法服務的，也就是常說的消息指針(message cursors)。當消息指針需要從磁盤文件中裝載一批消息的時候會使用這3個btree實例(kahadb版本小於2的不支持lowPriorityIndex、highPriorityIndex)
StoredDestination類的locationIndex：該btree的主要作用包括：
. 系統重啓進行恢復操作的時候，要移除掉不在db-*.log文件裏的消息；
. 在系統進行定時checkpointUpdate時使用
StoredDestination類的messageIdIndex：該btree的主要作用是消息確認acknowledge操作時，通過消息ID在messageIdIndex中刪除對應的記錄，並依據返回的值刪除orderIndex和locationIndex中的記錄
上面這些就是kahadb中最主用的btree實例。
#db.redo:
它的作用是“Double Write”，具體代碼參看PageFile類的writeBatch方法。它的原理可參考(http://www.mysqlperformanceblog.com/2006/08/04/innodb-double-write/)
#db.free:
當前db.data文件裏哪些頁面是空閒的，文件具體內容是所有空閒頁的ID
下面是具體每個文件的內部數據格式：
