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 僅會在集群中的某一個節點上啟動，并在該節點失效后轉移到另外的節點上去。?
（大概意思描述，下同）在兩個地理位置相距較遠的地方布置了兩個 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 上）?
到此，靜態 shovel 的基本使用已經摸的比較清楚了~~?
最后的總結
- 在使用 shovel 插件時，只需要在 source 節點進行配置，destination 節點不需要配置；同理，只需要在 source 節點上使能 shovel 插件，destination 節點無需使能該插件；
- 在 shovel 正常工作時，對于 source 節點來說，增加了一條用于 consumer 的 TCP 連接；對于 destination 節點來說，增加了一條用于 producer 的 TCP 連接，和普通客戶端的連接行為沒什么不同；
總結
以上是生活随笔為你收集整理的RabbitMQ—队列迁移插件shovel的使用的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 面试题—开发篇
- 下一篇： 五大常用经典算法—回溯算法