ActiveMQ的消息存储持久化（一）

                                 ActiveMQ的消息存储持久化（一）

概述

ActiveMQ不仅支持persistent【持久的】和non-persistent【非持久的】两种方式，还支持消息的recovery【恢复】方式。

PTP

Queue的存储是很简单的，就是一个FIFO的Queue。

PUB/SUB

对于持久化订阅主题，每一个消费者将获得一个消息的复制。

有效的消息存储

ActiveMQ提供了一个插件式的消息存储，类似于消息的多点传播，主要实现了如下几种：

1. AMQ消息存储，基于文件的存储方式，是以前的默认消息存储。
2. KahaDB消息存储，提供了容量的提升和恢复能力，是现在的默认存储方式。
3. JDBC消息存储，消息基于JDBC存储的。
4. Memory 消息存储，基于内存的消息存储。

KahaDB Message Store概述

KahaDB是目前默认的存储方式，可用于任何场景，提高了性能和恢复能力。消息存储使用一个事务日志和仅仅用一个索引文件来存储它所有的地址。

KahaDB是一个专门针对消息持久化的解决方案，它对典型的消息使用模式进行了优化。在KahaDB中，数据被追加到data logs中。当不再需要log文件中的数据的时候，log文件会被丢弃。

KahaDB基本配置示例

可用的属性有：

• director：KahaDB存放的路径，默认值activemq-data。
• indexWriteBatchSize： 批量写入磁盘的索引page数量，默认值1000。
• indexCacheSize：内存中缓存索引page的数量，默认值10000。
• enableIndexWriteAsync：是否异步写出索引，默认false。
• journalMaxFileLength：设置每个消息data log的大小，默认是32MB。
• enableJournalDiskSyncs：设置是否保证每个没有事务的内容，被同步写入磁盘，JMS持久化的时候需要，默认为true。
• cleanupInterval：在检查到不再使用的消息后，在具体删除消息前的时间，默认30000。
• checkpointInterval：checkpoint的间隔时间，默认5000。
• ignoreMissingJournalfiles：是否忽略丢失的消息日志文件，默认false。
• checkForCorruptJournalFiles：在启动的时候，将会验证消息文件是否损坏，默认false。
• checksumJournalFiles：是否为每个消息日志文件提供checksum，默认false。
• archiveDataLogs： 是否移动文件到特定的路径，而不是删除它们，默认false。
• directoryArchive：定义消息已经被消费过后，移动data log到的路径，默认null。
• databaseLockedWaitDelay：获得数据库锁的等待时间 (used by shared master/slave)，默认10000。
• maxAsyncJobs：设置最大的可以存储的异步消息队列，默认值10000，可以和concurrentMessageProducers 设置成一样的值。
• concurrentStoreAndDispatchTransactions：是否分发消息到客户端，同时事务存储消息，默认true。
• concurrentStoreAndDispatchTopics：是否分发Topic消息到客户端，同时进行存储，默认true。
• concurrentStoreAndDispatchQueues：是否分发queue消息到客户端，同时进行存储，默认true。

在Java中内嵌使用Broker，使用KahaDB的示例：

public class EmbeddedBrokerUsingKahaDBStoreExample {
  BrokerService createEmbeddedBroker() throws Exception {
   BrokerService broker = new BrokerService();
   File dataFileDir = new File("target/amq-in-action/kahadb");
   KahaDBStore kaha = new KahaDBStore();
   kaha.setDirectory(dataFileDir);
   // Using a bigger journal file
   kaha.setJournalMaxFileLength(1024*100);
   // small batch means more frequent and smaller writes
   kaha.setIndexWriteBatchSize(100);
   // do the index write in a separate thread
   kaha.setEnableIndexWriteAsync(true);
   broker.setPersistenceAdapter(kaha);
   //create a transport connector
   broker.addConnector("tcp://localhost:61616");
   //start the broker
   broker.start();
   return broker;
  }
}