RabbitMQ Shovel是单向消息搬运工，非复制工具：消息从源队列移除后即不可逆，目标端未写入不阻断搬运；配置必须包含且仅包含src-uri、src-queue/src-exchange、dest-uri、dest-queue/dest-exchange这4个核心参数，缺一即状态恒为stopped。
Shovel 插件不是“复制工具”，而是单向搬运工：源队列里的消息一旦被它拉走，就从源端永久移除——哪怕目标端还没成功写入。这点不理解，同步后发现源队列空了、目标端却没收到，第一反应往往是“Shovel 没工作”，其实它早把消息搬走了，只是卡在投递环节。
shovel 配置漏掉这 4 个参数，状态永远是 stopped
动态配置时（推荐），set_parameter 命令必须包含且仅包含以下 4 项，少一个或拼错大小写/连字符，Shovel 进程不会报错，但状态始终为 stopped：
-
src-uri：完整 AMQP URI，vhost 必须 URL 编码（如%2f表示/），密码含特殊字符也要编码 -
src-queue或src-exchange：二者二选一；若选src-exchange，必须同时配src-routing-key和src-exchange-type -
dest-uri：格式同src-uri，建议用域名而非 IP，方便后续 DNS 切换 -
dest-queue或dest-exchange：与源端类型对应；若目标是dest-queue，该队列必须已存在且durable=true
消息“消失”最常见的 3 个原因
日志里看不到报错，Shovel 状态是 running，但目标端收不到消息——大概率是语义断层，不是网络或权限问题：
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 源发到
topic交换器，但目标dest-exchange是direct类型，且没配对的 binding，消息直接被丢弃 - 源消息
delivery-mode不是2（即非持久化），Shovel 转发途中目标 Broker 崩溃，这部分消息彻底丢失 -
dest-uri中的用户在目标 vhost 上缺少configure或write权限，Shovel 日志只报NOT_ALLOWED，不标红也不中断
ack-mode + prefetch-count 组合决定是否丢消息
默认 ack-mode 是 on-confirm，这是安全基线；但若搭配过大的 prefetch-count（比如 >100），会导致源端在未确认目标投递成功前就批量 ACK 消息，一旦 Shovel 进程崩溃或网络中断，这批已 ACK 未送达的消息就丢了：
- 生产环境建议设
ack-mode为on-confirm，prefetch-count控制在10~50区间 - 若追求吞吐且能接受少量重复，可改用
ack-mode: on-publish，此时 Shovel 在发出消息后立即 ACK 源端，不等目标端 confirm -
reconnect-delay建议设为10秒以上，避免频繁重连压垮目标 Broker
动态配置后必须手动启动，否则不干活
通过 HTTP API 或管理界面配置完 Shovel，状态默认是 stopped。很多人以为“保存即生效”，结果等半天数据没动：
- API 方式需额外调一次
POST /api/shovels/%2f/{name}/start - 管理界面中，在
Admin → Shovel Management页面，找到刚建的 shovel，点Start shovel now - 静态配置（
rabbitmq.conf）要重启整个节点，跨机房场景下等于主动中断服务，生产环境禁止使用
真正难的不是配通，而是确认每条消息的终点是否和你预期的一致：exchange 类型、binding 关系、routing key、delivery-mode、vhost 权限——这些细节全在目标端生效，源端完全不校验。
