ActiveMQ、RabbitMQ、RocketMQ、Kafka介绍-CSDN博客

一、消息中间件的使用场景

 

消息中间件的使用场景总结就是六个字解耦、异步、削峰

 

1.解耦

如果我方系统A要与三方B系统进行数据对接推送系统人员信息通常我们会使用接口开发来进行。但是如果运维期间B系统进行了调整或者推送过程中B系统网络进行了调整又或者后续过程中我们需要推送信息到三方C系统中这样的话就需要我们进行频繁的接口开发调整还需要考虑接口推送消息失败的场景。

 

如果我们使用消息中间件进行消息推送我们只需要按照一种约定的数据结构进行数据推送其他三方系统从消息中间件取值消费就可以即便是三方系统出现宕机或者其他调整我们都可以正常进行数据推送。

 

总结通过一个 MQPub/Sub 发布订阅消息这么一个模型A 系统就跟其它系统彻底解耦了。

 

2.异步

继续我们上述的消息推送业务如果我们现在需要同时推送消息到BCD三个系统中而BCD系统接收到消息后需要进行复杂的逻辑处理以及读库写库处理。如果一个三方系统进行消息处理需要1s那我们遍历推送完一次消息就需要三秒。

 

而如果我们使用消息中间件我们只需要推送到消息中间件然后进行接口返回可能只需要20ms大大提升了用户体验。消息推送后BCD系统各自进行消息消费即可不需要我们等待。

 

3.削峰

还是上述我们的应用场景假设某一时间段内每秒都有一条消息推送如果我们使用接口进行推送BCD三个系统处理完就需要三秒。这样会导致用户前端体验较差而且系统后台一直处于阻塞状态后续的消息推送接口一直在等待。

 

如果我们使用消息中间件我们只需要将消息推送至消息中间件中BCD系统对积压的消息进行相应的处理。

 

在上述高频发的消息时间段内会在消息中间中产生消息积压BCD系统在上述时间段外对积压消息进行相应的处理即可。

 

二、消息中间件的优缺点

消息中间件的优点其实就是他的使用场景。

 

消息中间件的缺点与优点也是相辅相成的主要有以下三个

 

1.系统可用性降低

系统关联的中间件越多越容易引发宕机问题。

 

如上述案例中的问题原本进行消息推送我们只需要开发接口进行推送即可引入消息中间件后就需要考虑消息中间件的高可用问题如果消息中间件出现宕机问题我们所有的消息推送都会失败。

 

2.系统复杂度提高

上述案例中如果我们使用接口进行消息推送我们只需要考虑接口超时以及接口推送消息失败的问题。但我们引入消息中间件后就需要考虑消息中间件的维护以及消息重复消费消息丢失的问题。

 

3.一致性问题

上述案例中如果我们使用接口进行消息推送推送消息我们可以放在事务中处理如果推送过程中出现异常我们可以进行数据回滚但我们引入消息中间件后就需要考虑消息推送后消费失败的问题以及如果我们同时推送消息到BCD系统中如何保证他们的事务一致性。

 

三、四种消息中间件的基本介绍

特性 ActiveMQ RabbitMQ RocketMQ Kafka

单机吞吐量 万级比 RocketMQ、Kafka 低一个数量级 同 ActiveMQ 10 万级支撑高吞吐 10 万级高吞吐一般配合大数据类的系统来进行实时数据计算、日志采集等场景

topic 数量对吞吐量的影响 topic 可以达到几百/几千的级别吞吐量会有较小幅度的下降这是 RocketMQ 的一大优势在同等机器下可以支撑大量的 topic topic 从几十到几百个时候吞吐量会大幅度下降在同等机器下Kafka 尽量保证 topic 数量不要过多如果要支撑大规模的 topic需要增加更多的机器资源

时效性 ms 级 微秒级这是 RabbitMQ 的一大特点延迟最低 ms 级 延迟在 ms 级以内

可用性 高基于主从架构实现高可用 同 ActiveMQ 非常高分布式架构 非常高分布式一个数据多个副本少数机器宕机不会丢失数据不会导致不可用

消息可靠性 有较低的概率丢失数据 基本不丢 经过参数优化配置可以做到 0 丢失 同 RocketMQ

功能支持 MQ 领域的功能极其完备 基于 erlang 开发并发能力很强性能极好延时很低 MQ 功能较为完善还是分布式的扩展性好 功能较为简单主要支持简单的 MQ 功能在大数据领域的实时计算以及日志采集被大规模使用

其他 Apache软件基金会开发、起步较早但没有经过大量吞吐场景验证目前社区不是很活跃 开源稳定社区活跃度高 阿里出品目前已交给Apache但社区活跃度较低 Apache软件基金会开发、开源、高通吐量社区活跃度高

1.ActiveMQ

1.1Activemq 是什么

Activemq 是一种开源的实现了JMS1.1规范的面向消息(MOM)的中间件为应用程序提供高效的、可扩展的、稳定的和安全的企业级消息通信。

 

1.2Activemq 的作用及原理

Activemq 的作用就是系统之间进行通信原理就是生产者生产消息 把消息发送给activemq Activemq 接收到消息 然后查看有多少个消费者

 

然后把消息转发给消费者 此过程中生产者无需参与。 消费者接收到消息后做相应的处理和生产者没有任何关系。

 

1.3Activemq 的通信方式

publish(发布)-subscribe(订阅)(发布-订阅方式)

发布/订阅方式用于多接收客户端的方式作为发布订阅的方式可能存在多个接收客户端并且接收端客户端与发送客户端存在时间上的依赖。一个接收端只能接收他创建以后发送客户端发送的信息。

 

p2p(point-to-point)(点对点)

p2p的过程则理解起来比较简单。它好比是两个人打电话这两个人是独享这一条通信链路的。一方发送消息另外一方接收就这么简单。在实际应用中因为有多个用户对使用p2p的链路相互通信的双方是通过一个类似于队列的方式来进行交流。和前面pub-sub的区别在于一个topic有一个发送者和多个接收者而在p2p里一个queue只有一个发送者和一个接收者。

 

1.4Activemq 的消息持久化机制

JDBC 持久化到数据库

AMQ 日志文件已基本不用

KahaDB AMQ基础上改进默认选择

LevelDB 谷歌K/V数据库

在activemq.xml中查看默认的broker持久化机制。

 

1.5Activemq 的消息确认机制

1AUTO_ACKNOWLEDGE = 1 自动确认

 

2CLIENT_ACKNOWLEDGE = 2 客户端手动确认

 

3DUPS_OK_ACKNOWLEDGE = 3 自动批量确认

 

4SESSION_TRANSACTED = 0 事务提交并确认

 

5INDIVIDUAL_ACKNOWLEDGE = 4 单条消息确认

 

前四种是JMS API中提供的客户端ACK_MODE。第五种是InforSuiteMQ自定义补充的一种ACK_MODE。

 

2.RabbitMQ

2.1RabbitMQ是什么

RabbitMQ是一个由erlang语言编写的、开源的、在AMQP基础上完整的、可复用的企业消息系统。

 

2.2RabbitMQ的作用及原理

 

 

基本概念

 

关键名称 说明

Channel信道 消息推送使用的通道

Producer消息的生产者 向消息队列发布消息的客户端应用程序

Consumer消息的消费者 从消息队列取得消息的客户端应用程序

Message消息 消息由消息头和消息体组成

Routing Key路由键 消息头的一个属性用于标记消息的路由规则决定了交换机的转发路径

Queue消息队列 用于存储生产者的消息

Exchange交换器路由器 提供Producer到Queue之间的匹配

Binding绑定 用于建立Exchange和Queue之间的关联

Binding Key绑定键 Exchange与Queue的绑定关系用于匹配Routing Key

Broker服务主体 RabbitMQ Server服务器实体

2.3RabbitMQ的通信方式

2.3.1简单队列

最简单的工作队列其中一个消息生产者一个消息消费者一个队列。也称为点对点模式

 

2.3.2工作队列模式

一个消息生产者一个交换器一个消息队列多个消费者。同样也称为点对点模式

 

2.3.3发布订阅模式

Pulish/Subscribe无选择接收消息一个消息生产者一个交换机交换机类型为fanout多个消息队列多个消费者

 

生产者只需把消息发送到交换机绑定这个交换机的队列都会获得一份一样的数据。

 

2.3.4路由模式

在发布/订阅模式的基础上有选择的接收消息也就是通过 routing 路由进行匹配条件是否满足接收消息。

 

2.3.5主体模式

topics(主题)模式跟routing路由模式类似只不过路由模式是指定固定的路由键 routingKey而主题模式是可以模糊匹配路由键 routingKey类似于SQL中 = 和 like 的关系。

 

2.3.6RPC模式

与上面其他5种所不同之处该模式是拥有请求/回复的。也就是有响应的上面5种都没有。

 

RPC是指远程过程调用也就是说两台服务器AB一个应用部署在A服务器上想要调用B服务器上应用提供的处理业务处理完后然后在A服务器继续执行下去把异步的消息以同步的方式执行。

 

2.4RabbitMQ的消息持久化机制

Queue消息队列的持久化是通过durable=true来实现的。

 

Message消息的持久化 通过设置消息是持久化的标识。

 

Exchange交换机的持久化 。

 

2.5RabbitMQ的消息确认机制

confirm机制确认消息是否成功发送到Exchange

 

ack机制确认消息是否被消费者成功消费

 

AcknowledgeMode.NONE自动确认

AcknowledgeMode.AUTO根据情况确认

AcknowledgeMode.MANUAL手动确认

3.RocketMQ

3.1RocketMQ是什么

RocketMQ是阿里开发的一款纯java、分布式、队列模型的开源消息中间件支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。

 

3.2RocketMQ的作用及原理

 

 

基本概念

 

关键名称 说明

Producer 消息生产者

Producer Group 生产者组

Consumer 消息消费者

Consumer Group 消费者组

Topic Topic用于将消息按主题做划分Producer将消息发往指定的TopicConsumer订阅该Topic就可以收到这条消息

Message 代表一条消息

Tag 标签可以被认为是对 Topic 进一步细化

Broker 负责接收并存储消息

Queue Topic和Queue是1对多的关系一个Topic下可以包含多个Queue主要用于负载均衡

Offset RocketMQ在存储消息时会为每个Topic下的每个Queue生成一个消息的索引文件每个Queue都对应一个Offset记录当前Queue中消息条数。

NameServer NameServer可以看作是RocketMQ的注册中心

3.3RocketMQ的通信方式

RocketMQ消息订阅有两种模式

 

一种是Push模式MQPushConsumer即MQServer主动向消费端推送

 

另外一种是Pull模式MQPullConsumer即消费端在需要时主动到MQ Server拉取

 

但在具体实现时Push和Pull模式本质都是采用消费端主动拉取的方式即consumer轮询从broker拉取消息

 

集群模式和广播模式

 

集群模式默认情况下我们都是使用的集群模式也就是说消费者组收到消息后只有其中的一台机器会接收到消息。

 

广播模式消费者组内的每台机器都会收到这条消息。

 

3.