大家好，我是君哥。
RabbitMQ 这个消息队列相信很多程序员都用过，我第一次使用是在 2016 年，确实是一个老牌的消息队列了，但是为什么一直没有被淘汰呢？今天来聊一聊这个话题。
老旧差
发布历史
为什么说 RabbitMQ 老呢？下图是 RabbitMQ 最早的发布记录，可以看到 RabbitMQ 在 2007 年已经发布，已经有 16 年多的使用历史了。
小众
为什么说 RabbitMQ 比较小众呢？
一方面 RabbitMQ 使用 Erlang 语言编写，这是一个比较小众的编程语言，学习成本非常高，不像 Java、Scala、C 等编程语言学起来简单。所以虽然 RabbitMQ 也是开源的消息队列，但基于 RabbitMQ 做扩展和二次开发的情况是很少。
另一方面从使用的协议来看，RabbitMQ 支持 AMQP（Advanced Message Queuing Protocol） 协议，这也是主流消息队列不支持的。
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 的备份。如下图：
无论生产者发送消息，还是消费者拉取消息，如果请求发送到镜像队列，则镜像队列需要把请求转发到 Master 进行处理，Master 处理后再把结果回复给镜像节点，镜像队列回复给请求者。
在特定硬件环境下，RabbitMQ 支持的消息吞吐量在万级~十万级，相比 RocketMQ 的十万级~百万级和 Kafka 的百万级以上，吞吐量还是差一些。
受欢迎
从我过往的公司、身边的一些朋友、面试过的候选人简历可以看出，好多公司消息队列技术选型时选择了 RabbitMQ，这跟 RabbitMQ 老旧和性能差形成鲜明对比。
RabbitMQ 为什么这么受欢迎呢？
持续更新
虽然 RabbitMQ 老旧，但是并没有停止更新，而且更新还挺频繁，下图是 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 把消息路由到对应的队列。如下图（来自官网）：
Fanout Exchange
生产者将消息发送给 Exchange 后，Exchange 将消息路由到所有绑定的队列，类似于广播模式。如下图（来自官网）：
Topic Exchange
这种路由策略首先定义一个 Topic，topic 中可以包含 * 和 #。* 可以代表一个单词，# 可以代表 0 或多个单词。如下图（来自官网）：
图中 Topic 由三个单词..组成，分别代表特征、颜色和物种，单词之间用.间隔。这样 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 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 headers = new HashMap();
headers.put("key1","aaa");
headers.put("key2","bbb");
return BindingBuilder.bind(queue2).to(headersExchange).whereAny(headers).match();
}客户端丰富
RabbitMQ 客户端支持的编程语言是消息队列中最多的，很容易兼容自己系统使用的编程语言。参考下图（来自官网）：
总结
RabbitMQ 虽然老旧，但具有运维简单、灵活路由、客户端丰富等特性。虽然吞吐量不高，但性能足够满足中小企业的使用需求。这让 RabbitMQ 成为非常受欢迎的消息队列。
