rabbitmq federation 不支持真正的双向同步，仅通过分别配置 a→b 和 b→a 两套独立单向拉取链路实现业务级互通；消息异步转发、无强一致保证，java 应用无需特殊编码，但需确保双集群 exchange/vhost 一致、启用 tls、配置幂等消费。
RabbitMQ 本身不支持真正的“双向同步”，Federation 插件只提供单向、异步、基于拉取（pull-based）的消息转发能力。所谓“双向”，实际是通过在两个集群上**各自配置一套独立的 Federation 关系**来模拟：A→B 和 B→A 两套单向链路。这不是原子性双向复制，也不保证顺序或强一致，但能支撑广域网（如香港↔上海）下的业务级消息互通。
明确 Federation 的双向本质
Federation 没有内置双向模式。它的工作机制是：下游集群主动连接上游集群，拉取新到达的消息。因此，“双向”必须手动对称配置：
- SH 集群作为下游，联邦到 HK 集群（即 SH 拉取 HK 的 exchange 消息）
- HK 集群作为下游，联邦到 SH 集群（即 HK 拉取 SH 的 exchange 消息）
- 两边的 exchange 名称、vhost、绑定关系需严格一致，否则路由失败
- 两边的 upstream 定义、policy 规则、用户权限也需分别独立配置，互不影响
Java 应用层无需特殊编码
Java 端使用标准 AMQP 客户端（如 Spring AMQP 或 rabbitmq-java-client）即可，Federation 对生产者和消费者完全透明：
Java Development Manual
下载
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
- 生产者仍调用
channel.basicPublish(exchangeName, routingKey, ...)，发往本地 exchange - 消费者仍监听本地队列，消息由 Federation 插件自动拉入，与普通本地消息无区别
- 无需在 Java 代码中感知跨集群逻辑，也不用处理重试、确认模式等底层细节
- 唯一要注意的是：确保所用 vhost 和 exchange 在两个集群中已存在且名称完全一致
关键配置项与注意事项
真正起作用的是 RabbitMQ 服务端配置，Java 应用只需配合这些约定：
-
Upstream 连接：每个集群都要定义指向对方的 upstream，URI 中需含可用账号（如
amqp://feduser:pass@hk-ip:5672），该账号需在对方集群中有对应 vhost 权限 -
Ack-mode 选型：广域网建议用
on-confirm（默认），确保消息至少被下游 broker 接收成功；no-ack虽快但易丢，慎用 -
Policy 绑定范围：用正则匹配 exchange 名（如
"^order\.events$"），避免误联邦其他 exchange；策略作用域设为exchanges，不是 queues -
网络与 TLS：跨公网务必启用 TLS（
amqps://...）并校验证书；防火墙需放行 5671/5672 端口及管理端口（如 15672） - 幂等消费必需：因网络重试或插件重启，同一条消息可能被重复拉取，Java 消费者必须自行实现幂等（如基于 message-id + DB 去重表或 Redis set）
为什么不推荐用 Federation 做“强同步”
理解它的边界，才能合理使用：
- 消息不会实时同步，延迟取决于 upstream 心跳、prefetch、网络抖动，通常在数百毫秒到数秒级
- 已有队列中的历史消息不会被拉取，只转发新到达的消息
- 下游消费 ack 不影响上游队列状态——HK 消费了消息，SH 队列里的副本仍存在，可被 SH 消费者再次消费
- 没有跨集群事务，无法保障“HK 发 + SH 收”原子性；若需最终一致性，应靠业务层补偿或 Saga 模式
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
