RabbitMQ
路由最灵活的经典消息队列，业务解耦的第一选择
RabbitMQ 是最“像邮局”的消息队列：生产者不直接把信送到收件人手里，而是交给交换机（Exchange），交换机按规则把信分到不同信箱（Queue）。灵活的路由规则是它最大的特点，也因此特别适合业务系统之间做解耦。
它解决什么问题
一个支付成功事件，风控要同步一份、积分要加、短信要发、数据组要统计。直接调四家接口，任何一家挂了都会影响支付主流程。
真实场景：典型场景：支付服务把消息发给一个 topic 类型的 Exchange，路由键是 pay.success，风控、积分、通知三个队列各自绑定自己关心的规则，谁挂了都不影响支付。
核心概念
每个概念一句话 + 一个类比。点击卡片看更详细的解释。
Exchange
接收消息并按规则路由到队列，本身不存消息
类比：邮局的分拣中心
看概念详情Queue
真正存消息的地方，消费者从这里取
类比：家门口的信箱
看概念详情Binding
Exchange 和 Queue 之间的路由规则
类比：分拣中心墙上的“发往朝阳区的走 3 号口”
看概念详情RoutingKey
生产者发消息时带的地址标签
类比：信封上写的收件地址
看概念详情Channel
一条 TCP 连接里复用的轻量会话，几乎所有操作都在 Channel 上做
类比：一根网线里开的多条车道
看概念详情VHost
逻辑隔离的命名空间，不同业务用不同 VHost 互不干扰
类比：一栋楼里不同的公司，各有各的前台
看概念详情数据流转动画
跟着步骤看一条数据从进入系统到被处理完的完整路径，可以暂停、重播和调速。
Exchange 的三种路由方式
← 左右滑动查看完整流程图 →
生产者把消息发到 Exchange，带上 routingKey=order.pay。
提示：Direct 精确匹配、Topic 通配匹配、Fanout 无视路由键全部广播。 悬停图中的节点可以看概念解释。
优劣势
短句说清适合什么、不适合什么，选型时先看这一栏。
- 路由能力最强，Direct/Topic/Fanout/Headers 四种交换机
- 开箱即用，管理界面友好，入门成本最低
- 支持消息优先级、TTL、死信队列
- 多语言客户端成熟
- 吞吐量只有万级，远低于 Kafka
- 消息堆积时性能下降明显（内存优先）
- Erlang 技术栈，出问题排查门槛高
- 集群队列的镜像同步在高堆积下容易抖动
常见使用场景
每个场景都配一句「为什么用它」。
业务系统解耦
支付成功后广播给积分、通知、风控，各自订阅。
为什么用它：Fanout/Topic 加队列绑定，新增下游只加一个队列。
延迟任务与重试
下单 30 分钟未支付关单；消费失败进死信队列人工处理。
为什么用它：TTL + 死信队列组合可以实现延迟和重试。
任务分发
图片转码、报表生成这类耗时任务，丢进队列让 worker 慢慢做。
为什么用它：一条消息只被一个 worker 消费，天然适合任务队列。
同类对比
和同赛道的组件并排看，差异一目了然。
一句话：吞吐选 Kafka，业务语义选 RocketMQ，路由灵活和轻量选 RabbitMQ。三者不是替代关系，很多公司同时用两个。
常见问题
上手第一个月最容易卡住的地方。
Q1四种 Exchange 有什么区别？
Direct 按 routingKey 精确匹配；Topic 支持 * 和 # 通配；Fanout 忽略 key 广播给所有绑定队列；Headers 按消息头键值匹配，性能差、很少用。
Q2消息堆积怎么办？
先加消费者（不能超过队列数），再考虑拆分队列；开启 lazy queue 让消息直接落盘；极端情况临时扩容节点。根本办法是提高消费速度或限流生产端。
Q3和 Kafka 选哪个？
要百万级吞吐、日志流处理选 Kafka；要灵活路由、低延迟、业务解耦、消息优先级选 RabbitMQ。业务消息量不大时，RabbitMQ 更省心。
Q4消息丢失可能发生在哪？
三处：生产者没开 confirm、Exchange 没有绑定队列、消费者自动 ACK 但处理失败。对应解法：开启 publisher confirm + mandatory、声明持久化队列、改手动 ACK。
Q5Channel 和 Connection 的关系？
一个 Connection 是一条 TCP 连接，一个 Channel 是连接内的逻辑会话。频繁建连接开销大，所以复用 Connection、每个线程用自己的 Channel。Channel 不是线程安全的。