一、关于消息队列的认知
1.消息队列的应用场景
(1)服务解耦
(2)削峰填谷
(3)异步化缓冲
2.应用过程中,需要注意的关注点
(1)生产端可靠性投递
数据强一致,必须保证可靠性
(2)消费幂等性
一条消息只能被消费1次,不能被多次消费
(3)低延迟,高可用,可靠性
(4)堆积能力
3.关于选用MQ的建议
(1)ActiveMQ
a.使用于传统行业,中小型企业
b.并发能力,数据堆积能力一般,不适用于高并发,大流量,海量数据的场景
(2)RabbbitMQ
a.满足高并发,大流量
b.数据可靠,高可用
c.可用性和可维护性都非常不错
d.横向扩展性差,数据堆积能力一般
(3)RocketMQ和Kafka
a.具备高可用和可扩展性
b.适用于海量数据、高并发的场景
c.可维护性稍差
d.其中Kafka可靠性稍逊
(4)选型时,最主要的是还需要考虑业务场景,集群规模和人员成本
二、JMS 与其专业术语
1.JMS的概念
JMS(Java Message Service)规定了Java消息服务,它定义了Java中访问消息中间件的接口的规范。在这里请注意,JMS只是接口,并没有给予实现,实现JMS接口的消息中间件称为 “JMS Provider\”,主流的开源 MOM (Message Oriented Middleware,也就是消息中间件)系统包括Apache的ActiveMQ、RocketMQ、Kafka,以及RabbitMQ,可以说他们都 “基本遵循参考” JMS规范,都有自己的特点和优势。
2.专业术语
JMS(Java Message Service):实现JMS 接口的消息中间件;
Provider(MessageProvider):消息的生产者;
Consumer(MessageConsumer):消息的消费者;
PTP(Point to Point):即点对点的消息模型,这也是非常经典的模型;
Pub / Sub(Publish/Subscribe):,即发布/订阅的消息模型;
Queue:队列目标,也就是我们常说的消息队列,一般都是会真正的进行物理存储;
Topic:主题目标;
ConnectionFactory:连接工厂,JMS 用它创建连接;
Connection:JMS 客户端到JMS Provider 的连接;
Destination:消息的目的地;
Session:会话,一个发送或接收消息的线程(这里Session可以类比Mybatis的Session);
3.JMS 消息格式定义
StreamMessage 原始值的数据流;
MapMessage 一套名称/值对;
TextMessage 一个字符串对象;
BytesMessage 一个未解释字节的数据流;
ObjectMessage 一个序列化的Java对象;
三、关于ActiveMQ
1.前景
目前我们 80% 以上的业务我们使用ActiveMQ已经足够满足需求,其丰富的API、多种集群构建模式使得他成为业界老牌消息中间件,在中小型企业中应用广泛!
2.ActiveMQ的投递模式
(1)点对点(PTP)
生产者向队列投递一条消息,只有一个消费者能够监听得到这条消息
(2)发布订阅(Pub/Sub)
生产者向队列投递一条消息,所有监听该队列的消费者都能够监听得到这条消息
3.ActiveMQ的优劣势分析
(1)服务性能
ActiveMQ的性能一般,对于传统行业较为适用,不适用当前高并发,大流量的互联网环境。
(2)数据存储
默认采用kahadb存储(索引文件形式存储),也可以使用高性能的google leveldb(内存数据库存储), 或者可以使用MySql、Oracle进行消息存储(关系型数据库存储)。
(3)集群架构
ActiveMQ 可以与zookeeper进行构建 主备集群模型,并且多套的主备模型直接可以采用Network的方式构建分布式集群。
4.ActiveMQ的集群架构模式
ActiveMQ最经典的两种集群架构模式,Master-Slave 、Network 集群模式!
(1)Master-Slave
Master-Slave:主从模式=式,也可以理解为双机热备机制; Master Slave 背后的想法是,消息被复制到slave broker,因此即使master broker遇到了像硬件故障之类的错误,你也可以立即切换到slave broker而不丢失任何消息。Master Slave是目前ActiveMQ推荐的高可靠性和容错的解决方案。
(2)Network
Network:这里可以理解为网络通信方式,也可以说叫Network of brokers。这种方式真正解决了分布式消息存储和故障转移、broker切换的问题。可以理解消息会进行均衡;从ActiveMQ1.1版本起,ActiveMQ支持networks of brokers。它支持分布式的queues和topics。一个broker会相同对待所有的订阅(subscription):不管他们是来自本地的客户连接,还是来自远程broker,它都会递送有关的消息拷贝到每个订阅。远程broker得到这个消息拷贝后,会依次把它递送到其内部的本地连接上。