又老性能又差，为什么好多公司依然选择 RabbitMQ？

大家好，我是君哥。

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，三个命令就可以。

  1. 拉取镜像

  docker pull rabbitmq:3.8.2-management
  

  1. 创建路径

  mkdir /var/lib/rabbitmq
  

  1. 启动容器

  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 种。

  1. Direct Exchange

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

  

  1. Fanout Exchange

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

  

  1. Topic Exchange

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

  

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

  1. 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 成为非常受欢迎的消息队列。