大家好，我是君哥。

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