JMS学习(七)-ActiveMQ消息的持久存储方式之KahaDB存储
一，介绍
自ActiveMQ5.4以来，KahaDB成为了ActiveMQ默认的持久化存储方式。相比于原来的AMQ存储方式，官方宣称KahaDB使用了更少的文件描述符，并且提供了更快的存储恢复机制。
二，KahaDB存储配置
在 conf/activemq.xml 中配置如下：
<broker brokerName="broker" ... > <persistenceAdapter> <kahaDB directory="activemq-data" journalMaxFileLength="32mb"/> </persistenceAdapter> ... </broker>
<persistenceAdapter>中指定了kahaDB，并表明数据存储在 "activemq-data"目录下，日志文件最大长度是32MB。
比如一个实际的ActiveMQ的KahaDB存储方式下的数据目录如下：
可以看出，上面directory一共有四个文件：
①db.data
它是消息的索引文件。本质上是B-Tree的实现，使用B-Tree作为索引指向db-*.log里面存储的消息。
②db.redo
主要用来进行消息恢复。
③db-*.log 存储消息的内容。对于一个消息而言，不仅仅有消息本身的数据(message data)，而且还有(Destinations、订阅关系、事务...)
the data logs contain all of the message data and all of the information about destinations, subscriptions, transactions, etc..
data log以日志形式存储消息，而且新的数据总是以APPEND的方式追加到日志文件末尾。因此，消息的存储是很快的。比如，对于持久化消息，Producer把消息发送给Broker，Broker先把消息存储到磁盘中(enableJournalDiskSyncs配置选项)，然后再向Producer返回Acknowledge。Append方式在一定程度上减少了Broker向Producer返回Acknowledge的时间。
④lock文件
另外，一些关于KahaDB的配置选项如下：
1）indexWriteBatchSize 默认值1000，当Metadata Cache中更新的索引到达了1000时，才同步到磁盘上的Metadata Store中。不是每次更新都写磁盘，而是批量更新写磁盘，比较写磁盘的代价是很大的。
2）indexCacheSize 默认值10000，(number of index pages cached in memory)，在内存中最多分配多个页面来缓存index。缓存的index越多，命中的概率就越大，检索的效率就越高。
3）journalMaxFileLength 默认值32MB，当存储的消息达到32MB时，新建一个新文件来保存消息。这个配置对生产者或消息者的速率有影响。比如，生产者速率很快而消费者速率很慢时，将它配置得大一点比较好。
4）enableJournalDiskSyncs 默认值true，默认采用同步写磁盘，即消息先存储到磁盘中再向Producer返回ACK
normally,the broker performs a disk sync(ensuring that a message has been physically written to disk)
before sending the ACK back to a producer
5）cleanupInterval 默认值30000ms，当消息被消息者成功消费之后，Broker就可以将消息删除了。
6）checkpointInterval 默认值5s，每隔5s将内存中的Index(Metadata Cache)更新到磁盘的Index文件中(Metadata Store)
三， KahaDB存储底层实现简单分析
下图是KahaDB的Architecture：
从上图中可以看出：图中各个部分与KahaDB配置的存储目录下的文件是一 一对应的。
①在内存(cache)中的那部分B-Tree是Metadata Cache
通过将索引缓存到内存中，可以加快查询的速度(quick retrival of message data)。但是需要定时将 Metadata Cache 与 Metadata Store同步。
这个同步过程就称为：check point。由checkpointInterval选项 决定每隔多久时间进行一次checkpoint操作。
②BTree Indexes则是保存在磁盘上的，称为Metadata Store，它对应于文件db.data，它就是对Data Logs以B树的形式 索引。
有了它，Broker（消息服务器）可以快速地重启恢复，因为它是消息的索引，根据它就能恢复出每条消息的location。
如果Metadata Store被损坏，则只能扫描整个Data Logs来重建B树了，这个过程是很复杂且缓慢的。
The presence of the metadata store, however, enables the broker instance to restart rapidly.
If the metadata store got damaged or was accidentally deleted, the broker could recover by reading the data logs,
but the restart would then take a considerable length of time.
③Data Logs则对应于文件 db-*.log，默认是32MB
Data Logs以日志形式存储消息，它是生产者生产的数据的真正载体。
The data logs are used to store data in the form of journals,
where events of all kinds—messages, acknowledgments, subscriptions, subscription cancellations, transaction boundaries, etc.
---are stored in a rolling log
④Redo Log则对应于文件 db.redo
redo log的原理用到了“Double Write”。关于“Double Write”可参考
简要记录下自己的理解：因为磁盘的页大小与操作系统的页大小不一样，磁盘的页大小一般是16KB，而OS的页大小是4KB。而数据写入磁盘是以磁盘页大小为单位进行的，即一次写一个磁盘页大小，这就需要4个OS的页大小（4*4=16）。如果在写入过程中出现故障(突然断电)就会导致只写入了一部分数据(partial page write)
而采用了“Double Write”之后，将数据写入磁盘时，先写到一个Recovery Buffer中，然后再写到真正的目的文件中。在ActiveMQ的源码PageFile.java中有相应的实现。
扩展知识：Linux中的日志文件系统：因为Linux的 ext文件系统采用索引节点来存储文件的元数据，每次数据写入磁盘之后，需要更新索引节点表。而写入磁盘与更新索引节点表并不是“原子操作”，比如，在数据写入磁盘后，系统发生故障，之前写入的数据就再也找不到了。
因此，日志文件系统给Linux系统增加了一层安全性：数据写入存储设备之前，先将数据（或者只将索引节点信息写日志）写入到临时文件中，该临时文件称日志。如果在数据写入时发生故障，还可以通过日志来进行一定的恢复。
四，参考文档
