RabbitMQ具有什么优势，为什么好多公司依然选择 RabbitMQ-Toy模板网

RabbitMQ 这个消息队列相信很多程序员都用过，我第一次使用是在 2016 年，确实是一个老牌的消息队列了，但是为什么一直没有被淘汰呢？今天来聊一聊这个话题。

为什么说RabbitMQ老旧差

发布历史

为什么说 RabbitMQ 老呢？下图是 RabbitMQ 最早的发布记录，可以看到 RabbitMQ 在 2007 年已经发布，已经有 16 年多的使用历史了。

RabbitMQ 使用历史

为什么说 RabbitMQ 比较小众呢？

一方面 RabbitMQ 使用 Erlang 语言编写，这是一个比较小众的编程语言，学习成本非常高，不像 Java、Scala、C 等编程语言学起来简单。所以虽然 RabbitMQ 也是开源的消息队列，但基于 RabbitMQ 做扩展和二次开发的情况是很少的。

另一方面从使用的协议来看，RabbitMQ 支持 AMQP（Advanced Message Queuing Protocol）协议，这也是主流消息队列不支持的。

AMQP 协议如下图：

AMQP 协议

有几个概念介绍一下：

Connection：一个网络连接，AMQP 协议通常使用长连接；
Channel：网络信道，建立在 Connection 之上的轻量级的连接，一个 Connection 可以有多个 Channel；
Exchange：交换器，接收消息后将消息路由转发给绑定（Binding）的 Queue；
Binding：Exchange 和 Queue 之间的虚拟连接；
Routing Key：这个概念在图中没有画，是指路由规则，用来确定 Exchange 将消息路由到哪些 Queue。

可以看到，好多概念在主流的消息队列比如 Kafka、RocketMQ 是没有的，所以说 RabbitMQ 比较小众。

性能差

在底层消息持久化的方式上，RabbitMQ 并没有使用 MMAP、Sendfile 等零拷贝技术，这是性能差的一个重要原因。

在架构上，RabbitMQ 提供了镜像队列来做 Master 的备份。如下图：

RabbitMQ架构

无论生产者发送消息，还是消费者拉取消息，如果请求发送到镜像队列，则镜像队列需要把请求转发到 Master 进行处理，Master 处理后再把结果回复给镜像节点，镜像队列回复给请求者。

在特定硬件环境下，RabbitMQ 支持的消息吞吐量在万级~十万级，相比 RocketMQ 的十万级~百万级和 Kafka 的百万级以上，吞吐量还是差一些。

为什么受欢迎?

从我过往的公司、身边的一些朋友、面试过的候选人简历可以看出，好多公司消息队列技术选型时选择了 RabbitMQ，这跟 RabbitMQ 老旧和性能差形成鲜明对比。

RabbitMQ 为什么这么受欢迎呢？

持续更新

虽然 RabbitMQ 老旧，但是并没有停止更新，而且更新还挺频繁，下图是 2023 年最近发布的几个版本：

2023 年最近发布的几个版本

从 2007 年开始，RabbitMQ 已经有 16 年的使用历史，可以称得上是一个久经考验的战士，各种问题已经修复，学习资料丰富，性能稳定。

运维简单

RabbitMQ 是一个非常轻量级的消息队列，官方宣称开箱即用。在 Docker 上部署 RabbitMQ，三个命令就可以。

拉取镜像

docker pull rabbitmq:3.8.2-management

创建路径

mkdir /var/lib/rabbitmq

启动容器

docker run -d --name rabbitmq3.8.2 -p 5672:5672 -p 15672:15672 -v `pwd`/data:/var/lib/rabbitmq --hostname myRabbit -e RABBITMQ_DEFAULT_VHOST=my_vhost -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin --privileged=true

这种开箱即用的效果，大大降低了学习成本和运维成本。

灵活路由

依托于 AMQP 中的 Exchange，RabbitMQ 提供了灵活的路由配置，有 4 种。

Direct Exchange

生产者将消息发送给 Exchange 后，Exchange 通过 Routing Key 把消息路由到对应的队列。如下图（来自官网）：

Direct Exchange

Fanout Exchange

生产者将消息发送给 Exchange 后，Exchange 将消息路由到所有绑定的队列，类似于广播模式。如下图（来自官网）：

Fanout Exchange

Topic Exchange

这种路由策略首先定义一个 Topic，topic 中可以包含 * 和 #。* 可以代表一个单词，# 可以代表 0 或多个单词。如下图（来自官网）：

Topic Exchange

图中 Topic 由三个单词<celerity>.<colour>.<species>组成，分别代表特征、颜色和物种，单词之间用.间隔。这样 Q1 将接收颜色为 orange 的所有消息，Q2 将接收物种为 rabbit 的消息和特征为 lazy 的消息。

Headers Exchange

这种路由策略要求消息中需要携带 Headers(类似 Http 中的消息头)，队列跟 Routing Key 绑定时也要定义一个 Headers，只有绑定中定义的 Headers 跟消息中的 Header 匹配，才会路由到相应的队列。匹配规则有两种：

ALL：要求两个 Headers 中所有 key 和 value 匹配；
ANY：要求两个 Headers 任何一个 key 和 value 匹配。

如下图：

这种路由方式在定义绑定关系的时候就需要定义 Headers，如下代码：

@Bean
public Binding binding1(HeadersExchange headersExchange,Queue queue1){
 HashMap<String, Object> headers = new HashMap<>();
 headers.put("key1","aaa");
 headers.put("key2","bbb");
 return BindingBuilder.bind(queue1).to(headersExchange).whereAll(headers).match();
}

public Binding binding2(HeadersExchange headersExchange,Queue queue2){
 HashMap<String, Object> headers = new HashMap<>();
 headers.put("key1","aaa");
 headers.put("key2","bbb");
 return BindingBuilder.bind(queue2).to(headersExchange).whereAny(headers).match();
}