RabbitMQ Shovel的原理好用法是什么

RabbitMQ Shovel的原理好用法是什么，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

Shovel能夠可靠、持續(xù)地從一個(gè)Broker中的隊(duì)列(作為源端，即source)拉取數(shù)據(jù)并轉(zhuǎn)發(fā)至另一個(gè)Broker中的交換器(作為目的端，即destination)。作為源端的隊(duì)列和作為目的端的交換器可以位于同一個(gè)Broker上，也可以位于不同的Broker上。

Shovel原理

broker1中有交換器exchange1和隊(duì)列queue1，且這兩者通過路由鍵"rk1"進(jìn)行綁定；broker2中有交換器exchange2和隊(duì)列queue2，且這兩者通過路由鍵"rk2"進(jìn)行綁定。

在隊(duì)列queue1和交換器exchange2之間配置一個(gè)Shovel link，當(dāng)一條內(nèi)容為"shovel test payload" 的消息從客戶端發(fā)送至交換器exchange1的時(shí)候，這條消息會(huì)經(jīng)過上圖中的數(shù)據(jù)流轉(zhuǎn)最后存儲(chǔ)在隊(duì)列queue2中。如果在配置Shovel link設(shè)置了add-forward-headers參數(shù)為true，則在消費(fèi)到隊(duì)列queue2中這條消息的時(shí)候會(huì)有特殊的headers屬性標(biāo)記。如下圖：上面講述的是源端為隊(duì)列，目的端為交換器，下面看一下目的端也為隊(duì)列的示意圖：雖然看起來隊(duì)列queue1是通過Shovel link直接將消息轉(zhuǎn)發(fā)至queue2的，其實(shí)中間也是經(jīng)由broker2的交換器轉(zhuǎn)發(fā)，只不過這個(gè)交換器是默認(rèn)的交換器而己。

再看一下源端是交換器，目的端是交換器的示意圖：雖然看起來交換器exchange1是通過Shovel link直接將消息轉(zhuǎn)發(fā)至exchange2上的，實(shí)際上在broker1中會(huì)新建一個(gè)隊(duì)列(名稱由RabbitMQ自定義，比如上圖中的"amq.gen-ZwolUsoUchY6a7xaPyrZZH")并綁定exchange1，消息從交換器exchange1過來先存儲(chǔ)在這個(gè)隊(duì)列中，然后Shovel再從這個(gè)隊(duì)列中拉取消息進(jìn)而轉(zhuǎn)發(fā)至交換器exchange2。

broker1和broker2中的exchange1、queue1、exchange2及queue2都可以在Shovel成功連接源端或者目的端Broker之后再第一次創(chuàng)建(執(zhí)行一系列相應(yīng)的AMQP配置聲明時(shí))，它們并不一定需要在Shovel link建立之前創(chuàng)建。Shovel可以為源端或者目的端配置多個(gè)Broker的地址，這樣可以使得源端或者目的端的Broker失效后能夠嘗試重連到其他Broker之上(隨機(jī)挑選)。

可以設(shè)置reconnect delay參數(shù)以避免由于重連行為導(dǎo)致的網(wǎng)絡(luò)泛洪，或者可以在重連失敗后直接停止連接。針對(duì)源端和目的端的所有配置聲明會(huì)在重連成功之后被重新發(fā)送。

Shovel使用

Shovel插件默認(rèn)也在RabbitMQ的發(fā)布包中，執(zhí)行rabbitmq-plugins enable rabbitmqshovel命令可以開啟Shovel功能，該命令默認(rèn)也會(huì)開啟amqpclient插件。要開啟Shovel的管理插件，需要執(zhí)行rabbitmq-plugins enable rabbitmqshovelmanagement命令。

Shovel既可以部署在源端，也可以部署在目的端。有兩種方式可以部署Shovel: 靜態(tài)方式和動(dòng)態(tài)方式。靜態(tài)方式是指在rabbitmq.config配置文件中設(shè)置，而動(dòng)態(tài)方式是指通過Runtime Parameter設(shè)置。我們這里講動(dòng)態(tài)方式配置，基于插件的WEB管理界面進(jìn)行配置。

• Name：該Shovel配置的名稱

• Source：Source中需要指定協(xié)議類型、連接的源節(jié)點(diǎn)地址，源端的類型(隊(duì)列、交換器，如果是交換器還需要填入routingKey)

• Prefetch count：該參數(shù)表示Shovel內(nèi)部緩存的消息條數(shù)，可以參考Federation的相關(guān)參數(shù)。Shovel的內(nèi)部緩存是源端服務(wù)器和目的端服務(wù)器之間的中間緩存部分

• Auto-delete：默認(rèn)為Never表示不刪除自己，如果設(shè)置為After initial length transferred，則再消息轉(zhuǎn)移完成后刪除自己。

• Destination：Destination需要指定協(xié)議類型，連接的目的節(jié)點(diǎn)地址，目的端的類型(隊(duì)列、交換器，如果是交換器還需要填入routingKey)

• Add forwarding headers：如果設(shè)置為true，則會(huì)在轉(zhuǎn)發(fā)的消息內(nèi)添加x-shovelled的header屬性

• Reconnect delay：指定在Shovel link失效的情況下，重新建立連接前需要等待的時(shí)間，單位為秒。如果設(shè)置為0，則不會(huì)進(jìn)行重連動(dòng)作，即Shovel會(huì)在首次連接失效時(shí)停止工作。默認(rèn)為5秒。

• Acknowledgement mode：參考Federation的配置。no ack表示無須任何消息確認(rèn)行為；on publish表示Shovel會(huì)把每一條消息發(fā)送到目的端之后再向源端發(fā)送消息確認(rèn)； on confirm表示Shovel會(huì)使用publisher confirm機(jī)制，在收到目的端的消息確認(rèn)之后再向源端發(fā)送消息確認(rèn)。

Shovel處理消息堆積

消息堆積是在使用消息中間件過程中遇到的最正常不過的事情。消息堆積是一把雙刃劍，適量的堆積可以有削峰、緩存之用，但是如果堆積過于嚴(yán)重，那么就可能影響到其他隊(duì)列的使用，導(dǎo)致整體服務(wù)質(zhì)量的下降。

處理消息堆積的整體思路是為集群準(zhǔn)備一個(gè)備用集群，當(dāng)在線的集群某個(gè)隊(duì)列消息堆積嚴(yán)重時(shí)，則開啟Shovel將消息導(dǎo)入到備用機(jī)群的某一個(gè)，等到在線集群消息堆積狀況回暖時(shí)，再開啟Shovel從備用集群的隊(duì)列中導(dǎo)入到原集群中的隊(duì)列。

下圖是Federation/Shovel與集群的區(qū)別

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝您對(duì)億速云的支持。