Activemq特性之持久化--LevelDB特性

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