shovel 插件适合跨机房场景，是 rabbitmq 官方推荐的 wan 同步方案；它单侧启用、容忍断连、保障 at-least-once 投递，但需正确配置 reconnect-delay、ack-mode、prefetch-count 及四个核心参数，且目标端资源须预先创建。
Shovel 插件是否适合跨机房场景
适合，而且是 RabbitMQ 官方推荐的跨广域网（WAN）消息同步方案。它不像 Federation 那样要求两端都配置、依赖稳定长连接，Shovel 只需在源端单侧启用，能容忍网络抖动和间歇性断连，自动重试并保障 at-least-once 投递。
关键点在于：reconnect-delay 和 ack-mode 的组合决定了容错能力——设为 "on-confirm" 且搭配合理 prefetch-count，才能避免源端消息被提前 ACK 后丢失。
配置 Shovel 时必须设置的 4 个核心参数
漏掉任意一个，Shovel 不会启动或静默失败：
-
src-uri：必须是完整 AMQP URI，含用户、密码、vhost（URL 编码，如%2f表示/），注意目标机房防火墙要放行 5672 端口 -
src-queue或src-exchange：二者选其一；若用src-exchange，还需配src-routing-key和src-exchange-type -
dest-uri：同src-uri格式，但指向远端集群；建议用域名而非 IP，便于后续 DNS 切换 -
dest-exchange或dest-queue：与源端对应；若目标是队列，需确保该队列已存在且 durable=true
为什么消息看起来“同步了”，但消费端收不到
常见原因不是 Shovel 没工作，而是语义不匹配：
- 源端
src-queue中的消息被 Shovel 拉走后，就从该队列移除（即使没投递成功），所以不能把 Shovel 当作“复制”工具来用 - 目标端
dest-exchange类型与绑定关系不匹配：比如源发到topic交换器，但目标dest-exchange是direct，且没配对的 routing key 绑定，消息会直接丢弃 -
delivery-mode未设为 2：源消息本身非持久化，Shovel 转发时若目标 Broker 崩溃，这部分消息即丢失 - 目标 vhost 权限不足：
dest-uri中用户在目标 vhost 上没有configure或write权限，Shovel 日志里会出现NOT_ALLOWED错误但不报红
动态配置 vs 静态配置怎么选
生产环境一律用动态配置（HTTP API 或管理界面），别碰 rabbitmq.conf：
- 静态配置改完要重启整个 RabbitMQ，跨机房场景下等于主动制造服务中断
- 动态配置可热加载，Shovel 进程会自动 reload；API 路径是
/api/parameters/shovel/%2f/your_shovel_name - 管理界面中 “Admin → Shovel Management” 创建后，记得点 “Start shovel now”，否则状态一直是
stopped - 所有配置项名必须小写、带短横线（如
ack-mode），写成ackMode或ack_mode会被忽略
最易被忽略的是：Shovel 不会自动创建缺失的 exchange/queue，它只转发；目标端资源必须提前人工建好，且属性（durable、auto-delete、arguments）要与预期消费逻辑一致。
