今天主要分享RabbitMQ常見的4種集群架構(gòu),有待改進(jìn),大家一起看看吧!
01主備模式也稱為Warren(兔子窩)模式。實(shí)現(xiàn)rabbitMQ的高可用集群,一般在并發(fā)和數(shù)據(jù)量不高的情況下,這種模式非常的好用且簡(jiǎn)單。
也就是一個(gè)主/備方案,主節(jié)點(diǎn)提供讀寫,備用節(jié)點(diǎn)不提供讀寫。如果主節(jié)點(diǎn)掛了,就切換到備用節(jié)點(diǎn),原來的備用節(jié)點(diǎn)升級(jí)為主節(jié)點(diǎn)提供讀寫服務(wù),當(dāng)原來的主節(jié)點(diǎn)恢復(fù)運(yùn)行后,原來的主節(jié)點(diǎn)就變成備用節(jié)點(diǎn),和activeMQ利用zookeeper做主/備一樣,也可以一主多備。
HaProxy配置:
listenrabbitmq_clusterbind0.0.0.0:567#配置tcp模式modetcp#簡(jiǎn)單的輪詢balanceroundrobin#主節(jié)點(diǎn)roundrobin隨機(jī)server你的76機(jī)器hostname192.168.11.76:5672checkinter5000rise2fall2server你的77機(jī)器hostname192.168.11.77:5672backupcheckinter5000rise2fall2#備用節(jié)點(diǎn)注意了,上面的rabbitMQ集群節(jié)點(diǎn)配置#inter每隔5秒對(duì)mq集群做健康檢查,2次正確證明服務(wù)可用,2次失敗證明服務(wù)器不可用,并且配置主備機(jī)制
02***模式***模式可以實(shí)現(xiàn)雙活的一種模式,簡(jiǎn)稱shovel模式,所謂的shovel就是把消息進(jìn)行不同數(shù)據(jù)中心的復(fù)制工作,可以跨地域的讓兩個(gè)MQ集群互聯(lián),遠(yuǎn)距離通信和復(fù)制。
Shovel就是我們可以把消息進(jìn)行數(shù)據(jù)中心的復(fù)制工作,可以跨地域的讓兩個(gè)MQ集群互聯(lián)。
***模式
如圖所示,有兩個(gè)異地的MQ集群(可以是更多的集群),當(dāng)用戶在地區(qū)1這里下單了,系統(tǒng)發(fā)消息到1區(qū)的MQ服務(wù)器,發(fā)現(xiàn)MQ服務(wù)已超過設(shè)定的閾值,負(fù)載過高,這條消息就會(huì)被轉(zhuǎn)到地區(qū)2的MQ服務(wù)器上,由2區(qū)的去執(zhí)行后面的業(yè)務(wù)邏輯,相當(dāng)于分?jǐn)偽覀兊姆?wù)壓力。
在使用了shovel插件后,模型變成了近端同步確認(rèn),遠(yuǎn)端異步確認(rèn)的方式,大大提高了訂單確認(rèn)速度,并且還能保證可靠性。
shovel模式拓?fù)鋱D
如上圖所示,當(dāng)我們的消息到達(dá)exchange,它會(huì)判斷當(dāng)前的負(fù)載情況以及設(shè)定的閾值,如果負(fù)載不高就把消息放到我們正常的warehouse_goleta隊(duì)列中,如果負(fù)載過高了,就會(huì)放到backup_orders隊(duì)列中。backup_orders隊(duì)列通過shovel插件與另外的MQ集群進(jìn)行同步數(shù)據(jù),把消息發(fā)到第二個(gè)MQ集群上。
不過這是rabbitMQ比較早期的架構(gòu)模型了,現(xiàn)在很少使用了。
03鏡像模式非常經(jīng)典的mirror鏡像模式,保證100%數(shù)據(jù)不丟失。在實(shí)際工作中也是用得最多的,并且實(shí)現(xiàn)非常的簡(jiǎn)單,一般互聯(lián)網(wǎng)大廠都會(huì)構(gòu)建這種鏡像集群模式。
mirror鏡像隊(duì)列,目的是為了保證rabbitMQ數(shù)據(jù)的高可靠性解決方案,主要就是實(shí)現(xiàn)數(shù)據(jù)的同步,一般來講是2-3個(gè)節(jié)點(diǎn)實(shí)現(xiàn)數(shù)據(jù)同步。對(duì)于100%數(shù)據(jù)可靠性解決方案,一般是采用3個(gè)節(jié)點(diǎn)。
集群架構(gòu)如下
mirror鏡像隊(duì)列
如上圖所示,用KeepAlived做了HA-Proxy的高可用,然后有3個(gè)節(jié)點(diǎn)的MQ服務(wù),消息發(fā)送到主節(jié)點(diǎn)上,主節(jié)點(diǎn)通過mirror隊(duì)列把數(shù)據(jù)同步到其他的MQ節(jié)點(diǎn),這樣來實(shí)現(xiàn)其高可靠。
04多活模式這個(gè)也是實(shí)現(xiàn)異地?cái)?shù)據(jù)復(fù)制的主流模式,因?yàn)閟hovel模式配置比較復(fù)雜,所以一般來說,實(shí)現(xiàn)異地集群的都是采用這種雙活或者多活模型來實(shí)現(xiàn)的。這種模式需要依賴rabbitMQ的federation插件,可以實(shí)現(xiàn)持續(xù)的,可靠的AMQP數(shù)據(jù)通信,多活模式在實(shí)際配置與應(yīng)用非常的簡(jiǎn)單。
rabbitMQ部署架構(gòu)采用雙中心模式(多中心),那么在兩套(或多套)數(shù)據(jù)中心各部署一套rabbitMQ集群,各中心的rabbitMQ服務(wù)除了需要為業(yè)務(wù)提供正常的消息服務(wù)外,中心之間還需要實(shí)現(xiàn)部分隊(duì)列消息共享。
多活集群架構(gòu)如下:
federation插件是一個(gè)不需要構(gòu)建cluster,而在brokers之間傳輸消息的高性能插件,federation插件可以在brokers或者cluster之間傳輸消息,連接的雙方可以使用不同的users和virtualhosts,雙方也可以使用不同版本的rabbitMQ和erlang。federation插件使用AMQP協(xié)議通信,可以接受不連續(xù)的傳輸。federation不是建立在集群上的,而是建立在單個(gè)節(jié)點(diǎn)上的,如圖上黃色的rabbitnode3可以與綠色的node1、node2、node3中的任意一個(gè)利用federation插件進(jìn)行數(shù)據(jù)同步。
如上圖所示,federationexchanges可以看成downstream從upstream主動(dòng)拉取消息,但是并不是拉取所有消息,必須是在downstream上已經(jīng)明確定義Bingdings關(guān)系的exchange,也就是有實(shí)際的物理queue來接收消息,才會(huì)從upstream拉取消息到downstream。
它使用AMQP協(xié)議實(shí)現(xiàn)代理間通信,downstream會(huì)將綁定關(guān)系組合在一起,綁定/解綁命令將發(fā)送到upstream交換機(jī)。因此,federationexchange只接收具有訂閱的消息。
其實(shí)四種模式建議大家重點(diǎn)掌握第三種,鏡像模式屬于標(biāo)準(zhǔn)的集群鏡像模式。其他幾種模式都存在出現(xiàn)臟數(shù)據(jù)問題的可能,后面會(huì)分享更多devops和DBA方面內(nèi)容,感興趣的朋友可以關(guān)注下!