4、RabbitMQ交换机类型：Direct、Topic、Fanout、Headers
交换机（Exchange）是RabbitMQ里最核心的概念之一。说白了，它就是消息的中转站——生产者把消息扔给交换机，交换机再根据规则把消息路由到对应的队列。
我刚开始接触RabbitMQ时，总觉得交换机这玩意儿有点抽象。后来在搭建一个实时行情系统时，被各种路由规则折磨过几轮，才真正搞明白每种交换机的脾气。今天咱们就把这四种交换机掰开揉碎了讲清楚。
一句话总结：交换机决定了消息该往哪儿走。选对了，系统清晰又高效；选错了，后面全是坑。
4.1 Direct Exchange（直连交换机）
这是最直观的一种交换机。它的路由规则很简单：消息的routing key必须和队列绑定的routing key完全一致，才能被路由过去。
我习惯把它比作「对暗号」——你说对了暗号，门就开；说错了，门就关。
适用场景
- 日志级别路由（如：error级别日志走一个队列，info级别走另一个）
- 任务分发（按任务类型精确匹配）
- 点对点通信
代码示例
# 生产者：发送一条routing key为"error"的消息
channel.basic_publish(
exchange='direct_logs',
routing_key='error',
body='这是一条错误日志'
)
# 消费者：绑定队列，只接收"error"级别的消息
channel.queue_bind(
queue='error_queue',
exchange='direct_logs',
routing_key='error'
)我的经验：在交易系统中，我常用Direct Exchange来处理订单状态变更。比如"order.created"、"order.paid"、"order.cancelled"各绑定一个队列，清晰又高效。但要注意——routing key的命名一定要规范，否则后期维护起来很痛苦。
4.2 Topic Exchange（主题交换机）
Topic Exchange比Direct灵活得多。它支持通配符匹配：
*匹配一个单词#匹配零个或多个单词
举个例子：routing key 是 stock.usd.cny，那么 stock.*.cny 能匹配到，stock.# 也能匹配到。
你想想看，这在交易系统里有多好用？
适用场景
- 行情数据分发（按品种、市场、币对等维度）
- 多级分类的日志系统
- 事件驱动架构中的事件路由
代码示例
# 生产者：发送一条BTC/USDT的行情数据
channel.basic_publish(
exchange='market_data',
routing_key='ticker.btc.usdt',
body='{"price": 50000, "volume": 123.45}'
)
# 消费者：订阅所有USDT交易对
channel.queue_bind(
queue='usdt_quotes',
exchange='market_data',
routing_key='ticker.*.usdt'
)我曾经踩过的坑：有一次我把routing key设计成 trade.btc.usdt.binance，然后用 trade.#.binance 去匹配。结果发现性能很差。后来才意识到——# 通配符的匹配开销比 * 大得多。能用 * 就别用 #，这是性能优化的基本原则。
4.3 Fanout Exchange（扇出交换机）
Fanout Exchange最简单粗暴——它把收到的每条消息都广播到所有绑定的队列，完全无视routing key。
说白了就是「群发」。你发一条消息，所有订阅者都能收到。
适用场景
- 广播通知（系统公告、全局配置更新）
- 多消费者并行处理同一份数据
- 缓存刷新
代码示例
# 生产者：发送一条广播消息
channel.basic_publish(
exchange='broadcast',
routing_key='', # Fanout忽略routing key
body='系统将于今晚2:00进行维护'
)
# 消费者A和B：各自绑定队列，都能收到消息
channel.queue_bind(queue='queue_a', exchange='broadcast')
channel.queue_bind(queue='queue_b', exchange='broadcast')我的建议：Fanout虽然简单，但别滥用。我记得有个项目把所有消息都用Fanout广播，结果队列数量一多，性能直线下降。广播是好东西，但得用在刀刃上。
4.4 Headers Exchange（头交换机）
Headers Exchange不依赖routing key，而是根据消息的headers属性来路由。它支持两种匹配模式：
all：所有header键值对都匹配才行（类似AND）any：只要有一个header匹配就行（类似OR）
说实话，这玩意儿我用得最少。但在某些特殊场景下，它确实比Topic更灵活。
适用场景
- 需要多维度匹配的消息路由
- 不想在routing key里编码太多信息
- 动态路由规则
代码示例
# 生产者：设置headers
headers = {'type': 'order', 'priority': 'high', 'version': '2.0'}
channel.basic_publish(
exchange='header_exchange',
routing_key='',
headers=headers,
body='这是一条高优先级订单消息'
)
# 消费者：绑定队列，要求type=order且priority=high
args = {'x-match': 'all', 'type': 'order', 'priority': 'high'}
channel.queue_bind(
queue='high_priority_orders',
exchange='header_exchange',
arguments=args
)注意：Headers Exchange的性能比Direct和Topic差一些。我一般只在路由规则特别复杂、用routing key实在搞不定的时候才用它。能用Direct解决的问题，就别上Headers。
4.5 四种交换机对比
| 类型 | 路由依据 | 匹配方式 | 性能 | 推荐场景 |
|---|---|---|---|---|
| Direct | routing key | 精确匹配 | 高 | 任务分发、日志级别 |
| Topic | routing key | 通配符匹配 | 中高 | 行情数据、事件路由 |
| Fanout | 无 | 广播 | 高 | 广播通知、缓存刷新 |
| Headers | headers属性 | 多维度匹配 | 中 | 复杂路由、动态规则 |
4.6 核心逻辑图
下面这张图展示了四种交换机的核心路由逻辑，我画了很久才画明白——
4.7 选型建议
说了这么多，到底该怎么选？我个人的经验是：
- 先问自己一个问题：消息的路由规则是简单还是复杂？
- 简单规则（精确匹配）→ Direct
- 需要通配符匹配 → Topic
- 需要广播给所有消费者 → Fanout
- 规则复杂到routing key搞不定 → Headers
我的习惯：80%的场景用Topic，15%用Direct，4%用Fanout，1%用Headers。Topic的灵活性足够覆盖大部分需求，而且性能也不错。
嗯，四种交换机就讲到这里。每种都有自己的脾气，选对了能让系统跑得又稳又快。下一节咱们聊聊队列的持久化和消息确认机制——这两个东西在交易系统里可是保命用的。