消息中间件ActiveMQ5：可持久化方式AMQ和KahaDB

一、需要进行消息持久化的原因

原因&＃xff1a;

为了避免以外宕机以后丢失信息&＃xff0c;需要做到重启之后可以恢复消息队列。消息系统一般都会采用持久化机制。

ActiveMQ的消息持久化机制有JDBC、AMQ、KahaDB、和LevelDB&＃xff0c;无论使用哪种持久化方式&＃xff0c;消息的存储逻辑都是一致的。

思维导图&＃xff1a;

存储逻辑&＃xff1a;

就是在发送者将消息发送到MQ服务器后&＃xff0c;消息中心首先将消息持久化到 本地数据文件、内存数据库或者远程库等&＃xff0c;在试图将消息发送给接收者&＃xff0c;成功则将消息从存储中删除&＃xff0c;失败则继续尝试发送。

消息中间件启动以后&＃xff0c;首先要检查指定的存储配置&＃xff0c;如果有未发送成功的消息&＃xff0c;则需要把消息发送出去。

二、持久化方式

1、AMQ message Store&＃xff08;了解&＃xff09;

AMQ使一种文件消息存储&＃xff0c;它具有写入消息快的特点。

原理&＃xff1a;

• 写入消息时&＃xff0c;会将消息按顺序追加到日志文件&＃xff0c;性能很高。为了提升性能&＃xff0c;创建消息主键索引&＃xff0c;并且提供缓存机制&＃xff0c;进一步提升性能。
• 每个日志文件的大小都是有限制的&＃xff08;默认32m&＃xff0c;可自行配置&＃xff09;&＃xff0c;当一个存储文件中的消息已经全部被消费&＃xff0c;那么这个文件将会被表示为可删除&＃xff0c;在下一个清除判断&＃xff0c;这个文件会被删除。
• 当超过这个大小&＃xff0c;系统会重新建立一个文件。当所有的消息都消费完成&＃xff0c;系统会删除这个文件或者归档&＃xff08;取决于配置&＃xff09;。

缺点&＃xff1a;

• AMQ Message会为每一个Destination创建一个索引&＃xff0c;一旦使用了大量的Queue&＃xff0c;索引文件的大小会占用很多磁盘空间。而且由于索引巨大&＃xff0c;一旦Broker崩溃&＃xff0c;重建索引的速度会非常慢。

AMQ使用于5.3之前的版本&＃xff0c;基于文件的存储方式&＃xff0c;是以前默认的的消息存储&＃xff0c;现在已经不使用了。

2、KahaDB消息存储&＃xff08;默认&＃xff09;

ActiveMQ从5.4版本开始&＃xff0c;推荐使用KahaDB&＃xff0c;KahaDB是基于日志文件的

官方文档地址&＃xff1a;

原理&＃xff1a;

KahaDB的Architecture图&＃xff1a;

过程解析&＃xff1a;

① 在内存(cache)中的那部分B-Tree是Metadata Cache&＃xff0c;通过将索引缓存到内存中&＃xff0c;可以加快查询的速度(quick retrival of message data)。但是需要定时将 Metadata Cache 与 Metadata Store同步。

这个同步过程就称为&＃xff1a;check point。由checkpointInterval选项 决定每隔多久时间进行一次checkpoint操作。

② BTree Indexes则是保存在磁盘上的&＃xff0c;称为Metadata Store&＃xff0c;它对应于文件db.data&＃xff0c;它就是对Data Logs以B树的形式 索引。有了它&＃xff0c;Broker&＃xff08;消息服务器&＃xff09;可以快速地重启恢复&＃xff0c;因为它是消息的索引&＃xff0c;根据它就能恢复出每条消息的location。

如果Metadata Store被损坏&＃xff0c;则只能扫描整个Data Logs来重建B树了&＃xff0c;这个过程是很复杂且缓慢的。

③ Data Logs则对应于文件 db-.log&＃xff0c;默认是32MB,Data Logs以日志形式存储消息&＃xff0c;它是生产者生产的数据的真正载体。
④ Redo Log则对应于文件 db.redo&＃xff0c;redo log的原理用到了“Double Write”。

kahadb在消息保存目录中只有4个文件和一个lock&＃xff0c;跟ActiveMQ的却文件存储引擎相比这就非常简洁了。

4个文件和一个锁&＃xff1a;

• db-.log &＃xff1a;KahaDB存储消息到预定大小的数据记录文件中&＃xff0c;文件命名为db-.log。当数据文件已满时&＃xff0c;一个新的文件会随之创建。number的数值也会递增&＃xff0c;它随着消息数量的增多&＃xff0c;如每32M一个文件&＃xff0c;文件名安装数字进行依次编号。当不再有引用到数据文件中的任何消息时文件会被删除或者归档。
• db.data &＃xff1a; 该文件包含了持久化的BTree的索引&＃xff0c;索引了消息数据记录中的消息&＃xff0c;他是消息索引文件&＃xff0c;本质上时B-Tree&＃xff08;B数&＃xff09;&＃xff0c;使用B-Tree作为索引指向db-.log里面的存储消息。
• db.redo&＃xff1a; 主要用来进行消息恢复。
• db.free&＃xff1a;当前db.data文件里面哪些时空闲的&＃xff0c;文件具体内容时所有空闲页的ID
• lock&＃xff1a; 锁文件

KahaDB主要特性&＃xff1a;

• 日志形式存储消息&＃xff1b;
• 消息索引以B-Tree结构存储&＃xff0c;可以快速更新&＃xff1b;
• 完全支持JMS事务&＃xff1b;
• 支持多种恢复机制&＃xff1b;

在配置文件中我们可以看到下面的配置&＃xff0c;说明的ActiveMQ默认使用的KahaDB

配置方式&＃xff1a;

• directory : 指定持久化消息的存储目录
• journalMaxFileLength : 指定保存消息的日志文件大小&＃xff0c;具体根据你的实际应用配置

<persistenceAdapter><kahaDB directory&＃61;"${activemq.data}/activemq-data" journalMaxFileLength&＃61;"16mb"/>
persistenceAdapter>

说明&＃xff1a;

• 目前默认的存储方式&＃xff0c;可用于任何场景&＃xff0c;提高了性能和恢复能力。
• 消息存储使用一个事务日志和仅仅一个索引文件来存储它的所有地址。
• kahaDB时专门针对消息持久化的解决方案&＃xff0c;它对典型的消息使用模式进行了优化。
• 数据被追加到data logs中&＃xff0c;当不在需要log文件中的数据时&＃xff0c;log文件会被丢弃。