ActiveMQ、RabbitMQ、RocketMQ、Kafka四种消息中间件分析介绍

我们从四种消息中间件的介绍到基本使用，以及高可用，消息重复性，消息丢失，消息顺序性能方面进行分析介绍！

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

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

1.解耦

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

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

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

2.异步

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

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

3.削峰

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

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

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

二、消息中间件的优缺点

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

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

1.系统可用性降低

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

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

2.系统复杂度提高

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

3.一致性问题

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

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

1.ActiveMQ

1.1：Activemq是什么

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

1.2：Activemq的作用及原理

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

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

1.3：Activemq的通信方式

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

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

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

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

1.4：Activemq的消息持久化机制

JDBC：持久化到数据库AMQ：日志文件（已基本不用）KahaDB：AMQ基础上改进，默认选择LevelDB：谷歌K/V数据库在activemq.xml中查看默认的broker持久化机制。

1.5：Activemq的消息确认机制

（1）AUTO_ACKNOWLEDGE=1自动确认

（2）CLIENT_ACKNOWLEDGE=2客户端手动确认

（3）DUPS_OK_ACKNOWLEDGE=3自动批量确认

（4）SESSION_TRANSACTED=0事务提交并确认

（5）INDIVIDUAL_ACKNOWLEDGE=4单条消息确认

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

2.RabbitMQ

2.1：RabbitMQ是什么

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

2.2：RabbitMQ的作用及原理

基本概念

2.3：RabbitMQ的通信方式

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.6：RPC模式

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

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

2.4：RabbitMQ的消息持久化机制

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

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

Exchange（交换机）的持久化。

2.5：RabbitMQ的消息确认机制

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

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

AcknowledgeMode.NONE：自动确认

AcknowledgeMode.AUTO：根据情况确认

AcknowledgeMode.MANUAL：手动确认

3.RocketMQ

3.1：RocketMQ是什么

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

3.2：RocketMQ的作用及原理

基本概念

3.3：RocketMQ的通信方式

RocketMQ消息订阅有两种模式

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

另外一种是Pull模式（MQPullConsumer），即消费端在需要时，主动到MQServer拉取

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

集群模式和广播模式

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

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

3.4：RocketMQ的消息持久化机制

exchange持久化、queue持久化、message持久化

CommitLog：日志数据文件，存储消息内容，所有queue共享，不区分topic，顺序读写，1G一个文件

ConsumeQueue：逻辑Queue，基于topic的CommitLog的索引文件，消息先到达

转载请注明:http://www.aideyishus.com/lkjg/4926.html