联邦交换机是下游主动拉取上游消息的订阅机制，需全局启用rabbitmq_exchange_federation插件、正确配置带URL编码vhost的URI、绑定匹配类型与名称的policy，并理解其无状态、不保序、无重试等本质特性。
联邦交换机不是“自动同步”，而是下游节点主动拉取上游消息，配置错一个环节，消息就卡住不动。
必须在所有节点启用 rabbitmq_exchange_federation 插件
RabbitMQ 4.x 起，联邦功能已整合进单一插件，旧版的 rabbitmq_federation 和 rabbitmq_federation_management 不再兼容。漏启或启错插件，后续所有配置都无效。
- 执行命令：
rabbitmq-plugins enable rabbitmq_exchange_federation - 每台参与联邦的 broker（无论 upstream 还是 downstream）都必须运行该命令
- Docker 环境下需在容器启动前通过
docker run -e RABBITMQ_PLUGINS="rabbitmq_exchange_federation"或初始化脚本注入，不能只在管理界面点启用 - 启用后重启节点（
rabbitmqctl stop_app && rabbitmqctl start_app），否则新插件不加载
upstream 配置里 URI 必须带 vhost 且 URL 编码
下游节点连接上游时，URI 格式错误是最常见的静默失败原因。它不像普通 AMQP 客户端那样容错，缺字段、vhost 没编码、密码含特殊字符未转义，都会导致连接建立失败，但管理界面可能只显示 “not connected” 而不报具体错误。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 正确格式：
amqp://user:pass@upstream-host:5672/%2f（注意%2f是/的 URL 编码） - vhost 为空时也必须写
%2f，不能省略或写成/ - 若 vhost 为
my_vhost，应编码为my%5fvhost（下划线需转义） - 防火墙必须放行上游节点的 5672 端口（AMQP）和 15672（仅调试用，非必需）
policy 必须绑定到下游 exchange，且匹配名称与类型
Policy 不是“全局开关”，它只作用于指定的下游 exchange。如果 exchange 名称拼错、类型不一致（比如 upstream 是 topic，downstream 创建的是 direct），联邦链路会建立成功，但消息永远不转发。
- 创建 policy 命令示例：
rabbitmqctl set_policy --apply-to exchanges fed-upstream "^exchangeA$" '{"federation-upstream-set":"upstream-set-1"}' -
^exchangeA$是正则表达式，必须完全匹配下游 exchange 名称；不要加多余空格或通配符 - 下游 exchange 必须已存在，且类型（
type字段）与 upstream 的 exchange 类型一致，否则 binding 失败，消息被丢弃 - Policy 中的
federation-upstream-set值，必须与 upstream 配置中定义的 upstream set 名称严格一致（大小写敏感）
网络抖动时消息堆积在 upstream，下游消费延迟不可控
Federation Exchange 是“拉模式”：下游定时连 upstream 拉取消息。这意味着它不保证实时性，也不缓冲下游消费慢带来的压力——所有积压都留在 upstream 的原队列里，可能触发磁盘告警或影响上游业务。
- 默认拉取间隔为 1 秒，可通过
federation.interval调整（单位毫秒），但太小会增加 upstream 负载 - 上游队列若未设置
durable=true且 broker 重启，未拉走的消息直接丢失 - 没有类似 Shovel 的
ack-mode=on-confirm机制，一旦下游接收成功即从 upstream 队列移除，不支持重试补偿 - 若需控制背压，必须在 upstream 侧限制队列长度（
x-max-length）或 TTL（x-message-ttl），否则积压无上限
真正难的不是配通，而是理解“联邦交换机”本质是下游对上游的一次性订阅行为——它不复制状态，不共享元数据，也不保证顺序。跨地域场景下，网络延迟和断连是常态，而它的重连策略、心跳机制、消息确认粒度，都决定了你能不能在丢消息和卡死之间找到平衡点。
