ActiveMQ--可持久化（对持久化几种方式的总结）

消息的持久化

将MQ 收到的消息存储到文件、硬盘、数据库 等、 则叫MQ 的持久化，这样即使服务器宕机，消息在本地还是有，仍就可以访问到。

官网 ： http://activemq.apache.org/persistence

之前介绍过保证消息的可靠性的四个因素：1.消息的持久化 2.事务 3.签收 4.集群高可用

ActiveMQ支持的消息持久化机制：AMQ、LevelDB、kahaDB、JDBC、JDBC搭配高速缓存机制journal。

1.AMQ

AMQ 是文件存储形式，写入快、易恢复 默认 32M 在 ActiveMQ 5.3 之后不再适用

2.KahaDB 

5.4 之后基于日志文件的持久化插件，默认持久化插件，提高了性能和恢复能力

KahaDB 的属性配置 ： http://activemq.apache.org/kahadb

它使用一个事务日志和 索引文件来存储所有的地址

db-<数字>.log 存储数据，一个存满会再次创建 db-2 db-3 …… ，当不会有引用到数据文件的内容时，文件会被删除或归档

db.data 是一个BTree 索引，索引了消息数据记录的消息，是消息索引文件，它作为索引指向了 db-<x>.log 里的消息

一点题外话：就像mysql 数据库，新建一张表，就有这个表对应的 .MYD 文件，作为它的数据文件，就有一个 .MYI 作为索引文件。

db.free 存储空闲页 ID 有时会被清除

db.redo 当 KahaDB 消息存储在强制退出后启动，用于恢复 BTree 索引

lock 顾名思义就是锁

四类文件+一把锁 ==》 KahaDB

 

3.LevelDB

希望作为以后的存储引擎，5.8 以后引进，也是基于文件的本地数据存储形式，但是比 KahaDB 更快

它比KahaDB 更快的原因是她不使用BTree 索引，而是使用本身自带的 LevelDB 索引

题外话：为什么LevelDB 更快，并且5.8 以后就支持，为什么还是默认 KahaDB 引擎，因为 activemq 官网本身没有定论，LevelDB 之后又出了可复制的LevelDB 比LevelDB 更性能更优越，但需要基于 Zookeeper 所以这些官方还没有定论，所以默认使用 KahaDB

 

4.JDBC

有一部分数据会真实的存储到数据库中，实现消息的持久化。

①修改配置文件，默认 kahaDB

<persistenceAdapter>
       <kahaDB directory="${activemq.data}/kahadb"/>  
 </persistenceAdapter>

修改之后

<persistenceAdapter>
      <jdbcPersistenceAdapter dataSource="#mysql-ds"/>
 </persistenceAdapter>

②在activemq 的lib 目录下添加 jdbc 的jar 包

③ 修改配置文件 ： activemq.xml 使其连接自己windows 上的数据库，并在本地创建名为activemq 的数据库

④ 让linux 上activemq 可以访问到 mysql ，之后产生消息。

ActiveMQ 启动后会自动在 mysql 的activemq 数据库下创建三张表：activemq_msgs 、activemq_acks、activemq_lock

activemq_acks：用于存储订阅关系。如果是持久化Topic，订阅者和服务器的订阅关系在这个表保存

activemq_lock：在集群环境中才有用，只有一个Broker可以获得消息，称为Master Broker

activemq_msgs：用于存储消息，Queue和Topic都存储在这个表中，Queue类型消息被消费数据则消失，Topic类型为队列被删除数据才消失。

点对点会在数据库的数据表 ACTIVEMQ_MSGS 中加入消息的数据，且在点对点时，消息被消费就会从数据库中删除

但是对于主题，订阅方式接受到的消息，会在 ACTIVEMQ_MSGS 存储消息，即使MQ 服务器下线，并在 ACTIVEMQ_ACKS 中存储消费者信息 。 并且存储以 activemq 为主，当activemq 中的消息被删除后，数据库中的也会自动被删除。

 

5.jdbc配合Journal高速缓存

通过jdbc进行数据读写效率是很低的，特别是当生产者与消费者对消息的操作频繁的时候，这种方式是相当于在ActiveMQ和Mysql中加了一道高速缓存的屏障，当有生产者添加消息数据时，将消息先放到本地的一个文件中，消费者暂时先从文件中进行消费，每隔一段时间将还没有被消费的数据通过批处理的方式再更新到Mysql数据库中，这样可以减少数据插入的条数，从而加快效率。

配置：

 

 

总结：

持久化机制演化过程：从最初的AMQ Message Store 方案到 ActiveMQ V4版本推出的High performance journal （高性能事务）附件，并且同步推出了关系型数据库的存储方案， ActiveMQ 5.3 版本有推出了KahaDB 的支持，（也是5.4之后的默认持久化方案），后来ActiveMQ 从5.8开始支持LevelDB ，现在5.9 提供了 Zookeeper + LevelDB 的集群化方案。

ActiveMQ 消息持久化机制有：

AMQ 基于日志文件

KahaDB 基于日志文件，5.4 之后的默认持久化

JDBC 基于第三方数据库

LevelDB ： 基于文件的本地数据库存储，从5.8 之后推出了LevelDB 性能高于 KahaDB

ReplicatedLevelDB Store 从5.8之后提供了基于LevelDB 和Zookeeper 的数据复制方式，用于Master-slave方式的首数据复制选方案