RabbitMQ常用Exchange类型为direct、fanout、topic三种：direct要求routing_key完全匹配binding_key，适合点对点或固定分组；fanout无视routing_key，广播至所有绑定队列，适合事件通知；topic支持*和#通配符模式匹配，灵活但易出错，适用于多维路由场景。
RabbitMQ 里真正常用、有明确语义且被广泛支持的 Exchange 类型就三种：direct、fanout、topic。 headers 和 default（即空字符串名的 direct）虽存在，但 headers 实际极少用（配置复杂、性能差、客户端支持不一），default 仅用于简化单队列直连场景，不算独立选型依据。
direct 交换机：路由键必须完全匹配才投递
它只做字符串级别的精确比对：消息的 routing_key 必须和某个队列绑定时指定的 binding_key 完全一致，消息才会进那个队列。不匹配就丢弃（除非配置了死信）。
- 适合一对一或固定分组的任务分发，比如按日志级别分流：
error→ error-queue，info→ info-queue - 微服务间点对点命令下发，如
order.cancel只路由到订单取消处理器队列 - 注意：一个
routing_key可绑定多个队列，但一个消息只能进一个队列（除非重复发） - 性能高、逻辑透明，是默认入门首选；但扩展性差——新增路由规则就得改代码+加 binding
fanout 交换机：不看路由键，强制广播给所有绑定队列
它压根不检查 routing_key，哪怕你传了也无视。只要队列绑定了这个 fanout 交换机，消息必达每一份副本。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 典型用于事件广播：用户注册成功后，同时触发发邮件、写画像、发优惠券，三个消费者各自监听同一 fanout 的不同队列
- 缓存失效通知：修改商品信息后，向 fanout 发一条消息，所有服务监听并清本地缓存
- 没有路由开销，吞吐最高；但无法过滤，所有订阅者都得处理（或自行忽略）
- 不能用 routing_key 做任何区分，想“部分广播”就得换 topic 或拆多个 fanout
topic 交换机：靠通配符做模式匹配，最灵活也最易出错
它用 routing_key 和 binding_key 做模式匹配，支持两个通配符：*（匹配单个单词）、#（匹配零个或多个单词），单词之间用 . 分隔。
- 适用多维标签路由：比如日志系统中，
us.east.error.db能同时匹配us.*.error.#和#.db - 微服务事件总线：订单服务发
order.created.us，风控服务绑order.*.us，物流服务绑order.created.# - 容易踩坑：binding_key 中的
#不能出现在中间（如a.#.b非法），*不匹配空段（a..b里两个点之间为空，a.*.b就不匹配） - 匹配逻辑隐含层级，调试困难；生产环境建议限制单词数（如最多 4 段），避免
#匹配爆炸
真正难的是设计好 routing_key 的分段语义和 binding_key 的粒度平衡——太粗失去灵活性，太细导致 binding 泛滥、维护成本陡增。实际项目里，80% 的场景用 direct + fanout 组合就能覆盖，topic 留给确实需要多条件动态路由的少数模块。
