RabbitMQ—队列迁移插件shovel的使用
原文作者：xiaoliuliu2050
原文地址：rabbitmq 學(xué)習(xí) 之 shovel 插件使用（24）
目錄
一、shovel插件基本功能
二、shovel 的使用場景
三、針對 static 和 dynamic 兩種配置的 shovel 的實(shí)驗(yàn)
一、shovel插件基本功能
Shovel 插件?允許你?同時配置多個?shovel 以便在 broker 啟動的時候可以隨之自動啟動。?shovel 的高層次的目標(biāo)是?保證可靠連續(xù)地將 message 從某個 broker 上的 queue （作為源端）中取出，再將其 publish 到另外一個 broker 中的相應(yīng) exchange 上（作為目的端）。?作為源的 queue 和作為目的的 exchange?可以同時位于一個 broker 上，也可以位于不同 broker 上。?shovel 的行為就像編寫良好的客戶端應(yīng)用程序，負(fù)責(zé)連接源和目的，負(fù)責(zé) message 的讀出和寫入，以及負(fù)責(zé)連接失敗問題的處理（連接失敗怎么處理的）。
1、shovel 的主要優(yōu)勢在于：?
- 松耦合：? ? shovel 可以將位于不同管理域中的 broker（或者 cluster）上的 message 進(jìn)行移動。?這些 broker 或 cluster 可以包含不同的 user 和 vhost ；這些 broker 或 cluster 可以使用不同的 RabbitMQ 和 Erlang 版本；
- WAN 友好：Shovel 插件基于?AMQP 協(xié)議在 broker 間進(jìn)行通信， 并被設(shè)計(jì)成可以容忍時斷時續(xù)的連通性，且保證 message 不會丟失。
- 非侵入特性：為了使用 shovel 功能，你不必重新配置任何源或者目的資源。你甚至不需要重新啟動這些資源所在的 broker ：因?yàn)?shovel 可以運(yùn)行于完全不相關(guān)的 broker 上面。?
- 高度定制性：?當(dāng) shovel 成功連接后（連接上源或者目的），可以對其進(jìn)行相應(yīng)配置以執(zhí)行任意數(shù)量的相關(guān)方法。例如，源 queue 在最初不需要存在，可以在連接建立后聲明。?
2、shovel 做了些什么？
Shovel 插件會定義（和運(yùn)行） Erlang 客戶端應(yīng)用程序，只要在相應(yīng)的配置中定義了 shovel 相關(guān)信息。?在本質(zhì)上，shovel 可以類比為一個簡單的水泵。每一個 shovel 都會：
- connect?到源 broker 和目的 broker，
- 從 queue 中?consume?相應(yīng)的 message?，
- 每一條 message 將被?re-publishe?到目的 broker 中（默認(rèn)會使用原消息中的 exchange 名字和 routing_key 的值）。
通過對 shovel 進(jìn)行配置，可以對上述操作步驟進(jìn)行定制。
1）連接：在成功連接源或目的 broker 之后，就可以執(zhí)行一系列相應(yīng)的 AMQP 配置聲明了。Queue 、exchange 以及 binding 均可以進(jìn)行聲明。?shovel 插件會保證在目標(biāo) broker 失效后，嘗試重連到其他 broker 上；還可以為源端 broker 和目的端 broker 同時指定多個 shovel broker，以便從中（隨機(jī)）選擇要連接的 broker 。?可以設(shè)置 reconnection delay?以避免由于重連行為導(dǎo)致的網(wǎng)絡(luò)泛洪，或者可以在重連失敗后直接停止重連。??所有配置聲明（針對相應(yīng)的源和目的）會在重連成功后被重新發(fā)送。
2）消費(fèi)：在 Shovel 模型中的，consumer 收到 message 并自動進(jìn)行 acknowledge 動作的時機(jī)有以下幾種：?
- 在收到 message 時；
- 在 (re-)publication 后；
- 在 publication 被（目的端）confirmation 之后。
3）重新推送：可以顯式地對 publish 方法和 message 屬性進(jìn)行修改。?具體細(xì)節(jié)在下面的 [?configuration] 段中給出。
上述文字引用自：https://my.oschina.net/moooofly/blog/96716?spm=a2c4e.10696291.0.0.446b19a4xXNPHB
shovel 插件的使用存在 static 和 dynamic 兩種形式，其主要差異如下?
| Static Shovels | Dynamic Shovels |
| 基于 broker 的配置文件進(jìn)行定義 | 基于 broker 的 parameter 參數(shù)進(jìn)行定義 |
| Require a restart of the hosting broker to change.需要重啟宿主 broker 以便配置生效 | 可以在任意時間進(jìn)行創(chuàng)建和刪除，直接生效 |
| 更加通用：任何 queue 、exchange 或 binding 關(guān)系均可在啟動 | 更具有目標(biāo)性：被 shovel 所使用的?queue 、exchange 和 binding 關(guān)系能夠自動被聲明（創(chuàng)建） |
二、shovel 的使用場景
在了解了 shovel 的基本功能之后，下一個需要考慮的問題就是 shovel 的使用場景。相關(guān)的幾個問題總結(jié)如下：?
1.為什么需要使用 shovel 插件？?
答：當(dāng)業(yè)務(wù)需要可靠且連續(xù)地將消息從一個 broker 的 queue 里搬運(yùn)（轉(zhuǎn)發(fā)）到另一個 broker 的 exchange 時（最終達(dá)到某個 queue 里?）使用；作為 source 的 queue 和作為 destination 的 exchange 可以位于同一個 broker 上（通常要求處于不同的 vhost 下），也可以位于不同的 broker 上。?
2.使用 shovel 插件的好處？?
答：shovel 基于 RabbitMQ 的 Erlang 客戶端實(shí)現(xiàn)，且作為 built-in 插件被使用，故可以隨 broker 的啟動而自動啟動；shovel 具有松耦合特性：通過該插件可以在分屬不同管理域下的 broker 或 cluster 之間進(jìn)行消息的搬運(yùn)；shovel 具有 WAN 友好特性：基于 AMQP 0-9-1 協(xié)議實(shí)現(xiàn)，并設(shè)計(jì)成能夠保證在不穩(wěn)定網(wǎng)絡(luò)場景下不丟失消息；shovel 具有高度可定制性：允許在 shovel 建立連接后，立即執(zhí)行指定的 AMQP 方法進(jìn)行定制化操作（例如聲明 queue 的動作）；?
3.shovel 與 cluster 的結(jié)合問題?
答：如果每個 shovel 均指定了屬于源集群或目的集群中的多個 source URI 或 destination URI ，那么當(dāng) shovel 遇到節(jié)點(diǎn)失效時，就可以進(jìn)行失效轉(zhuǎn)移操作；對于 dynamic shovel 來說，其定義信息會出現(xiàn)在使能了 shovel 插件的、目標(biāo)集群中的所有節(jié)點(diǎn)上（即所有節(jié)點(diǎn)都能獲取到 shovel 的定義信息），而每一個 shovel 僅會在集群中的某一個節(jié)點(diǎn)上啟動（任意一個），并在該節(jié)點(diǎn)失效后，轉(zhuǎn)移到另外的節(jié)點(diǎn)上去；對于 static shovel 來說，需要在使能了 shovel 插件的、目標(biāo)集群中的所有節(jié)點(diǎn)的配置文件中添加相應(yīng)的定義信息，同樣的，每一個 shovel 僅會在集群中的某一個節(jié)點(diǎn)上啟動，并在該節(jié)點(diǎn)失效后轉(zhuǎn)移到另外的節(jié)點(diǎn)上去。?
（大概意思描述，下同）在兩個地理位置相距較遠(yuǎn)的地方布置了兩個 RabbitMQ 節(jié)點(diǎn)，其中 Goleta 節(jié)點(diǎn)用于負(fù)責(zé)大部分訂單的處理，而 Carpinteria 節(jié)點(diǎn)用于解決 Goleta 節(jié)點(diǎn)達(dá)到一個負(fù)荷后的、額外訂單的處理。該場景屬于基于 WAN 的互聯(lián)，所以無法使用 RabbitMQ 的集群功能；?
?在未使用 shovel 功能前，只能通過同時將訂單發(fā)往兩地的方式進(jìn)行處理，在這種場景下，最大延遲取決于較遠(yuǎn)的一端；并且可能會對業(yè)務(wù)提出變更要求；?
在使用了 shovel 插件后，模型變成了近端同步確認(rèn)，遠(yuǎn)端異步確認(rèn)的方式，大大提高了訂單確認(rèn)速度，并且還能保證可靠性；?
?
最終的內(nèi)部結(jié)構(gòu)圖如上圖所示。?一句話總結(jié)：shovel 適用于需要對資源請求（訂單）快速作出相應(yīng)的場景，能夠有效利用跨 WAN 的其他 broker 或 cluster 一起進(jìn)行請求的處理（訂單處理）。?
三、針對 static 和 dynamic 兩種配置的 shovel 的實(shí)驗(yàn)
shovel 插件的使用存在 static 和 dynamic 兩種形式，其主要差異如下?
| Static Shovels | Dynamic Shovels |
| 基于 broker 的配置文件進(jìn)行定義 | 基于 broker 的 parameter 參數(shù)進(jìn)行定義 |
| Require a restart of the hosting broker to change.需要重啟宿主 broker 以便配置生效 | 可以在任意時間進(jìn)行創(chuàng)建和刪除，直接生效 |
| 更加通用：任何 queue 、exchange 或 binding 關(guān)系均可在啟動 | 更具有目標(biāo)性：被 shovel 所使用的?queue 、exchange 和 binding 關(guān)系能夠自動被聲明（創(chuàng)建） |
【static shovel】
首先按照《RabbitMQ in Action》中的示例進(jìn)行配置（調(diào)整了監(jiān)聽端口，以及 user 和 password?）?
?
此時在 Web UI 上會看到如下錯誤信息
或者?
?
這兩個狀態(tài)在不停的切換，表明 RabbitMQ 內(nèi)部在不斷重新嘗試建立 shovel 連接；?
通過日志可以看出，問題出現(xiàn)在 shovel 插件建立 AMQP 連接過程的握手節(jié)點(diǎn)，而錯誤原因?yàn)椤?access to vhost '', ?refused by user 'dev'?”。說明 vhost 的指定有錯誤。通過抓包內(nèi)容同樣可以確認(rèn)這一點(diǎn)。
重新調(diào)整配置文件如下
?
上圖中的紅框位置為增加的內(nèi)容，其中 %2F 代表的就是 vhost "/" ，此處需要進(jìn)行轉(zhuǎn)義使用。?
變更配置后，重啟相應(yīng)的 broker ，此時可以看到
（source broker）?
（destination broker）?
可以看到 shovel 已經(jīng)正常運(yùn)行了，查看此時的網(wǎng)絡(luò)連接情況如下（注：source broker 在 81.111 上，destination broker 在 80.111 上）?
到此，靜態(tài) shovel 的基本使用已經(jīng)摸的比較清楚了~~?
最后的總結(jié)
- 在使用 shovel 插件時，只需要在 source 節(jié)點(diǎn)進(jìn)行配置，destination 節(jié)點(diǎn)不需要配置；同理，只需要在 source 節(jié)點(diǎn)上使能 shovel 插件，destination 節(jié)點(diǎn)無需使能該插件；
- 在 shovel 正常工作時，對于 source 節(jié)點(diǎn)來說，增加了一條用于 consumer 的 TCP 連接；對于 destination 節(jié)點(diǎn)來說，增加了一條用于 producer 的 TCP 連接，和普通客戶端的連接行為沒什么不同；
總結(jié)
以上是生活随笔為你收集整理的RabbitMQ—队列迁移插件shovel的使用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 面试题—开发篇
- 下一篇： 五大常用经典算法—回溯算法