RabbitMQ、RocketMQ 、Kafka区别

引言

1、队列应用场景：

MQ（Message Queue，消息队列）
消息队列在实际应用中常用的使用场景（优点）：异步处理，应用解耦，流量削锋和消息通讯四个场景。

2、目前使用较多的消息队列：

有老牌的ActiveMQ、RabbitMQ，ZeroMQ，炙手可热的Kafka，MetaMQ，阿里巴巴的RocketMQ。

3、如何选型（目前现状）：

ActiveMQ，性能不是很好，因此在高并发的场景下，直接被pass掉了。它的Api很完善，在中小型互联网公司可以去使用。最早大家都用 ActiveMQ，但是现在确实大家用的不多了，社区也不是很活跃，不推荐用这个了；

后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高，可视化的管理界面比较友好；

不过现在确实越来越多的公司，会去用 RocketMQ，确实很不错（阿里出品），它是纯Java开发，它高性能、满足可靠性、分布式事物、支持水平扩展、上亿级别的消息堆积、主从之间的切换等等。MQ的所有优点它基本都满足。但是它最大的缺点：商业版收费。但社区可能有突然黄掉的风险，对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则老老实实用 RabbitMQ 吧，毕竟RabbitMQ有活跃的开源社区，绝对不会黄。

所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。

如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，适合产生大量数据的互联网服务的数据收集业务等。社区活跃度很高，何况几乎是全世界这个领域的事实性规范。kafka，主要强调高性能，如果对业务需要可靠性消息的投递的时候。那么就不能够选择kafka了。

4、使用消息队列缺点：

• 系统可用性降低：系统引入的外部依赖越多，越容易挂掉，万一MQ挂了，整套系统崩溃了。
• 系统复杂性提高：加MQ进来，怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？
• 一致性问题：A系统处理完了直接返回成功了，后面的如果失败了，这数据就不一致了。

一、RabbitMQ

1、RabbitMQ概述

AMQP，即Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。
AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。

RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。RabbitMQ服务器是用Erlang语言编写的。

RabbitMQ 是比较有代表性的，因为是基于主从（非分布式）做高可用性的。

2、RabbitMQ原理图

RabbitMQ通过信道的方式传输数据，将消息发布到交换机上，消息拥有一个路邮键，由消息创建时设定，通过队列路由键，可以把队列绑定到交换机上，消息到达交换机后，RabbitMQ将消息的路由键与队列的路由键进行匹配（不同的交换机有不同的路由规则），匹配到相应的队列，消息投递到队列的队列中供消费者消费。

多个消费者可以订阅同一个Queue，消息将以循环（round-robin）的方式发送给消费者，每条消息只会发给一个订阅的消费者，而不是每个消费者都收到所有的消息并处理。

每个Channel运行在独立的线程上，多个线程共享同一个socket。

相关概念：

• ConnectionFactory（连接管理器）：应用程序与Rabbit之间建立连接的管理器，程序代码中使用；
• Broker：简单来说就是消息队列服务器实体。
• Channel（信道）：消息推送使用的通道；
• Exchange（交换器）：用于接受、分配消息；
• Queue（队列）：用于存储生产者的消息；
• RoutingKey（路由键）：用于把生成者的数据分配到交换器上；【最大255个字节】
• BindingKey（绑定键）：用于把交换器的消息绑定到队列上；【最大255个字节】
• vhost（虚拟主机）每个Rabbit都能创建很多vhost，每个虚拟主机其实都是mini版的RabbitMQ，拥有自己的队列，交换器和绑定，拥有自己的权限机制。

3、RabbitMQ常用的三种交换机

RabbitMQ常用的三种Exchange：fanout,direct,topic

（1）Direct Exchange ：

直连型交换机，根据消息携带的路由键将消息投递给对应队列。
　　大致流程，有一个队列绑定到一个直连交换机上，同时赋予一个路由键 routing key。　然后当一个消息携带着路由值为X，这个消息通过生产者发送给交换机时，交换机就会根据这个路由值X去寻找绑定值也是X的队列。

（2）Fanout Exchange：

扇型交换机，这个交换机没有路由键概念，就算你绑了路由键也是无视的。 这个交换机在接收到消息后，会直接转发到绑定到它上面的所有队列。

（3）Topic Exchange：

主题交换机，这个交换机其实跟直连交换机流程差不多，但是它的特点就是在它的路由键和绑定键之间是有规则的。
　　
性能排序：fanout > direct >> topic。

4、 RabbitMQ集群元数据

RabbitMQ集群会始终同步四种类型的内部元数据：

• a. 队列元数据：队列名称和它的属性

• b. 交换器元数据：交换器名称、类型和属性

• c. 绑定元数据：一张简单的表格展示了如何将消息路由到队列

• d. vhost元数据：为vhost内的队列、交换器和绑定提供命名空间和安全属性

5、RabbitMQ镜像集群

RabbitMQ 有三种模式：单机模式、普通集群模式（无高可用性）、镜像集群模式（高可用性）。

镜像队列将需要消费的队列变成镜像队列，存在于多个节点，实现RabbitMQ的高可用，保证 100% 数据不丢失。作用就是消息实体会主动在镜像节点之间实现同步，而不是像普通模式那样，在消费者消费数据时临时拉取，缺点就是集群内部的同步通讯会占去大量的网络带宽。

二、RocketMQ

RocketMQ是阿里开源的消息中间件，目前也已经孵化为Apache顶级项目。用Java语言实现，在设计时参考了Kafka，并做出了自己的一些改进，消息可靠性上比Kafka更好。RocketMQ在阿里内部被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。

RocketMQ缺点：

• 单机支持1万以上持久化队列；
• RocketMQ的所有消息都是持久化的，先写入系统PAGECACHE，然后刷盘，可以保证内存与磁盘都有一份数据，而访问时，直接从内存读取。
• 模型简单，接口易用（JMS的接口很多场合并不太实用）；
• 性能非常好，可以允许大量堆积消息在Broker中；
• 支持多种消费模式，包括集群消费、广播消费等；
• 各个环节分布式扩展设计，支持主从和高可用；
• 开发度较活跃，版本更新很快。

RocketMQ缺点：

• 支持的 客户端语言不多，目前是Java及C++，其中C++还不成熟
• 维护RocketMQ需要专业的团队
• 商业版收费，有许多功能是不对外提供的。
• 没有在MQ核心里实现JMS等接口

三、kafka

1、kafka概述

kafka是Linkedin于2010年12月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。作为hadoop生态系统的一部分，被各种商业公司广泛应用。

kafka优点：

• 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒
• 可扩展性：kafka集群支持热扩展
• 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
• 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
• 高并发：支持数千个客户端同时读写

kafka缺点：

• 快速持久化：可以在O(1)的系统开销下进行消息持久化；
• 高吞吐：在一台普通的服务器上既可以达到10W/s的吞吐速率；
• 完全的分布式系统：Broker、Producer和Consumer都原生自动支持分布式，自动实现负载均衡；
• 支持同步和异步复制两种高可用机制；
• 支持数据批量发送和拉取；
• 零拷贝技术(zero-copy)：减少IO操作步骤，提高系统吞吐量；
• 数据迁移、扩容对用户透明；
• 无需停机即可扩展机器；
• 其他特性：丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力、定期删除机制

2、kafka原理图

四、总结