1. ActiveMq简介
1.1 java消息服务:
不同系统之间的信息交换,是我们开发中比较常见的场景,比如系统A要把数据发送给系统B,这个问题我们应该如何去处理? 1999年,原来的SUN公司领衔提出了一种面向消息的中间件服务–JMS规范(标准);常用的几种信息交互技术(
httpClient、hessian、dubbo、jms、webservice 五种)
1.2 JMS概述:
JMS即Java消息服务(Java Message Service的简称),是Java EE
的标准/规范之一。这种规范(标准)指出:消息的发送应该是异步的、非阻塞的。也就是说消息的发送者发送完消息后就直接返回了,不需要等待接收者返回后才能返回,发送者和接收者可以说是互不影响。所以这种规范(标准)能够减轻或消除系统瓶颈,实现系统之间去除耦合,提高系统的整体可伸缩性和灵活性。JMS只是Java
EE中定义的一组标准API,它自身并不是一个消息服务系统,它是消息传送服务的一个抽象,也就是说它定义了消息传送的接口而并没有具体实现
1.3 ActiveMQ与JMS关系:
我们知道,JMS只是定义了一组有关消息传送的规范和标准,并没有真正实现,也就说JMS只是定义了一组接口而已;就像JDBC抽象了关系数据库访问、JPA抽象了对象与关系数据库映射、JNDI抽象了命名目录服务访问一样,JMS具体的实现由不同的消息中间件厂商提供,比如Apache
ActiveMQ就是JMS规范的具体实现,Apache ActiveMQ才是一个消息服务系统,而JMS不是
1.4 ActiveMQ概述:
我们知道JMS只是消息服务的一组规范和接口,并没有具体的实现,而ActiveMQ就是JMS规范的具体实现;它是Apache下的一个项目,采用Java语言开发,完全支持JMS1.1和J2EE1.4规范的JMS Provider实现
1.5 ActiveMQ特点:
- 支持多种语言编写客户端
- 对spring的支持,很容易和spring整合
- 支持多种传输协议: TCP,SSL,NIO,UDP等
- 支持点对点(queue)
- 支持一对多(topic)
1.6 ActiveMQ版本选型:
- ActiveMQ “Classic”
经典版,一直在维护,生产环境建议使用该版本
- ActiveMQ Artemis 下一代,目前社区维护版本更新较慢,不建议使用
1.7 ActiveMQ的几种消息持久化机制
- JDBC持久化方式 使用JDBC持久化方式,数据库会创建3个表:activemq_msgs,activemq_acks和activemq_lock。 activemq_msgs用于存储消息,Queue和Topic都存储在这个表中
- AMQ方式
- 性能高于JDBC,写入消息时,会将消息写入日志文件,由于是顺序追加写,性能很高,为了提升性能,创建消息主键索引,并且提供缓存机制,进一步提升性能
- 每个日志文件的大小都是有限制的(默认32m,可自行配置)
- 当超过这个大小,系统会重新建立一个文件。当所有的消息都消费完成,系统会删除这个文件或者归档(取决于配置)
- 主要的缺点是AMQ Message会为每一个Destination创建一个索引,如果使用了大量的Queue,索引文件的大小会占用很多磁盘空间
- 而且由于索引巨大,一旦Broker崩溃,重建索引的速度会非常慢
- KahaDB方式
- KahaDB是从ActiveMQ 5.4开始默认的持久化插件,也是我们项目现在使用的持久化方式
- KahaDb恢复时间远远小于其前身AMQ并且使用更少的数据文件,所以可以完全代替AMQ
- kahaDB的持久化机制同样是基于日志文件,索引和缓存
- LevelDB方式
- 从ActiveMQ 5.6版本之后,又推出了LevelDB的持久化引擎。
- 目前默认的持久化方式仍然是KahaDB,不过LevelDB持久化性能高于KahaDB,可能是以后的趋势。
- 在ActiveMQ 5.9版本提供了基于LevelDB和Zookeeper的数据复制方式,用于Master-slave方式的首选数据复制方案。
- 在ActiveMQ5.14之后又取消了该方式,具体参考