RabbitMQ Shovel 跨集群消息迁移与运维实战

1. Shovel 到底解决什么问题：从"我不想写搬运代码"说起

手上有两个 RabbitMQ 集群，一边是老机房要下线，队列里还压着上百万条没消费完的消息；另一边是新集群，业务已经切过去了。这时候最朴素的做法是写一段 Java 或者 Python：从老集群 basic.consume，再往新集群 basic.publish，挂在中间当个搬运工。我试过，能跑，但麻烦的地方在于——网络一抖你得自己重连，目标端 broker 重启你得自己退避重试，业务侧还要多维护一个进程、一套日志、一套监控。更别提切流量的时候凌晨三点盯着屏幕看谁的进度快。

RabbitMQ Shovel 就是把这个搬运工内建进了 broker 本身。它在概念上非常简单：一个 Shovel 就是把消息从源端（source）搬到目的端（destination）的一个后台进程，源和目的既可以是同一台 broker 上的不同 vhost，也可以是两台完全独立的 broker，中间隔着公网或者专线都行。你只需要给它一段连接串和队列名，剩下的重连、重试、确认、限流，它自己管。

这个功能属于 RabbitMQ 的"扩展"能力，跟 Federation、Consistent Hash Exchange 是同一类东西——平时不用，一旦遇上跨集群、跨 vhost、跨机房的搬运需求，它就是那个能让你少加一个月班的东西。适合谁看？我建议这几类人都把它过一遍：负责集群迁移和机房搬迁的运维；手里有多个环境（dev/test/prod）需要打通消息链路的架构同学；还有面试里被问到"如何实现跨集群消息同步"时想答得比别人具体的开发者。

先给一个最直观的认知：Shovel 是单向的，它不会给你做双向同步；它是消费再发布，所以消息会从源队列里真的消失，而不是复制一份；它只搬消息本身，队列属性、绑定关系、策略（policy）、TTL 配置这些一概不管。这三点先记住，后面所有的坑基本都能从这里推导出来。

1.1 一个典型的跨集群搬运需求长什么样

我把遇到过的场景归了三类，你可以对照一下自己属于哪种。

第一类是集群迁移。老集群的 vhost/prod下有几十个业务队列，新的集群已经建好，但不可能停机等消息消费干净。做法就是在两边都建好同名队列和绑定，然后用 Shovel 把老队列里的存量消息拉到新队列，存量拉完之后让生产者、消费者统一切到新集群，最后拆掉 Shovel。

第二类是跨机房单向汇聚。边缘节点部署了轻量 broker，本地业务写本地队列，满足低延迟；同时用 Shovel 把关键事实数据（比如订单、支付流水）单向汇聚到中心机房做大屏和对账。这类场景对吞吐不敏感，对稳定性和断线重连很敏感——正好是 Shovel 的强项。

第三类是vhost 之间的隔离打通。有些团队为了权限隔离，把不同业务放不同 vhost，结果某天发现两个业务之间需要传消息。与其开放跨 vhost 的用户权限，不如用一条 Shovel 把 A vhost 的队列搬到 B vhost 的交换机，权限边界一点没破。

还有一类比较"取巧"的用法：源是队列，目的是交换机，routing key 可以重写。这等价于给一批已经进队的消息做一次重新路由，比写脚本捞出来再发回去干净得多。

1.2 Shovel 与 Federation 的适用边界

这两个经常被拿来比较，因为功能上有重叠。我的经验是：能用 Shovel 简单解决的，别上 Federation。

关键差别在于触发方式。Shovel 是"我盯着这个源队列，只要里面有东西就搬走"，源队列因此会被搬空；Federation 是"我挂在目的端的 exchange 上，上游有消息过来时给我一份"，它更接近于在上游 broker 上挂了一个隐形的消费者，源头的数据控制权还在源头手里。

所以如果你的需求是"把 A 里的存量搬到 B 然后 A 就废弃了"，Shovel 是正解；如果是"两个机房长期互为备份，谁也不能被搬空"，那得看 Federation 或者业务侧双写。

2. 动手之前：Shovel 的运行形态与插件准备

很多人第一次配 Shovel 失败，不是参数写错了，而是压根没搞清它的运行形态：它不是一个独立的服务，而是 broker 内部的一批 Erlang 进程；它的定义存在哪、在哪个节点跑，直接决定了你怎么排障。

Shovel 的实现依赖rabbitmq_shovel这个插件，管理界面的部分依赖rabbitmq_shovel_management。启用一条命令就够：

rabbitmq-plugins enable rabbitmq_shovel rabbitmq_shovel_management

不需要重启 broker，插件会动态加载。装完之后管理界面左侧的 Admin 菜单下会多出 Shovel Status 和 Shovel Management 两项。如果没有这两项，八成是插件没启成功，去日志里搜rabbitmq_shovel找原因。

2.1 插件装在哪个节点：端侧选择的经验

这是很多人的第一个困惑——Shovel 要连两个 broker，插件到底装哪边？

答案是：装在"定义 Shovel 的那一端"。Shovel 由某个节点上的 broker 进程发起，它作为客户端分别去连源端和目的端。所以理论上你可以定义在源端（推送式），也可以定义在目的端（拉取式），还可以定义在第三台完全无关的 broker 上。

实际项目里我这样选：

• 源集群即将下线：定义在目的端，用拉取式。因为老集群你不想再动任何配置了，能少改一处是一处。
• 目的端是新建的、配置干净：同样定义在目的端，方便集中管理所有搬运任务。
• 只想快速验证一条链路：定义在任意一台已经装了插件的 broker 上，URI 里写清楚两端地址就行。

还有一个容易忽略的点：动态 Shovel 的参数是 vhost 级、集群内共享的。也就是说你在集群三个节点中的任意一个执行set_parameter，参数会同步到所有节点，而实际运行的 Shovel 只会在其中一个节点上被拉起。这个节点挂了，集群会在别的节点重新拉起它。对迁移场景来说，这意味着你不用操心"Shovel 跑在哪个节点上会不会因为节点维护而中断"——它会自己漂移，但漂移期间会有短暂停顿，所以别在切换窗口的最后一分钟做节点滚动重启。

Shovel 内部大致是两组进程：一组负责维持到源端和目的端的 AMQP 连接，另一组负责实际的"取一条、发一条、确认"循环。前者挂掉会触发重连，后者挂掉会触发整个 Shovel 重启。这也是为什么你在状态里会看到它有明确的状态机，而不是一个简单的"运行中/已停止"。

2.2 三种定义方式的取舍

Shovel 有三种定义姿势，选错会很痛苦。

静态配置（rabbitmq.conf）适合长期存在的搬运任务：

shovel.shovels.order_shovel.src-uri = amqp://shovel_user:***@192.168.10.10:5672/%2fprod shovel.shovels.order_shovel.src-queue = order.queue shovel.shovels.order_shovel.dest-uri = amqp://shovel_user:***@192.168.10.20:5672/%2fprod shovel.shovels.order_shovel.dest-queue = order.queue shovel.shovels.order_shovel.prefetch-count = 500 shovel.shovels.order_shovel.ack-mode = on-confirm shovel.shovels.order_shovel.reconnect-delay = 5

注意的是名字里不要带点和斜杠，order_shovel这种下划线命名最稳。静态配置的缺点是要改配置就得重启节点，做一次性迁移时很不灵活。

动态参数（rabbitmqctl / HTTP API）适合迁移这种"临时但要求精细控制"的场景，随时可增可删：

rabbitmqctl set_parameter -p /prod shovel order_shovel \ '{"src-uri":"amqp://shovel_user:***@192.168.10.10:5672/%2fprod", "src-queue":"order.queue", "dest-uri":"amqp://shovel_user:***@192.168.10.20:5672/%2fprod", "dest-queue":"order.queue", "prefetch-count":500, "ack-mode":"on-confirm", "reconnect-delay":5}'

管理界面适合单人操作、任务数量少的情况，Admin → Shovel Management → Add a new shovel，填表单就行。缺点是没有版本记录，配置改了什么全靠人记，团队协作时不如前两种方式可审计。

我的建议是：迁移用动态参数，落库到你的运维脚本或者配置仓库里；长期链路用静态配置，跟rabbitmq.conf一起纳入版本管理；界面只用来点开看一眼状态。

3. 参数逐项拆解：哪些默认值是坑，哪些必须显式配

参数表看起来有二十来个，实际真正需要你操心的也就六七个。但有几个默认值如果不改，迁移当天会出问题。

3.1 URI 与 vhost 编码：最常见的失败点

Shovel 的src-uri/dest-uri用的是标准 AMQP URI 格式：

amqp://用户名:密码@主机:端口/vhost

这里有个必踩的坑：vhost 名称需要 URL 编码。默认 vhost 是/，写的时候要写成%2f；如果你的 vhost 叫/prod，那就要写成%2fprod；如果叫prod/msg，斜杠同样要转义成%2f，即prod%2fmsg。

# 默认 vhost "src-uri":"amqp://user:pass@10.0.0.1:5672/%2f" # 名为 /prod 的 vhost "src-uri":"amqp://user:pass@10.0.0.1:5672/%2fprod" # 名为 prod/msg 的 vhost "src-uri":"amqp://user:pass@10.0.0.1:5672/prod%2fmsg"

第二个坑是密码里的特殊字符。密码里有@、:、/、#、?这些字符时，不编码会把 URI 解析得乱七八糟。我一般直接避免在 Shovel 专用账号的密码里用特殊字符，实在要用就做百分号编码。

第三个坑是别用 guest。guest 默认只允许本机登录，跨机器用 guest 会直接连接失败，日志里是一句很含糊的access_refused。专门建一个shovel_user账号，密码用密码管理器生成，然后按需授权。

第四个坑跟网络有关：URI 里的主机名一定要写能被解析且能连通的地址。我遇到过一次，主机名在 /etc/hosts 里只配了老集群，Shovel 定义在新集群上，解析不到，状态一直卡在 starting。用 IP 或者确保 DNS 两边一致，能省很多时间。

3.2 ack-mode 三档语义与数据安全权衡

ack-mode是 Shovel 里最重要的一个参数，它决定了"什么时候认为这条消息搬成功了"，直接对应数据安全等级。

on-confirm比on-publish慢多少？实测差异取决于目的端的确认延迟，在局域网内通常是 10%~30% 的吞吐差距。做迁移的时候这个代价完全值得，因为迁移最怕的不是慢，而是"搬完了发现少了一批但你不知道少了哪些"。

这里要强调一个很多人误解的点：on-confirm保证的是"至少一次"，不是"恰好一次"。目的端确认了但确认包在回程丢了，Shovel 会重发，源端就会看到重复。所以消费端必须做幂等——用业务唯一键去重，或者用数据库的唯一索引兜底。这条不是 Shovel 的锅，任何"至少一次"的传输机制都一样。

no-ack还有一个隐性代价：它会让源队列的消息瞬间被大量取走并删除，如果目的端写不进去，这批消息就凭空消失了，而且没有任何痕迹。所以这个模式我只在一种情况下用：源数据本身是可再生的，比如从数据库同步出来的、随时能重跑一遍的。

3.3 队列型与交换机型目的端的差别

目的端有两种写法，行为完全不同。

写dest-queue：消息按顺序落到指定队列，最直接，迁移场景用这个。源队列和目标队列同名是最省事的方式，虽然 Shovel 并不要求同名。

写dest-exchange：消息会被发布到指定的交换机，由交换机和绑定关系决定去哪。这时候 routing key 怎么办？默认是保持源消息的 routing key 不变。如果目标端没有匹配的绑定，消息就直接被丢弃，而且因为没有开 mandatory，你不会收到任何错误提示——消息就这么静悄悄地没了。

所以用dest-exchange的时候，我强烈建议同时指定dest-exchange-key重写 routing key：

{ "src-uri": "amqp://user:***@10.0.0.1:5672/%2fprod", "src-queue": "legacy.order.queue", "dest-uri": "amqp://user:***@10.0.0.2:5672/%2fprod", "dest-exchange": "order.topic", "dest-exchange-key": "order.created.v2" }

这样不管你源端的 routing key 有多乱，到了目的端都会被重新打标，命中你新定的绑定规则。顺带说一句，用dest-exchange做迁移时，如果目的端有多个队列绑定了这个 routing key，消息会被复制成多份——这在某些场景是特性（一份数据多处消费），但在迁移场景里很可能是个事故。定义之前一定把绑定关系画一遍。

至于声明行为：在没开启src-predeclared/dest-predeclared的情况下，Shovel 会尝试声明源队列和目的端对象（指定dest-queue就声明队列，指定dest-exchange就声明交换机）。这意味着如果名字写错了，RabbitMQ 会帮你创建一个空队列或空交换机，然后 Shovel 看起来"正常运行"，实际上消息搬到了一个没人消费的孤儿队列里。这个错误非常隐蔽，我的做法是迁移前先把两端队列都手工建好，然后在 Shovel 参数里加上src-predeclared: true和dest-predeclared: true，让它只搬不建。名字写错就直接报 NOT_FOUND，比默默创建好一百倍。

3.4 生命周期参数：prefetch-count、reconnect-delay、delete-after

prefetch-count决定 Shovel 一次从源队列最多取多少条未确认消息。默认值不小，我一般会往下调，尤其是做迁移的时候。原因很简单：这些消息在确认之前是躺在 Shovel 进程里的，量大意味着内存占用大。如果目的端变慢，未确认消息会迅速堆积，源端 broker 的内存曲线就会往上飙。局域网迁移我会设 200~500，跨公网或者目的端不太稳的时候设 50~100，先求稳再求快。

reconnect-delay是断线后重连的等待秒数，默认值偏小。跨机房链路上，如果对端正在重启，你每隔一两秒去连一次，日志会被连接失败刷屏，也没意义。设成 5 到 15 秒更合理。这里有个细节：Shovel 的重连不会记住上次搬到哪里，它是从源队列当前的队头继续搬。因为所有已确认的消息已经被源端删掉了，所以逻辑上不会重复搬已经搬过的部分——这也是为什么on-confirm模式虽然慢，但迁移可中断、可续传，非常舒服。

delete-after是迁移场景的收尾利器。默认是never，也就是 Shovel 一直活着。设成queue-length之后，当源队列长度降到 0（且消息都被确认）时，Shovel 会自动删除自己。做一次性迁移时我会带上它，好处是搬运结束后不会留一个空转的进程，也不会有人忘记清理。需要注意的是不同版本里这个字段可能叫src-delete-after，配置前拿当前版本的文档或者rabbitmqctl的帮助确认一下字段名，别凭记忆写。

4. 实操：把老集群的积压队列搬到新集群

理论讲完，来一个我实际做过一遍的完整链路。场景：老集群192.168.10.10的 vhost/prod里有个order.queue，积压约 200 万条；新集群192.168.10.20要接管，消费者和生产者会统一切过去。目标是不停机把存量搬完。

4.1 权限与 vhost 准备

先在新老两端建账号。Shovel 对权限的要求分两端看：

• 源端：需要能读源队列（consume），如果让 Shovel 自动声明队列还需要configure权限。
• 目的端：需要能写（publish）到目标队列或交换机，同样，自动声明也需要 configure。

迁移期间我授权比较宽松，直接给.*，搬完再收紧：

# 在两端分别建账号（老集群和新集群都执行） rabbitmqctl add_user shovel_user 'Replace_With_A_Strong_Password' rabbitmqctl set_permissions -p /prod shovel_user ".*" ".*" ".*"

然后是最容易被跳过的一步：在新集群上把队列和绑定建好，属性要对齐。用什么对齐？从老集群导出定义：

# 导出全部定义 curl -s -u monitor:*** http://192.168.10.10:15672/api/definitions -o defs.json # 只要队列和绑定，可以用 jq 过滤后再导入 curl -s -u admin:*** -X POST -H "content-type:application/json" \ --data-binary @defs.json http://192.168.10.20:15672/api/definitions

注意导入定义会把 users、vhosts、policies 一起带过去，生产环境直接全量导入容易和别人已有的配置打架。我一般用 jq 只抽queues、exchanges、bindings三段，手工合并。这一步别偷懒——Shovel 只搬消息，队列是不是持久化、有没有配 DLX、TTL 是多少，全靠你这一步对齐。

提示：如果目标队列配了消息 TTL 或者队列级 TTL，搬过去的消息在目标端会按到达时间重新计时；而每条消息自带的过期时间戳是会保留的，快过期的消息可能一进新队列就被丢掉。迁移前确认一下两边的 TTL 配置是不是一致，或者干脆临时把 TTL 策略摘掉。

4.2 定义拉取式 Shovel 并观察进度

因为老集群要下线、不想再动它，我把 Shovel 定义在新集群上，用拉取式。注意-p /prod指定的是Shovel 参数所属的 vhost，不是源队列的 vhost，这两个可以不一样。

rabbitmqctl set_parameter -p /prod shovel migrate_order_queue \ '{"src-uri":"amqp://shovel_user:***@192.168.10.10:5672/%2fprod", "src-queue":"order.queue", "dest-uri":"amqp://shovel_user:***@192.168.10.20:5672/%2fprod", "dest-queue":"order.queue", "src-predeclared":true, "dest-predeclared":true, "prefetch-count":300, "ack-mode":"on-confirm", "reconnect-delay":5, "delete-after":"queue-length"}'

定义完立刻确认状态：

rabbitmqctl shovel_status

输出里能看到 Shovel 的名字和状态。正常应该是走到running；如果是starting卡着不动，去看日志；如果是terminated就说明它起不来，日志里一定有原因。

看进度的方式很"土"但非常有效——盯两端的队列长度：

# 源端（老集群） rabbitmqctl list_queues -p /prod name messages messages_ready messages_unacknowledged --silent # 目的端（新集群） rabbitmqctl list_queues -p /prod name messages messages_ready --silent

理想曲线是源端messages_ready稳步下降、目的端稳步上升，源端的messages_unacknowledged稳定在prefetch-count附近。如果源端的messages_unacknowledged一直在涨，说明目的端写得比取得慢，这时候要么调小prefetch-count，要么去查目的端是不是磁盘慢或者有流控。

也可以用 HTTP API 更精细地看：

curl -s -u monitor:*** \ http://192.168.10.20:15672/api/shovels/%2fprod/migrate_order_queue | jq

4.3 切换窗口的控制与回滚预案

搬运是后台的事，真正需要设计的是切换那一刻。我用的流程是这样的：

1. T0：确认源端积压已经降到接近 0，或者降到可接受的范围。如果是几十万级别的存量，几百 MB/s 的局域网带宽通常几十分钟就能搬完，但别指望线性——源端队列的读取速率和磁盘、目的端的写入速率都有上限。
2. T1：通知生产者停止写入老集群（可以通过修改配置、重启生产端、或者在上游做开关）。等 1~2 分钟让在途请求落定。
3. T2：观察 Shovel 把源队列"搬空"。因为开了delete-after: queue-length，队列清零后 Shovel 会自己消失。这一步能看到messages_ready归零并且不再反弹，就说明存量真的搬完了。
4. T3：消费者切到新集群，验证消费正常，抽查几条消息的内容和顺序。
5. T4：生产者切到新集群，观察新集群的入队速率和错误日志。
6. T5：确认无误后，把 Shovel 参数删掉（如果还没自动删）、回收shovel_user的权限、清理老集群。

回滚预案也要提前想好。最简单的一招是让老集群的 Shovel 暂时不要自动删除：把delete-after设成never，等观察一整天确认新集群稳定了，再手工执行清理。

rabbitmqctl clear_parameter -p /prod shovel migrate_order_queue

另一个更稳的做法是不要清空老集群。让消费者的切换是"先双读、再单读"，或者干脆保留老队列几天，用 TTL 自然过期。Shovel 搬完就删参数，但队列还在，万一新集群出问题，把消费者切回来还能继续跑。

5. 排错现场：Shovel 起不来、搬不动、搬丢了怎么查

我把这些年遇到的 Shovel 问题整理成了一条排查链路。核心原则是：先看状态，再看日志，最后才怀疑参数。

5.1 状态机与日志入口

rabbitmqctl shovel_status输出的状态基本就四类：

• starting：正在建立连接、声明对象。停留超过十几秒就是异常。
• running：正常工作中。
• terminating：正在收尾，通常是收到删除指令或者满足delete-after条件。
• terminated：结束或者启动失败。

日志入口有两个地方：节点的 broker 日志（rabbitmqctl log_tail或者日志文件），以及管理界面的 Shovel Status 页面，后者会把最近一次错误直接写在状态旁边。我的习惯是先看界面，因为界面上那一行错误信息往往就是最终答案。

5.2 五个高频故障的定位链路

逐条说下我怎么定位。

连接类问题占了我遇到的一半以上。URI 写错、vhost 没编码、端口不对、密码里有特殊字符，症状都是"状态起来了但一直连不上"。我现在的习惯是先用一个普通客户端验证 URI 是否可用——拿 Python 的 pika 或者 management 界面上的 HTTP API 去连一下同样的地址和账号。如果连客户端都连不上，那就别怀疑 Shovel 了，先把连通性和权限搞通。

权限问题有个很坑的细节：Shovel 需要的权限是按"操作"算的。读源队列要 read，写目的端要 write，自动声明要 configure。很多人的账号是从别的用途借过来的，只有 read 没有 configure，结果 Shovel 想声明源队列时被拒，日志里是一句很抽象的access_refused。排查的时候用rabbitmqctl list_permissions把三列都看一遍。

路由丢失是最阴的一个，因为 Shovel 状态永远是running，看起来一切正常。判断方法很简单：如果有 Shovel 在跑，但目的端消息数纹丝不动，99% 是路由问题。用dest-queue就没这个烦恼——所以做迁移时我坚决用dest-queue，把重新路由的需求留到迁移之后单独处理。

5.3 循环搬运与重复投递的防范

Shovel 自身有一个"防呆"检查：如果源和目的是完全同一个队列，它会拒绝启动，避免自己吃自己的消息。但这个检查覆盖不了更复杂的循环。

想象一下：A 集群的q1用 Shovel 搬到 B 集群的q2，B 集群又有一条 Shovel 把q2搬回 A 集群的q1——这时候消息就进入了永动机状态，两边的队列长度都降不下去，CPU 和网络被打满，而你从单个 Shovel 的状态看两个都是running。

防范手段不是靠 Shovel，是靠拓扑设计：每个 Shovel 的搬运关系画成图，确保是有向无环的。尤其是多机房场景，画一遍图就会发现有些"看起来对称"的配置其实是环。

重复投递的处理则落在消费端。我在迁移项目里做过两件事：

第一，给消费端加上基于业务 ID 的去重日志表，或者用 Redis 的 SETNX 做一层幂等过滤。这不是为 Shovel 加的，是任何"至少一次"通道都应该有的兜底。

第二，迁移期间在消息头里加一个标记，方便消费端识别"这条是从老集群搬过来的"，出问题时能定向排查：

"publish-properties": { "content_type": "application/json", "headers": {"x-migrated-from": "legacy-cluster"} }

publish-properties和publish-fields这两个参数的作用就是覆盖发布时的属性和字段。要提醒的是：它是覆盖语义，不是合并，你设置headers可能会把原有 header 顶掉。这个行为在不同版本上细节有差异，正式跑之前一定在测试环境验证一遍，别直接上生产。

6. 性能与运维收尾：吞吐调优和长期维护

Shovel 跑通不难，跑快、跑稳、跑得可观测，才是真正花时间的地方。

6.1 吞吐不达标时该调什么

先把瓶颈定位清楚，我一般的判断顺序是：源端读取、网络传输、目的端写入，哪个环节先饱和。

看源端：messages_unacknowledged长期贴着prefetch-count，说明 Shovel 一直在等目的端确认，瓶颈在下游。反过来，如果它长期是 0 或者很低的个位数，说明源端供不上货，去看看源队列是不是有其他消费者在抢、源端磁盘是不是慢。

看目端：目的队列的messages_ready持续上涨，同时 Shovel 卡在确认阶段，那就是目的端 broker 处理不过来。可能是目的队列的持久化开销大（比如队列是持久化且消息要求落盘），也可能是目的端本身内存告警触发了流控。这时候调大prefetch-count没用，反而会让内存更紧张。

调参的优先级我排成这样：

• prefetch-count：从默认值往下调，找到"内存不飙、吞吐不塌"的平衡点。我项目里最终的稳定值是 200~500，视目的端延迟而定。
• ack-mode：只有在数据可以容忍丢失时，才考虑从on-confirm换到on-publish换取吞吐。迁移场景我不换。
• 网络层：跨机房迁移考虑上amqps，但要清楚 TLS 会带来额外开销，而且需要在 Shovel 所在节点配置对应的 TLS 选项，字段随版本有变化，要以当前版本官方文档为准。
• 并行度：一个 Shovel 只对应一个队列，想提高总体吞吐只能开多个 Shovel 搬不同队列，而不是给同一个队列开多个。这是硬约束，别指望靠调参突破。

还有一个容易被忽视的点：如果目的队列有 TTL 或者长度限制，Shovel 的高速写入可能触发消息过期或者队列溢出行为。迁移期间建议临时放宽这些限制。

6.2 把 Shovel 纳入监控与批量管理

一次性迁移可以人肉盯，长期存在的 Shovel 必须纳入监控。要采集的指标不多，但都得有：

• Shovel 状态（必须是running），状态一旦变成terminated就该告警。
• 源队列的messages、messages_ready、messages_unacknowledged三个值。长期不下降就是链路上有问题。
• 两端 broker 的连接数（Shovel 会占两条连接）。

拿状态最简单的方式是 HTTP API：

# 列出某个 vhost 下所有 shovel curl -s -u monitor:*** http://host:15672/api/shovels/%2fprod | jq '.[].name' # 单个 shovel 的详情 curl -s -u monitor:*** http://host:15672/api/shovels/%2fprod/migrate_order_queue | jq '{name, state, src_uri, dest_uri}'

做个定时任务，把状态和队列长度打到监控系统里，值班同学一眼就能看出异常。

队列多的时候，一条条敲set_parameter很痛苦。我的做法是准备一份队列清单，用脚本生成参数批量提交：

#!/bin/bash # queues.txt 每行一个队列名 SRC="amqp://shovel_user:***@192.168.10.10:5672/%2fprod" DST="amqp://shovel_user:***@192.168.10.20:5672/%2fprod" while read -r q; do [ -z "$q" ] && continue rabbitmqctl set_parameter -p /prod shovel "migrate_${q//./_}" "$(cat <<JSON {"src-uri":"$SRC","src-queue":"$q", "dest-uri":"$DST","dest-queue":"$q", "src-predeclared":true,"dest-predeclared":true, "prefetch-count":300,"ack-mode":"on-confirm","reconnect-delay":5} JSON )" echo "created shovel for $q" done < queues.txt

注意 Shovel 名字里的.我替换成了_，避免和静态配置的层级分隔符冲突。批量创建完之后一定要逐个确认状态，别创建完就当成了——名字冲突或者 URI 有问题的时候，它会静默地创建失败。

最后一个运维细节：动态 Shovel 没有"暂停"这个操作。想让它停下来，只能删除参数；静态配置的则要改配置文件重启节点。所以做迁移时别想着"先停了等会儿再开"，要么让它跑完，要么删掉重新建。知道这一点，切换窗口的时间安排会清晰很多。

我在实际做集群迁移的时候，最大的体会是：Shovel 本身很可靠，不可靠的是"我以为了"。我以为目的队列已经建好了，我以为账号权限给全了，我以为 routing key 是一致的。把这三件事在动手前逐个验证一遍，整个迁移过程基本就是一条平缓下降的队列长度曲线。真正需要花心思的地方从来不是配置参数，而是切换那一刻的生产者停写、消费者切换、以及回滚预案能不能在五分钟内生效。

如果后面你要做的不是迁移而是长期的多机房同步，Shovel 也能用，但那时候更该先想清楚"谁拥有这条消息的真相"这个问题——单向汇聚用 Shovel 很舒服，双向对等就别硬套了。