发布&订阅模型

1. 什么是发布/订阅模型

发布/订阅模型（Publish/Subscribe） 是在工作消息队列基础上引入了交换机（Exchange） 的消息传递机制。生产者不再直接向队列发送消息，而是发送给交换机，由交换机根据类型和绑定规则将消息路由到一个或多个队列，从而实现一条消息被多个消费者接收。

与前两种模型的对比：

                        ┌──Binding──▶ Queue1 ──▶ Consumer1
Publisher ──▶ Exchange ─┤
                        └──Binding──▶ Queue2 ──▶ Consumer2

将消息广播到所有绑定的队列，完全忽略 Routing Key。

Exchange(fanout) ──▶ Queue1 ──▶ Consumer1
                 ──▶ Queue2 ──▶ Consumer2
                 ──▶ Queue3 ──▶ Consumer3

适用场景：系统广播通知（如全体用户推送、缓存刷新通知）。

根据 Routing Key 精确匹配 Binding Key，只有匹配的队列才会收到消息。

消息(key=error)  ──▶ Exchange(direct) ──▶ error队列  ──▶ 错误日志消费者
消息(key=info)   ──▶ Exchange(direct) ──▶ info队列   ──▶ 普通日志消费者

适用场景：按日志级别分发（error/warn/info）、按业务类型路由。

支持通配符匹配 Routing Key，规则如下：

通配符	含义
`*`	匹配一个单词
`#`	匹配零个或多个单词

Routing Key: order.created.shanghai
Binding Key: order.*        ✗ 不匹配（只能匹配一个词）
Binding Key: order.#        ✓ 匹配
Binding Key: *.created.*    ✓ 匹配

适用场景：多维度路由，如按地区+业务类型组合分发消息。

根据消息的 Header 键值对匹配队列，完全忽略 Routing Key。匹配模式分两种：

适用场景：路由逻辑复杂、无法用字符串 Key 描述的场景（实际项目中较少使用）。

RabbitMQ 内置的特殊 Direct Exchange，名称为空字符串。每个队列自动以队列名作为 Binding Key 绑定到它，无需手动声明绑定关系。

适用场景：基本消息队列和工作消息队列底层默认使用的就是它。

类型	路由方式	是否用 Routing Key	典型场景
Fanout	广播所有绑定队列	✗	全局通知、缓存刷新
Direct	精确匹配	✓	日志分级、任务路由
Topic	通配符匹配	✓	多维度路由
Headers	Header 键值对匹配	✗	复杂属性路由
Default	队列名即路由键	✓	简单点对点（内置）

优点：

缺点：