# rabbitmq 之 shovel插件使用介绍

## shovel插件主要功能

A shovel can move messages between brokers (or clusters) in different geographic or administrative domains that

Shovel是分布式消息传递工具包中的一种极简但灵活的工具，可以容纳许多用例。

• may have different loosely related purposes
• may run on different versions of RabbitMQ
• may use different messaging products or protocols
• may have different users and virtual hosts

• 可以应对不同的平台进行消息传递，藕合性低。
• 可以在RabbitMQ的不同版本上运行，兼容性强。
• 可使用不同的消息传递产品或协议。
• 可使用不同的用户和虚拟主机进行传输对接，包容性好。

## shovel 插件工作原理

Shovel是RabbitMQ的一个插件，这个插件的功能就是将源节点的消息发布到目标节点，这个过程中Shovel就是一个客户端，它负责连接源节点，读取某个队列的消息，然后将消息写入到目标节点的exchange/queue中。根据这么一个概念，其实也可以自己开发一个简单的程序，负责从一个节点读取数据然后发送到目标节点。

## shovel 如何使用

In essence, a shovel is a minimalistic message pump. Each shovel:

• 连接集群源节点和目标节点
• 从队列中消费消息
• 重新发布消息到目标节点
• 在两端使用数据安全功能保障数据安全，并处理故障

https://cloud.tencent.com/developer/article/1469332

## shovel插件使用场景

https://www.cnblogs.com/middleware/p/9959221.html

https://zhuanlan.zhihu.com/p/30588183

## shovel 插件确认ack消费慢的问题

http://rabbitmq.1065348.n5.nabble.com/Very-slow-get-dequeue-on-node-B-if-shovel-on-node-A-is-configured-with-ack-mode-on-confirm-td25006.html

Hi!

My setup includes a rabbitmq-c application that publishes messages on node A.
The publishing rate is about 200mps, each message can be up to 10Kb.

Shovel (node A) is configured to move them to node B.
On node B i’m dequeuing the messages with a PHP test script with \$queue->get(AMQP_AUTOACK).
If i keep the publishing rate at 200mps then i can see that the queue on node A is empty and the Q on node B is
filling up. The read-rate of my test script is really low.

If i stop the publishing, 3-5 seconds later, my test script starts reading like crazy until the queue on node B is empty.

Even If I slow down the publishing rate to 5mps , same is happening , messages are piling up on node B until i dial down the pressure.

This problem disappears if I set ack_mode to on_publish or no_ack. In this case the reader script reads with the publishing speed.

Hi. If the shovel is on node A then {ack_mode, on_publish} is not
particularly safe - if the network connection goes down then you will
lose messages that were on the wire.

If the shovel were to be running on node B then {ack_mode, on_publish}
would be safer, as it would tolerate network failures (but not a crash
at node B).

on_confirm would still be better. Of course, since you’re consuming in
autoack mode in the php script you can lose messages there anyway…

You didn’t say which version of RabbitMQ you were running. The script
seems perfectly reasonable (I assume that you are not doing anything
AMQPish in the part elided by “/* do stuff here, count messages, run mps
stats etc… */“).

So it’s a bit of a puzzle. If confirms + persistence are so much slower
than persistence alone, then I wonder if somehow you have a machine that
fsyncs very slowly, since that’s the primary difference in what node B
will be doing.

Cheers, Simon

## shovel插件与federation插件区别

shove是做消息迁移的，federation是分流消费的。