图解 RabbitMQ 01|为什么是消息队列:异步、解耦、削峰与 Rabbit 的位置
消息队列被讲成「一个发消息的中间件」,但它真正解决的是异步、解耦和削峰这三类系统级问题。这一篇先把 MQ 的价值坐标立起来,再说 Rabbit 在其中站的位置。
从异步解耦削峰与选型开始,拆到 AMQP 模型、路由、队列存储、客户端治理、集群高可用和运维排障。
适合想把 RabbitMQ 从命令手册理解到可靠性闭环、路由设计和集群治理的后端工程师。
为什么是 MQ、选型边界、AMQP 模型、队列语义、可靠性三问与投递闭环。
四种交换器、路由键匹配、死信 TTL、优先级延迟惰性队列与路由实战。
经典队列存储、ETS 持久化、镜像队列废弃、Quorum Queue 与 Stream。
连接与信道、连接池熔断、消费者并发 prefetch 与 broker 流控。
集群拓扑、Khepri 元数据、网络分区治理与 Federation/Shovel 容灾。
监控排障闭环与 RabbitMQ 的适用边界和选型判断。
消息队列被讲成「一个发消息的中间件」,但它真正解决的是异步、解耦和削峰这三类系统级问题。这一篇先把 MQ 的价值坐标立起来,再说 Rabbit 在其中站的位置。
选消息队列不是选「最好」的那个,而是选「最匹配场景」的那个。这篇把 RabbitMQ、Kafka、RocketMQ 的吞吐、可靠、路由、延迟、协议这几根轴量化,给一个能落地的选型判断。
RabbitMQ 的一切机制都建立在 AMQP 模型上:Producer、Exchange、Queue、Consumer 四要素,外加 Binding 连接它们。看懂这张图,复杂度降一半。
消息队列有两种基本模型:点对点和发布订阅。RabbitMQ 用一套队列+交换器机制,把两种模型统一了。理解这条缝在哪,才能正确设计消费拓扑。
消息队列的可靠性只有三个问题:消息不丢、消息不重、消息有序。这一篇把 RabbitMQ 对这三个问题的回答讲透,并说清哪个能靠 MQ 本身解决,哪个必须靠业务。
RabbitMQ 的可靠投递靠三个机制配合:confirm 确认 broker 收到、return 处理路由失败、ack 确认消费完成。这篇把这三个机制的角色和配合讲透,再给一个生产级配置模板。
RabbitMQ 的路由能力集中在四种交换器上:direct 精确匹配、fanout 广播、topic 通配、headers 按头匹配。这篇把四种的路由语义和适用场景讲清,并说清怎么选。
topic Exchange 的威力全在 RoutingKey 和 BindingKey 的设计上。这篇讲清两者的区别、点号层级的规划、通配符的边界,以及怎么设计一套能演化的路由键命名规范。
RabbitMQ 里消息不是「要么消费要么丢弃」,它还有第二次生命——死信队列让失败的消息有去处,TTL 让消息按时过期。两者结合还能实现延迟队列。
队列不只是 FIFO。RabbitMQ 的队列还能设优先级、能变惰性、能独占连接。这篇讲清这些进阶形态各自的语义、代价和适用边界,避免用错形态增加复杂度。
不是所有队列都该持久化。RPC 的回复队列、动态消费者的临时队列,都该随连接或消费者的生命周期生灭。这篇讲清临时队列和独占模式的用法与边界。
前面几篇拆完了交换器、路由键、死信、TTL、队列形态。这一篇把它们组合起来,用四个常见业务场景演示路由拓扑怎么设计,以及设计时要避开的几个坑。
经典队列是 RabbitMQ 的元老队列类型。它的存储一直在内存和磁盘间做取舍——这个取舍怎么做的、3.12 之后发生了什么变化、什么时候还该用它,这篇讲清。
RabbitMQ 用 Erlang 写的,消息存储绕不开 ETS 这个 Erlang 的内存表。这篇讲清持久化消息和非持久化消息在 ETS 和磁盘间的不同路径,以及它对性能和容量的影响。
镜像队列曾是 RabbitMQ 高可用的标准方案,但 RabbitMQ 4.0 把它彻底移除了。为什么?这篇讲清主从复制模型在分布式环境下的固有缺陷,以及它为什么必然被 Raft 取代。
镜像队列被废弃后,Quorum Queue 接过了高可用的接力棒。它基于 Raft 做强一致复制,解决了主从复制的脑裂和丢失问题。这篇讲清它怎么工作、什么时候该用、代价是什么。
Stream 是 RabbitMQ 3.9 引入的第三种队列类型,思路完全不同——它不是队列,而是类 Kafka 的追加日志。这篇讲清它和队列的语义差别、重放能力,以及什么时候该用它。
RabbitMQ 客户端有两层连接抽象:Connection 是 TCP 连接,Channel 是其上的虚拟信道。为什么用 Channel 而不是多开 Connection,是客户端性能和资源治理的基础。
光会开连接还不够,生产环境要管好连接的生命周期。这篇讲清连接池怎么设计、重连怎么做、什么时候该熔断,避免 broker 故障把应用拖垮。
消费者吞吐的核心参数是 prefetch。设大了消息堆积在客户端内存,设小了吞吐上不去。这篇讲清 prefetch 的工作机制、怎么定值,以及它怎么充当背压。
prefetch 是消费者侧的背压,broker 侧也有自己的流控——当内存或磁盘吃紧,它会阻塞生产者保护自己。这篇讲清 RabbitMQ 的内存/磁盘告警和 credit 流控机制。
RabbitMQ 集群是多个节点共享元数据、但消息不默认复制的结构。这篇讲清集群的拓扑、disk/ram 节点的区别、集群和高可用的关系,以及一个常见误解。
RabbitMQ 的元数据存在哪?答案是 Mnesia——Erlang 自带的分布式数据库。但它有脑裂隐患,于是有了基于 Raft 的 Khepri。这篇讲清这场演进的来龙去脉。
网络分区是分布式系统最棘手的故障。RabbitMQ 怎么检测分区、分区时各组件表现如何、pause_minority 为什么是最安全的策略,这篇讲清治理思路。
集群解决单机房的高可用,但跨机房怎么办?RabbitMQ 给了两个答案:Federation 做集群联邦,Shovel 做单向搬运。这篇讲清两者的差别和适用场景。
前 25 篇拆完了机制,这一篇落到运维。消息积压、publish 阻塞、连接泄漏是最常见的三类线上问题。这篇把它们的成因、定位方法、处理动作收成一个排查闭环。
图解 RabbitMQ 系列的收束篇。把 27 篇六个阶段串成一张地图,收成「该不该用 RabbitMQ、用的时候要注意什么」的判断——它是复杂路由与高可靠的在线业务队列,不是万能 MQ。