RabbitMQ—队列迁移插件shovel的使用

原文作者：xiaoliuliu2050

原文地址：rabbitmq 学习 之 shovel 插件使用（24）

目录

一、shovel插件基本功能

二、shovel 的使用场景

三、针对 static 和 dynamic 两种配置的 shovel 的实验

---

一、shovel插件基本功能

Shovel 插件 允许你 同时配置多个 shovel 以便在 broker 启动的时候可以随之自动启动。 shovel 的高层次的目标是 保证可靠连续地将 message 从某个 broker 上的 queue （作为源端）中取出，再将其 publish 到另外一个 broker 中的相应 exchange 上（作为目的端）。 作为源的 queue 和作为目的的 exchange 可以同时位于一个 broker 上，也可以位于不同 broker 上。 shovel 的行为就像编写良好的客户端应用程序，负责连接源和目的，负责 message 的读出和写入，以及负责连接失败问题的处理（连接失败怎么处理的）。

1、shovel 的主要优势在于： 

• 松耦合：    shovel 可以将位于不同管理域中的 broker（或者 cluster）上的 message 进行移动。 这些 broker 或 cluster 可以包含不同的 user 和 vhost ；这些 broker 或 cluster 可以使用不同的 RabbitMQ 和 Erlang 版本；
• WAN 友好：Shovel 插件基于 AMQP 协议在 broker 间进行通信， 并被设计成可以容忍时断时续的连通性，且保证 message 不会丢失。
• 非侵入特性：为了使用 shovel 功能，你不必重新配置任何源或者目的资源。你甚至不需要重新启动这些资源所在的 broker ：因为 shovel 可以运行于完全不相关的 broker 上面。 
• 高度定制性： 当 shovel 成功连接后（连接上源或者目的），可以对其进行相应配置以执行任意数量的相关方法。例如，源 queue 在最初不需要存在，可以在连接建立后声明。 

2、shovel 做了些什么？

Shovel 插件会定义（和运行） Erlang 客户端应用程序，只要在相应的配置中定义了 shovel 相关信息。 在本质上，shovel 可以类比为一个简单的水泵。每一个 shovel 都会：

• connect 到源 broker 和目的 broker，
• 从 queue 中 consume 相应的 message ，
• 每一条 message 将被 re-publishe 到目的 broker 中（默认会使用原消息中的 exchange 名字和 routing_key 的值）。

通过对 shovel 进行配置，可以对上述操作步骤进行定制。

1）连接：在成功连接源或目的 broker 之后，就可以执行一系列相应的 AMQP 配置声明了。Queue 、exchange 以及 binding 均可以进行声明。 shovel 插件会保证在目标 broker 失效后，尝试重连到其他 broker 上；还可以为源端 broker 和目的端 broker 同时指定多个 shovel broker，以便从中（随机）选择要连接的 broker 。 可以设置 reconnection delay 以避免由于重连行为导致的网络泛洪，或者可以在重连失败后直接停止重连。  所有配置声明（针对相应的源和目的）会在重连成功后被重新发送。

2）消费：在 Shovel 模型中的，consumer 收到 message 并自动进行 acknowledge 动作的时机有以下几种： 

• 在收到 message 时；
• 在 (re-)publication 后；
• 在 publication 被（目的端）confirmation 之后。

3）重新推送：可以显式地对 publish 方法和 message 属性进行修改。 具体细节在下面的 [ configuration] 段中给出。

上述文字引用自：https://my.oschina.net/moooofly/blog/96716?spm=a2c4e.10696291.0.0.446b19a4xXNPHB

shovel 插件的使用存在 static 和 dynamic 两种形式，其主要差异如下 

Static Shovels	Dynamic Shovels
基于 broker 的配置文件进行定义	基于 broker 的 parameter 参数进行定义
Require a restart of the hosting broker to change.需要重启宿主 broker 以便配置生效	可以在任意时间进行创建和删除，直接生效
更加通用：任何 queue 、exchange 或 binding 关系均可在启动	更具有目标性：被 shovel 所使用的 queue 、exchange 和 binding 关系能够自动被声明（创建）

二、shovel 的使用场景

在了解了 shovel 的基本功能之后，下一个需要考虑的问题就是 shovel 的使用场景。相关的几个问题总结如下： 

1.为什么需要使用 shovel 插件？ 
答：当业务需要可靠且连续地将消息从一个 broker 的 queue 里搬运（转发）到另一个 broker 的 exchange 时（最终达到某个 queue 里 ）使用；作为 source 的 queue 和作为 destination 的 exchange 可以位于同一个 broker 上（通常要求处于不同的 vhost 下），也可以位于不同的 broker 上。 

2.使用 shovel 插件的好处？ 
答：shovel 基于 RabbitMQ 的 Erlang 客户端实现，且作为 built-in 插件被使用，故可以随 broker 的启动而自动启动；shovel 具有松耦合特性：通过该插件可以在分属不同管理域下的 broker 或 cluster 之间进行消息的搬运；shovel 具有 WAN 友好特性：基于 AMQP 0-9-1 协议实现，并设计成能够保证在不稳定网络场景下不丢失消息；shovel 具有高度可定制性：允许在 shovel 建立连接后，立即执行指定的 AMQP 方法进行定制化操作（例如声明 queue 的动作）； 

3.shovel 与 cluster 的结合问题 
答：如果每个 shovel 均指定了属于源集群或目的集群中的多个 source URI 或 destination URI ，那么当 shovel 遇到节点失效时，就可以进行失效转移操作；对于 dynamic shovel 来说，其定义信息会出现在使能了 shovel 插件的、目标集群中的所有节点上（即所有节点都能获取到 shovel 的定义信息），而每一个 shovel 仅会在集群中的某一个节点上启动（任意一个），并在该节点失效后，转移到另外的节点上去；对于 static shovel 来说，需要在使能了 shovel 插件的、目标集群中的所有节点的配置文件中添加相应的定义信息，同样的，每一个 shovel 仅会在集群中的某一个节点上启动，并在该节点失效后转移到另外的节点上去。 

 shovel 使用场景示例图（取自 《RabbitMQ in Action》） 

（大概意思描述，下同）在两个地理位置相距较远的地方布置了两个 RabbitMQ 节点，其中 Goleta 节点用于负责大部分订单的处理，而 Carpinteria 节点用于解决 Goleta 节点达到一个负荷后的、额外订单的处理。该场景属于基于 WAN 的互联，所以无法使用 RabbitMQ 的集群功能； 

 在未使用 shovel 功能前，只能通过同时将订单发往两地的方式进行处理，在这种场景下，最大延迟取决于较远的一端；并且可能会对业务提出变更要求； 

在使用了 shovel 插件后，模型变成了近端同步确认，远端异步确认的方式，大大提高了订单确认速度，并且还能保证可靠性； 
 

最终的内部结构图如上图所示。 一句话总结：shovel 适用于需要对资源请求（订单）快速作出相应的场景，能够有效利用跨 WAN 的其他 broker 或 cluster 一起进行请求的处理（订单处理）。 

三、针对 static 和 dynamic 两种配置的 shovel 的实验

shovel 插件的使用存在 static 和 dynamic 两种形式，其主要差异如下 

Static Shovels	Dynamic Shovels
基于 broker 的配置文件进行定义	基于 broker 的 parameter 参数进行定义
Require a restart of the hosting broker to change.需要重启宿主 broker 以便配置生效	可以在任意时间进行创建和删除，直接生效
更加通用：任何 queue 、exchange 或 binding 关系均可在启动	更具有目标性：被 shovel 所使用的 queue 、exchange 和 binding 关系能够自动被声明（创建）

【static shovel】
首先按照《RabbitMQ in Action》中的示例进行配置（调整了监听端口，以及 user 和 password ） 
 
此时在 Web UI 上会看到如下错误信息

或者 
 
这两个状态在不停的切换，表明 RabbitMQ 内部在不断重新尝试建立 shovel 连接； 

通过日志可以看出，问题出现在 shovel 插件建立 AMQP 连接过程的握手节点，而错误原因为“ access to vhost '',  refused by user 'dev' ”。说明 vhost 的指定有错误。通过抓包内容同样可以确认这一点。

重新调整配置文件如下

 
上图中的红框位置为增加的内容，其中 %2F 代表的就是 vhost "/" ，此处需要进行转义使用。 
变更配置后，重启相应的 broker ，此时可以看到
（source broker） 

（destination broker） 

可以看到 shovel 已经正常运行了，查看此时的网络连接情况如下（注：source broker 在 81.111 上，destination broker 在 80.111 上） 

[root@Betty rabbitmq]# netstat -natp|grep 6672
tcp        0      0 172.16.81.111:36489         172.16.81.111:6672          ESTABLISHED 12739/beam.smp  -- shovel 作为 consumer 从 source broker 上进行消费的 TCP 连接
tcp        0      0 172.16.81.111:35203         172.16.80.111:6672          ESTABLISHED 12739/beam.smp  -- shovel 作为 producer 向 destination broker 发送消息的 TCP 连接
tcp        0      0 :::6672                     :::*                        LISTEN      12739/beam.smp
tcp        0      0 ::ffff:172.16.81.111:6672   ::ffff:172.16.81.111:36489  ESTABLISHED 12739/beam.smp      
[root@Betty rabbitmq]#

到此，静态 shovel 的基本使用已经摸的比较清楚了~~ 

最后的总结

• 在使用 shovel 插件时，只需要在 source 节点进行配置，destination 节点不需要配置；同理，只需要在 source 节点上使能 shovel 插件，destination 节点无需使能该插件；
• 在 shovel 正常工作时，对于 source 节点来说，增加了一条用于 consumer 的 TCP 连接；对于 destination 节点来说，增加了一条用于 producer 的 TCP 连接，和普通客户端的连接行为没什么不同；