RabbitMQ

1. 什么是RabbitMQ呢？

RabbitMQ是基于AMQP协议使用ErLang开发的一个开源的消息队列服务器（消息中间件）。
它主要在分布式系统中实现异步通信，应用解耦和流量削峰等功能。
RabbitMQ的核心组件包括：生产者，消费者，交换机，队列，绑定等。消息经过交换机路由到队列，同时支持多种路由模式（直连，扇出，主题等）。
同时支持多种语言调用。
RabbitMQ主要具有高可用，消息持久化，灵活的路由规则等特性。
常常用于订单处理，任务队列等场景。

2. 解决的问题

主要解决异步通信，应用解耦，流量削峰等问题：

  • 应用解耦：服务之间不再直接依赖，通过消息传递通信，一个服务修改不影响其他服务；
  • 异步通信：非核心流程（如短信通知、日志记录）通过消息队列异步执行，提升主流程响应速度；
  • 流量削峰：高并发场景下（如秒杀），将请求消息暂存队列，消费端按能力匀速处理，避免服务被压垮。

3. RabbitMQ的缺点

  1. 性能上限较低，不适合超大规模高吞吐场景
  • 核心问题：RabbitMQ 的设计初衷是保证消息可靠性和路由灵活性，而非极致的吞吐量。其单节点吞吐量约为万级 / 秒（消息大小为 1KB 左右），远低于 Kafka 的十万级 / 秒、RocketMQ 的十万级 / 秒。
  1. Erlang 语言带来的开发与运维门槛
  • 二次开发难度大：RabbitMQ 的底层由 Erlang 开发，而 Erlang 是一门小众函数式语言，国内开发者掌握度低。如果业务需要对 RabbitMQ 进行定制化开发（如修改核心组件、扩展协议），几乎无法实现。
  1. 集群架构与消息堆积的运维成本高
  • 集群架构复杂：RabbitMQ 的高可用方案（如镜像队列、主从集群）配置繁琐，节点间的同步机制（如镜像队列的同步策略）会消耗额外资源，且集群扩容时需要考虑队列的重新分布，操作成本高。
  1. 部分高级特性支持不足或体验不佳
  • 延迟队列实现繁琐：RabbitMQ 没有原生的延迟队列功能，需要通过死信队列 + TTL（消息过期时间） 模拟，这种方式存在 “消息过期时间不一致、堆积时延迟不准确” 的问题，而 RocketMQ、Redis（ZSet）原生支持精准的延迟队列。
  1. 与云原生生态的融合度不如新兴 MQ
  • 随着云原生的普及，Kafka、Pulsar 等 MQ 原生支持容器化部署、动态扩缩容、云平台集成（如 K8s 的 Operator），而 RabbitMQ 的云原生适配相对滞后，虽然也支持容器化，但在自动化运维、弹性伸缩等方面的体验不如前者。