为了高性能，这种方式使用日志文件存储+数据库存储。先将消息持久到日志文件，等待一段时间再将未消费的消息持久到数据库。该方式要比JDBC性能要高
配置（基于JDBC配置稍作修改）
activemq.xml修改
# 修改配置前 <persistenceAdapter> <jdbcPersistenceAdapter dataSource="#mysql-ds" /> </persistenceAdapter> # 修改配置后（注释掉之前的jdbc配置使用下面的） <persistenceFactory> <journalPersistenceAdapterFactory journalLogFiles="5" journalLogFileSize="32768" useJournal="true" useQuickJournal="true" dataSource="#mysql-ds" dataDirectory="../activemq-data" /> </persistenceFactory> 8.6 总结
Jdbc效率低，KahaDB效率高，Jdbc+Journal效率较高。
持久化消息主要指的是：MQ所在服务器宕机了消息不会丢试的机制。
持久化机制演变的过程：从最初的AMQ Message Store方案到ActiveMQ V4版本退出的High Performance Journal（高性能事务支持）附件，并且同步推出了关于关系型数据库的存储方案。ActiveMQ5.3版本又推出了对KahaDB的支持（5.4版本后被作为默认的持久化方案），后来ActiveMQ 5.8版本开始支持LevelDB，到现在5.9提供了标准的Zookeeper+LevelDB集群化方案。
ActiveMQ消息持久化机制有：
持久化机制 特点AMQ 基于日志文件
KahaDB 基于日志文件，从ActiveMQ5.4开始默认使用
JDBC 基于第三方数据库
Replicated LevelDB Store 从5.9开始提供了LevelDB和Zookeeper的数据复制方法，用于Master-slave方式的首选数据复制方案。
9. ActiveMQ多节点集群 9.1 理解
基于zookeeper和LevelDB搭建ActiveMQ集群。集群仅提供主备方式的高可用集群功能，避免单点故障。
9.2 三种集群方式
基于shareFileSystem共享文件系统（KahaDB）
基于JDBC
基于可复制的LevelDB
9.3 ZK + Replicated LevelDB Store 案例Replicated LevelDB Store
是什么：
使用Zookeeper集群注册所有的ActiveMQ Broker但只有其中一个Broker可以提供服务，它将被视为Master，其他的Broker处于待机状态被视为Slave。如果Master因故障而不能提供服务，Zookeeper会从Slave中选举出一个Broker充当Master。Slave连接Master并同步他们的存储状态，Slave不接受客户端连接。所有的存储操作都将被复制到连接至Maste的Slaves。如果Master宕机得到了最新更新的Slave会变成Master。故障节点在恢复后会重新加入到集群中并连接Master进入Slave模式。所有需要同步的消息操作都将等待存储状态被复制到其他法定节点的操作完成才能完成。所以，如给你配置了replicas=3，name法定大小是（3/2）+1 = 2。Master将会存储更新然后等待（2-1）=1个Slave存储和更新完成，才汇报success，至于为什么是2-1，阳哥的zookeeper讲解过自行复习。有一个ode要作为观察者存在。当一个新的Master被选中，你需要至少保障一个法定mode在线以能够找到拥有最新状态的ode，这个ode才可以成为新的Master。因此，推荐运行至少3个replica nodes以防止一个node失败后服务中断。
部署规划和步骤
环境和版本
关闭防火墙并保证各个服务器能够ping通
具备zk集群并可以成功启动
集群部署规划列表
创建3台集群目录（就是一台电脑复制三份ActiveMQ）
修改管理控制台端口（就是ActiveMQ后台管理页面的访问端口）
hostname名字映射（如果不映射只需要吧mq配置文件的hostname改成当前主机ip）
ActiveMQ集群配置
配置文件里面的BrokerName要全部一致
持久化配置(必须)
修改各个节点的消息端口（真实的三台机器不用管）
按顺序启动3个ActiveMQ节点,到这步前提是zk集群已经成功启动运行（先启动Zk 在启动ActiveMQ）
zk集群节点状态说明
3台Zk连接任意一台验证三台ActiveMQ是否注册上了Zookeeper
查看Master
集群可用性测试
10 ActiveMQ高级特性 10.1 引入消息中间件后如何保证其高可用zookeeper+Replicated LevelDB
10.2 异步投递Async Sends异步投递
对于一个Slow Consumer，使用同步发送消息可能出现Producer堵塞的情况，慢消费者适合使用异步发送。
是什么
ActiveMQ支持同步，异步两种发送的模式将消息发送到broker，模式的选择对发送延时有巨大的影响。producer能达到怎么样的产出率（产出率=发送数据总量/时间）主要受发送延时的影响，使用异步发送可以显著提高发送的性能。