RabbitMQ如何實(shí)現(xiàn)集群管理

這篇文章主要為大家展示了“RabbitMQ如何實(shí)現(xiàn)集群管理”，內(nèi)容簡(jiǎn)而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“RabbitMQ如何實(shí)現(xiàn)集群管理”這篇文章吧。

RabbitMQ集群方案的原理

RabbitMQ這款消息隊(duì)列中間件產(chǎn)品本身是基于Erlang編寫，Erlang語(yǔ)言天生具備分布式特性（通過同步Erlang集群各節(jié)點(diǎn)的magic cookie來實(shí)現(xiàn)）。因此，RabbitMQ天然支持Clustering。這使得RabbitMQ本身不需要像ActiveMQ、Kafka那樣通過ZooKeeper分別來實(shí)現(xiàn)HA方案和保存集群的元數(shù)據(jù)。集群是保證可靠性的一種方式，同時(shí)可以通過水平擴(kuò)展以達(dá)到增加消息吞吐量能力的目的。下面先來看下RabbitMQ集群的整體方案：

上面圖中采用三個(gè)節(jié)點(diǎn)組成了一個(gè)RabbitMQ的集群，Exchange A（交換器，對(duì)于RabbitMQ基礎(chǔ)概念不太明白的童鞋可以看下基礎(chǔ)概念）的元數(shù)據(jù)信息在所有節(jié)點(diǎn)上是一致的，而Queue（存放消息的隊(duì)列）的完整數(shù)據(jù)則只會(huì)存在于它所創(chuàng)建的那個(gè)節(jié)點(diǎn)上。，其他節(jié)點(diǎn)只知道這個(gè)queue的metadata信息和一個(gè)指向queue的owner node的指針。

RabbitMQ集群元數(shù)據(jù)的同步

RabbitMQ集群會(huì)始終同步四種類型的內(nèi)部元數(shù)據(jù)（類似索引）：a.隊(duì)列元數(shù)據(jù)：隊(duì)列名稱和它的屬性；b.交換器元數(shù)據(jù)：交換器名稱、類型和屬性；c.綁定元數(shù)據(jù)：一張簡(jiǎn)單的表格展示了如何將消息路由到隊(duì)列；d.vhost元數(shù)據(jù)：為vhost內(nèi)的隊(duì)列、交換器和綁定提供命名空間和安全屬性；因此，當(dāng)用戶訪問其中任何一個(gè)RabbitMQ節(jié)點(diǎn)時(shí)，通過rabbitmqctl查詢到的queue／user／exchange/vhost等信息都是相同的。

為何RabbitMQ集群僅采用元數(shù)據(jù)同步的方式

我想肯定有不少同學(xué)會(huì)問，想要實(shí)現(xiàn)HA方案，那將RabbitMQ集群中的所有Queue的完整數(shù)據(jù)在所有節(jié)點(diǎn)上都保存一份不就可以了么？（可以類似MySQL的主主模式嘛）這樣子，任何一個(gè)節(jié)點(diǎn)出現(xiàn)故障或者宕機(jī)不可用時(shí)，那么使用者的客戶端只要能連接至其他節(jié)點(diǎn)能夠照常完成消息的發(fā)布和訂閱嘛。我想RabbitMQ的作者這么設(shè)計(jì)主要還是基于集群本身的性能和存儲(chǔ)空間上來考慮。第一，存儲(chǔ)空間，如果每個(gè)集群節(jié)點(diǎn)都擁有所有Queue的完全數(shù)據(jù)拷貝，那么每個(gè)節(jié)點(diǎn)的存儲(chǔ)空間會(huì)非常大，集群的消息積壓能力會(huì)非常弱（無法通過集群節(jié)點(diǎn)的擴(kuò)容提高消息積壓能力）；第二，性能，消息的發(fā)布者需要將消息復(fù)制到每一個(gè)集群節(jié)點(diǎn)，對(duì)于持久化消息，網(wǎng)絡(luò)和磁盤同步復(fù)制的開銷都會(huì)明顯增加。

RabbitMQ集群發(fā)送/訂閱消息的基本原理

RabbitMQ集群的工作原理圖如下：

場(chǎng)景1、客戶端直接連接隊(duì)列所在節(jié)點(diǎn)

如果有一個(gè)消息生產(chǎn)者或者消息消費(fèi)者通過amqp-client的客戶端連接至節(jié)點(diǎn)1進(jìn)行消息的發(fā)布或者訂閱，那么此時(shí)的集群中的消息收發(fā)只與節(jié)點(diǎn)1相關(guān)，這個(gè)沒有任何問題；如果客戶端相連的是節(jié)點(diǎn)2或者節(jié)點(diǎn)3（隊(duì)列1數(shù)據(jù)不在該節(jié)點(diǎn)上），那么情況又會(huì)是怎么樣呢？

場(chǎng)景2、客戶端連接的是非隊(duì)列數(shù)據(jù)所在節(jié)點(diǎn)

如果消息生產(chǎn)者所連接的是節(jié)點(diǎn)2或者節(jié)點(diǎn)3，此時(shí)隊(duì)列1的完整數(shù)據(jù)不在該兩個(gè)節(jié)點(diǎn)上，那么在發(fā)送消息過程中這兩個(gè)節(jié)點(diǎn)主要起了一個(gè)路由轉(zhuǎn)發(fā)作用，根據(jù)這兩個(gè)節(jié)點(diǎn)上的元數(shù)據(jù)（也就是上文提到的：指向queue的owner node的指針）轉(zhuǎn)發(fā)至節(jié)點(diǎn)1上，最終發(fā)送的消息還是會(huì)存儲(chǔ)至節(jié)點(diǎn)1的隊(duì)列1上。同樣，如果消息消費(fèi)者所連接的節(jié)點(diǎn)2或者節(jié)點(diǎn)3，那這兩個(gè)節(jié)點(diǎn)也會(huì)作為路由節(jié)點(diǎn)起到轉(zhuǎn)發(fā)作用，將會(huì)從節(jié)點(diǎn)1的隊(duì)列1中拉取消息進(jìn)行消費(fèi)。

在單 node 系統(tǒng)和多 node 構(gòu)成的 cluster 系統(tǒng)中聲明 queue、exchange ，以及進(jìn)行 binding 會(huì)有什么不同？

當(dāng)你在單 node 上聲明 queue 時(shí)，只要該 node 上相關(guān)元數(shù)據(jù)進(jìn)行了變更，你就會(huì)得到 Queue.Declare-ok 回應(yīng)；而在 cluster 上聲明 queue ，則要求 cluster 上的全部 node 都要進(jìn)行元數(shù)據(jù)成功更新，才會(huì)得到 Queue.Declare-ok 回應(yīng)。另外，若 node 類型為 RAM node 則變更的數(shù)據(jù)僅保存在內(nèi)存中，若類型為 disk node 則還要變更保存在磁盤上的數(shù)據(jù)。

客戶端連接到 cluster 中的任意 node 上是否都能正常工作？

是的?？蛻舳烁杏X不到有何不同。

若 cluster 中擁有某個(gè) queue 的 owner node 失效了，且該 queue 被聲明具有 durable 屬性，是否能夠成功從其他 node 上重新聲明該 queue ？

不能，在這種情況下，將得到 404 NOT_FOUND 錯(cuò)誤。只能等 queue 所屬的 node 恢復(fù)后才能使用該 queue 。但若該 queue 本身不具有 durable 屬性，則可在其他 node 上重新聲明。

cluster 中 node 的失效會(huì)對(duì) consumer 產(chǎn)生什么影響？若是在 cluster 中創(chuàng)建了 mirrored queue ，這時(shí) node 失效會(huì)對(duì) consumer 產(chǎn)生什么影響？

若是 consumer 所連接的那個(gè) node 失效（無論該 node 是否為 consumer 所訂閱 queue 的 owner node），則 consumer 會(huì)在發(fā)現(xiàn) TCP 連接斷開時(shí)，按標(biāo)準(zhǔn)行為執(zhí)行重連邏輯，并根據(jù)“Assume Nothing”原則重建相應(yīng)的 fabric 即可。若是失效的 node 為 consumer 訂閱 queue 的owner node，則 consumer 只能通過 Consumer Cancellation Notification 機(jī)制來檢測(cè)與該 queue 訂閱關(guān)系的終止，否則會(huì)出現(xiàn)傻等卻沒有任何消息來到的問題。

能夠在地理上分開的不同數(shù)據(jù)中心使用 RabbitMQ cluster 么？

不能。第一，你無法控制所創(chuàng)建的 queue 實(shí)際分布在 cluster 里的哪個(gè) node 上（一般使用 HAProxy + cluster 模型時(shí)都是這樣），這可能會(huì)導(dǎo)致各種跨地域訪問時(shí)的常見問題；第二，Erlang 的 OTP 通信框架對(duì)延遲的容忍度有限，這可能會(huì)觸發(fā)各種超時(shí)，導(dǎo)致業(yè)務(wù)疲于處理；第三，在廣域網(wǎng)上的連接失效問題將導(dǎo)致經(jīng)典的“腦裂”問題，而 RabbitMQ 目前無法處理（該問題主要是說 Mnesia）。

以上是“RabbitMQ如何實(shí)現(xiàn)集群管理”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！