LevelDB持久性適配器使用LevelDB作為高性能的消息存儲。它是一個基於文件的存儲庫，它使用了Google的LevelDB，將索引保存到包含消息的日志文件中。它經過優化，提供了比KahaDB更快的持久性。它類似於KahahDB，但是它沒有使用自定義的b樹實現來索引寫前日志，而是使用基於LevelDB的索引，由於“append only”文件訪問模式，這些索引具有一些很好的屬性：
- 快速更新(不需要進行隨機磁盤更新)
- 並發讀取
- 使用硬鏈接的快速索引快照
KahaDB和LevelDB存儲都必須進行周期性的垃圾收集，以確定可以刪除哪些日志文件。在KahaDB的情況下，這可能非常昂貴，因為您增加了存儲的數據量，並且在收集發生時可能導致讀/寫停止。LevelDB存儲使用一種便宜得多的算法來確定何時可以收集日志文件並避免這些停頓。
LevelDB的主要優勢有：
- 更高的持久吞吐量
- broker重啟時恢復時間更快
- 支持並發的讀訪問
- 在垃圾回收周期中不會暫停
- 使用較少的讀取IO操作來加載存儲的消息
- 支持XA事務
- 檢查重復的消息
- 通過JMX暴露公開狀態以進行監控
- 支持復制
在ActiveMQ中配置使用LevelDB作為持久化存儲方案實際上很簡單，使用主配置文件中的persistence Adapter標記就可以完成。最簡配置如下所示：
...... <broker xmlns="http://activemq.apache.org/schema/core" brokerName="localhost" dataDirectory="${activemq.data}"> ...... <persistenceAdapter> <levelDB directory="${activemq.data}/levelDB"/> </persistenceAdapter> ...... </broker> ......
以上示例配置中，directory屬性表示LevelDB的結構文件所放置的目錄位置。請注意，由於log文件是順序寫的機制，所以log文件也會預占磁盤空間，並且log文件默認的大小就是100MB。那么只要生成一個log文件，就至少會占據100MB的存儲空間（但這不代表總的已使用量）。也就是說，如果您將主配置文件中storeUsage標記的limit屬性設置為200mb，那么透過ActiveMQ管理界面看到的現象就是：只要有任何一條PERSISTENT Message被接受，Store percent used立刻就會變成50%。如果您將storeUsage標記的limit屬性為100mb，那么只要有任何一條PERSISTENT Message被接受，ActiveMQ服務端的Producer Flow Control策略就會立刻開始工作。
所以一定不要吝嗇分配memoryUsage、storeUsage。依據您的團隊在生產環境下的存儲方案，也可以通過logSize屬性改變LevelDB中單個log文件的大小。如下示例：
...... <!-- 限制大小為50mb --> <persistenceAdapter> <levelDB directory="${activemq.data}/levelDB" logSize="52428800"/> </persistenceAdapter> ......
默認的LevelDB存儲策略中，當ActiveMQ接收到一條消息后，就會同步將這條消息寫入到log文件中，並且同時在內存區域向Memtable寫入位置索引。通過配置您也可以將這個過程改為“異步”：
...... <!-- 改為異步寫log文件 --> <persistenceAdapter> <levelDB directory="${activemq.data}/levelDB" logSize="52428800" sync="false"/> </persistenceAdapter> ......
以下列表展示了您可以使用的LevelDB的配置屬性，使用“*”標識出來的屬性是筆者認為重要的配置項：
關於LevelDB 詳細請參加官網：http://activemq.apache.org/replicated-leveldb-store.html