2.6 路由全流程追踪：从发布到入队的每一帧

2.6 路由全流程追踪：从发布到入队的每一帧

本节摘要：本节把本章前五节的知识点装回一次完整投递：从 basic_publish 发出那一刻起，逐帧追踪消息穿过连接、交换机、绑定、队列的每一个内部动作，并对"路由失败"给出三种堵漏方案的对照结论。这张全流程追踪单是全册的中枢图，第 3 章的可靠性方案将在它的延长线上展开。

前五节分别看过消息构造、四类交换机、绑定契约、队列参数与传输底座，知识是散装的。现在把它们串起来：跟着一条 order.created 消息，从客户端内存出发，直到它在队列里安顿下来。每一帧都标注"这一步可能出什么事"——这正是追踪单方法论的完整演示。

逐帧追踪：七个内部动作

图 6 路由全流程追踪单：从发布到入队

对照追踪图，逐帧走一遍并标注风险：

帧 1，客户端编码。pika 把载荷与属性序列化为 AMQP 方法帧加内容帧。风险点：消息体超大导致帧组装缓慢，进程内存翻倍。帧 2，通道发出。帧带上通道号写入 TCP 连接。风险点：若连接已被 Broker 判死，publish 调用抛异常——这是发布方唯一能同步感知的失败。帧 3，Broker 接收。校验虚拟主机权限、交换机是否存在。交换机不存在时通道被关闭并回报 404，发布方能感知。帧 4，交换机判决。按 2.2 节的规则比对绑定表，direct 全等、topic 模式、fanout 全收。此帧纯内存计算，微秒级完成。帧 5，分流。命中则复制写队列；无命中则进入图中的三岔口——静默丢弃是默认行为，mandatory 与备用交换机是两条兜底通道。帧 6，队列接收。执行容量与溢出策略，挂 TTL 时钟。帧 7，回执。只有显式开启发送方确认，Broker 才会告诉发布方"帧 3 之后我收到并处理完了"。没有这一帧，发布方对一切失败都是盲的。

完整演练：亲手触发三种路由失败

背景：光看图不踏实，把 5b 三岔口的每个分支都亲手按一遍。

操作：实验一，验证默认静默丢弃——向没有匹配绑定的键发布，队列数不变，控制台无任何输出。实验二，验证 mandatory 退回：

import pika

connection = pika.BlockingConnection(pika.ConnectionParameters(host="localhost"))
channel = connection.channel()

# 开启 mandatory：无命中绑定时，Broker 把消息退回发布方
returned = []
channel.add_on_return_callback(
    lambda ch, method, properties, body:
        returned.append((method.reply_code, body.decode())))

channel.basic_publish(
    exchange="trace.topic", routing_key="nobody.cares",
    body=b"orphan message", mandatory=True)
connection.process_data_events(time_limit=2)  # 等待退回帧

print("被退回的消息:", returned)
# 预期输出：
# 被退回的消息: [(312, 'orphan message')]   # 312 即 NO_ROUTE
​

实验三，验证备用交换机（Alternate Exchange）：

# 声明备用交换机与兜底队列
channel.exchange_declare(exchange="ae.catchall", exchange_type="fanout")
channel.queue_declare(queue="ae.quarantine")
channel.queue_bind(exchange="ae.catchall", queue="ae.quarantine")

# 主交换机声明时挂上 AE 参数；参数不同会触发 406，需全新名字
channel.exchange_declare(
    exchange="trace.topic.v2", exchange_type="topic",
    arguments={"alternate-exchange": "ae.catchall"})
channel.basic_publish(exchange="trace.topic.v2",
                      routing_key="nobody.cares", body=b"stray message")
​

rabbitmqctl list_queues name messages
# 预期输出：
# ae.quarantine	1
# trace.orders	0
​

结果与解读：mandatory 把决定权还给发布方（同步回执，适合关键业务逐一处理），备用交换机把决定权交给拓扑（统一归集，适合全站兜底 quarantine 队列加告警）。两者可以并存：先走 AE，AE 也接不住再退回。注意实验三的坑：AE 是交换机的声明参数，同样受"参数不可变更"铁律约束，所以要换新名字 trace.topic.v2 声明——2.4 节的铁律在这里再次显灵。

变式：把 mandatory 与发送方确认组合使用，观察退回帧与确认帧的先后：退回发生在路由判决帧，确认发生在入队帧，两者是不同阶段的独立回执——这也是"确认不解决路由失败"结论的直接证据。

本章追踪单小结

到这里，追踪单的前半程走完：消息从生产者出发，穿过帧 1 到帧 7，最终落进队列。已标注的风险点有三个——发布即忘（帧 7 缺席）、路由静默丢弃（帧 5b）、属性缺失（帧 6 生死簿空白）。它们的系统化解法将在第 3 章逐个登场。

把本章六节的知识点再压缩一层，得到一张"路由问诊卡"：消息没到队列——查帧 4 与帧 5（类型与绑定）；消息到了但不对——查帧 1 与帧 2（属性与通道）；消息到了但丢——查帧 6（容量与 TTL）；一切正常但发布方慌——查帧 7（确认没开）。四句口诀覆盖九成路由类求助，比翻文档快得多。

⚠️ 常见坑：以为"发了没报错就是成功了"。本节三个实验的共同教训是：RabbitMQ 的失败默认是安静的，安静不等于平安。回执机制要发布方主动要，Broker 从不主动汇报。

本节要点回顾

• 七帧流程：编码、通道发出、接收校验、交换机判决、分流、入队、回执；
• 三岔口结论：mandatory 逐条退回、AE 统一兜底、确认只保接收，三者互补；
• AE 参数：属于交换机声明参数，受不可变更铁律约束，改名重建才能补挂；
• 中枢图价值：排任何路由问题时，先定位消息死在哪一帧，再对症下药。

消息入队，前半程结束。第 3 章接力后半程：投递、签收与异常处理——消息可靠性真正的主战场。