rabbitmq federation 不支持真正双向同步，仅通过上海↔香港两套独立单向拉取链路实现业务级互通；java应用无需修改代码，只需确保vhost/exchange一致、消费者幂等、服务端配好upstream/tls/policy/ack-mode/心跳。
Java 应用本身不参与 Federation 的跨地域同步逻辑，RabbitMQ Federation 是服务端插件机制，Java 只需按标准 AMQP 方式收发消息，同步由 Broker 自动完成。关键在 RabbitMQ 集群的配置一致性与网络可靠性，Java 层只需配合约定、做好幂等。
核心思路：双向单向链路，不是真正双向同步
Federation 插件只支持单向拉取（pull-based），所谓“跨地域同步”实际是两套独立配置：
- 上海集群作为下游，联邦到香港集群（即上海主动拉取香港 exchange 的新消息）
- 香港集群作为下游，联邦到上海集群（即香港主动拉取上海 exchange 的新消息）
- 两边的 vhost、exchange 名称、绑定关系、路由键必须完全一致，否则消息无法正确路由
- 不存在跨集群事务或顺序保证，也不复制历史消息，只转发新到达的消息
Java 应用要做的三件事
代码无需修改，但需确保以下三点落地：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
vhost 和 exchange 提前存在：两个集群中，Java 生产者要发往的 exchange（如
order.events）和对应 vhost（如/prod）必须已手动创建且名称严格一致 - 消费者实现幂等：因网络抖动、插件重启或重试机制，同一条消息可能被多次拉取并投递到本地队列；建议用业务主键 + Redis 或数据库去重表控制
-
不依赖确认语义做跨集群强一致：不要在 Java 中等待“对方集群已收到”的反馈；
basicPublish只需确认本地 broker 接收成功即可，后续转发由 Federation 异步完成
服务端必须配好的五项
这些不在 Java 里写，但 Java 应用能否稳定运行取决于它们是否正确：
-
Upstream 定义：每个集群都要配置指向对方的 upstream，URI 含有效账号（如
amqps://feduser:pass@hk-ip:5671），该账号需在对方 vhost 有读权限 -
Policy 绑定：用正则精准匹配 exchange（如
"^order\.events$"），作用域设为exchanges，避免误联邦其他 exchange -
TLS 加密：跨公网必须用
amqps://并校验服务端证书；防火墙开放 5671（AMQPS）和 15672（管理端口） -
Ack-mode 设置：广域网推荐
on-confirm（默认），确保消息至少被下游 broker 接收；禁用no-ack -
心跳与超时：在
rabbitmq.conf中调优federation.heartbeat_interval = 60、federation.max_hops = 2，防长连接中断
验证是否生效的简单方法
不靠 Java 日志，直接看 RabbitMQ 管理界面：
- 访问上海集群管理页 → Federation Status 标签页 → 查看 upstream 连接状态是否为
running - 点开对应 policy → 观察 Federated exchanges 列表是否有目标 exchange，且 Messages in queue 数值随生产波动
- 在香港集群发一条测试消息到
order.events，1–3 秒后检查上海集群对应 exchange 下绑定的队列是否收到
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
