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

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系统中，如何保证他们的事务一致性。

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

特性	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.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 单条消息确认

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

2.RabbitMQ

2.1：RabbitMQ是什么

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

2.2：RabbitMQ的作用及原理