(一) 功能和原理
設計集羣的目的node
容許消費者和生產者在RabbitMQ節點崩潰的狀況下繼續運行
經過增長更多的節點來擴展消息通訊的吞吐量
1 集羣配置方式
RabbitMQ能夠經過三種方法來部署分佈式集羣系統,分別是:cluster,federation,shovelgit
cluster:算法
不支持跨網段,用於同一個網段內的局域網
能夠隨意的動態增長或者減小
節點之間須要運行相同版本的RabbitMQ和Erlang
federation:應用於廣域網,容許單臺服務器上的交換機或隊列接收發布到另外一臺服務器上交換機或隊列的消息,能夠是單獨機器或集羣。federation隊列相似於單向點對點鏈接,消息會在聯盟隊列之間轉發任意次,直到被消費者接受。一般使用federation來鏈接internet上的中間服務器,用做訂閱分發消息或工做隊列。vim
shovel:鏈接方式與federation的鏈接方式相似,但它工做在更低層次。能夠應用於廣域網。服務器
2 節點類型
RAM node:內存節點將全部的隊列、交換機、綁定、用戶、權限和vhost的元數據定義存儲在內存中,好處是可使得像交換機和隊列聲明等操做更加的快速。cookie
Disk node:將元數據存儲在磁盤中,單節點系統只容許磁盤類型的節點,防止重啓RabbitMQ的時候,丟失系統的配置信息。網絡
問題說明: RabbitMQ要求在集羣中至少有一個磁盤節點,全部其餘節點能夠是內存節點,當節點加入或者離開集羣時,必需要將該變動通知到至少一個磁盤節點。若是集羣中惟一的一個磁盤節點崩潰的話,集羣仍然能夠保持運行,可是沒法進行其餘操做(增刪改查),直到節點恢復。
解決方案:設置兩個磁盤節點,至少有一個是可用的,能夠保存元數據的更改。架構
3 Erlang Cookie
Erlang Cookie是保證不一樣節點能夠相互通訊的密鑰,要保證集羣中的不一樣節點相互通訊必須共享相同的Erlang Cookie。具體的目錄存放在/var/lib/rabbitmq/.erlang.cookie。app
說明: 這就要從rabbitmqctl命令的工做原理提及,RabbitMQ底層是經過Erlang架構來實現的,因此rabbitmqctl會啓動Erlang節點,並基於Erlang節點來使用Erlang系統鏈接RabbitMQ節點,在鏈接過程當中須要正確的Erlang Cookie和節點名稱,Erlang節點經過交換Erlang Cookie以得到認證。負載均衡
4 鏡像隊列
功能和原理
RabbitMQ的Cluster集羣模式通常分爲兩種,普通模式和鏡像模式。
普通模式:默認的集羣模式,以兩個節點(rabbit0一、rabbit02)爲例來進行說明。對於Queue來講,消息實體只存在於其中一個節點rabbit01(或者rabbit02),rabbit01和rabbit02兩個節點僅有相同的元數據,即隊列的結構。當消息進入rabbit01節點的Queue後,consumer從rabbit02節點消費時,RabbitMQ會臨時在rabbit0一、rabbit02間進行消息傳輸,把A中的消息實體取出並通過B發送給consumer。因此consumer應儘可能鏈接每個節點,從中取消息。即對於同一個邏輯隊列,要在多個節點創建物理Queue。不然不管consumer連rabbit01或rabbit02,出口總在rabbit01,會產生瓶頸。當rabbit01節點故障後,rabbit02節點沒法取到rabbit01節點中還未消費的消息實體。若是作了消息持久化,那麼得等rabbit01節點恢復,而後纔可被消費;若是沒有持久化的話,就會產生消息丟失的現象。
鏡像模式:將須要消費的隊列變爲鏡像隊列,存在於多個節點,這樣就能夠實現RabbitMQ的HA高可用性。做用就是消息實體會主動在鏡像節點之間實現同步,而不是像普通模式那樣,在consumer消費數據時臨時讀取。缺點就是,集羣內部的同步通信會佔用大量的網絡帶寬。
實現機制
鏡像隊列實現了RabbitMQ的高可用性(HA),具體的實現策略以下所示:
ha-mode ha-params 功能
all 空 鏡像隊列將會在整個集羣中複製。當一個新的節點加入後,也會在這 個節點上覆制一份。
exactly count 鏡像隊列將會在集羣上覆制count份。若是集羣數量少於count時候,隊列會複製到全部節點上。若是大於Count集羣,有一個節點crash後,新進入節點也不會作新的鏡像。
nodes node name 鏡像隊列會在node name中複製。若是這個名稱不是集羣中的一個,這不會觸發錯誤。若是在這個node list中沒有一個節點在線,那麼這個queue會被聲明在client鏈接的節點。
實例列舉:
queue_args("x-ha-policy":"all") //定義字典來設置額外的隊列聲明參數 channel.queue_declare(queue="hello-queue",argument=queue_args)
若是須要設定特定的節點(以rabbit@localhost爲例),再添加一個參數
queue_args("x-ha-policy":"nodes", "x-ha-policy-params":["rabbit@localhost"]) channel.queue_declare(queue="hello-queue",argument=queue_args)
能夠經過命令行查看那個主節點進行了同步
rabbitmqctl list_queue name slave_pids synchronised_slave_pids
(二) RabbitMQ Cluster 配置
1 單機多節點部署
在啓動RabbitMQ節點以後,服務器默認的節點名稱是Rabbit和監聽端口5672,若是想在同一臺機器上啓動多個節點,那麼其餘的節點就會由於節點名稱和端口與默認的衝突而致使啓動失敗,能夠經過設置環境變量來實現,具體方法以下:
首先在機器上設置兩個節點rabbit和rabbit_01
rabbitmqctl stop //先中止運行節點,再進行集羣部署 RABBITMQ_NODE_PORT=5672 RABBITMQ_NODENAME=rabbit //設置環境變量指定端口和節點名稱 rabbitmq-server -detached //後臺啓動節點 RABBITMQ_NODE_PORT=5673 RABBITMQ_NODENAME=rabbit_01 //設置環境變量指定端口和節點名稱 rabbitmq-server -detached //後臺啓動節點
或者經過添加/etc/rabbitmq/rabbitmq-env.conf文件來進行設置:
NODE_PORT=5672 NODENAME=rabbit NODE_PORT=5673 NODENAME=rabbit_01
將rabbit_01節點添加到第一個集羣節點rabbit中
rabbitmqctl -n rabbit_01@localhost stop_app //中止rabbit_01節點的應用 rabbitmqctl -n rabbit_01@localhost join_cluster rabbit@localhost //將rabbit_01添加到集羣節點rabbit中去 rabbitmqctl cluster_status //查看集羣節點的狀態 rabbitmqctl -n rabbit_01@localhost start_app //啓動rabbit_01節點的應用
//能夠看到以下信息,說明節點添加成功,代表都是磁盤類型的節點
Cluster status of node rabbit@localhost ... [{nodes,[{disc,[rabbit@localhost,rabbit_01@localhost]}]}, {running_nodes,[rabbit@localhost]}, {cluster_name,<<"rabbit@localhost">>}, {partitions,[]}, {alarms,[{rabbit@localhost,[]}]}]
2 多機多節點部署
不一樣於單機多節點的狀況,在多機環境,若是要在cluster集羣內部署多個節點,須要注意兩個方面:
保證須要部署的這幾個節點在同一個局域網內
須要有相同的Erlang Cookie,不然不能進行通訊,爲保證cookie的徹底一致,採用從一個節點copy的方式
環境介紹:
RabbitMQ節點 IP地址 工做模式 操做系統
rabbitmqCluster 186.16.195.24 DISK CentOS 7.0 - 64位
rabbitmqCluster01 186.16.195.25 DISK CentOS 7.0 - 64位
rabbitmqCluster02 186.16.195.26 DISK CentOS 7.0 - 64位
cluster部署過程:
局域網配置
分別在三個節點的/etc/hosts下設置相同的配置信息
186.16.195.24 rabbitmqCluster 186.16.195.25 rabbitmqCluster01 186.16.195.26 rabbitmqCluster02
設置不一樣節點間同一認證的Erlang Cookie
採用從主節點copy的方式保持Cookie的一致性
[root@rabbitmqCluster01]# scp /var/lib/rabbitmq/.erlang.cookie 186.16.195.25:/var/lib/rabbitmq
[root@rabbitmqCluster02]# scp /var/lib/rabbitmq/.erlang.cookie 186.16.195.26:/var/lib/rabbitmq
使用 -detached運行各節點
rabbitmqctl stop
rabbitmq-server -detached
查看各節點的狀態
[root@rabbitmqCluster]#rabbitmqctl cluster_status
[root@rabbitmqCluster01]#rabbitmqctl cluster_status
[root@rabbitmqCluster02]#rabbitmqctl cluster_status
建立並部署集羣,以rabbitmqCluster01節點爲例:
[root@rabbitmqCluster01]#rabbitmqctl stop_app
[root@rabbitmqCluster01]#rabbitmqctl join_cluster rabbit@rabbitmqCluster
[root@rabbitmqCluster01]#rabbitmqctl start_app
查看集羣狀態
[root@rabbitmqCluster]#rabbitmqctl cluster_status
RabbitMQ負載均衡配置 前言:從目前來看,基於RabbitMQ的分佈式通訊框架主要包括兩部份內容,一是要確保可用性和性能,另外一個就是編寫當節點發生故障時知道如何重連到集羣的應用程序。負載均衡就是解決處理節點的選擇問題。 安裝HAProxy 選擇開源的HAProxy爲RabbitMQ集羣作負載均衡器,在CentOS 7.0中安裝HAProxy。 安裝epel
rpm -ivh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm//
安裝HAProxy
yum -y install haproxy
配置HAProxy
cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak
vim /etc/haproxy/haproxy.cfg
添加配置信息
listen rabbitmq_local_cluster 127.0.0.1:5670 //前段IP,供product和consumer來進行選擇,因爲5672端口已經默認使用,這裏選擇5670端口
mode tcp //負載均衡選項
balance roundrobin //輪詢算法將負載發給後臺服務器
server rabbit 127.0.0.1:5672 check inter 5000 rise 2 fall 3//負載均衡中的集羣節點配置,這裏選擇的rabbit節點
listen private_monitoring :8100
mode http
option httplog
stats enable
stats uri /stats
stats refresh 60s
```
訪問http://localhost:8100/stats就能夠看到具體的控制界面。
參考文獻:
http://rabbitmq-into-chinese.readthedocs.org/zh_CN/latest/
《RabbitMQ實戰-高效部署分佈式消息隊列》[美] Alvar Videla,Jason J.W. Williams 著 汪佳南 譯
https://geewu.gitbooks.io/rabbitmq-quick/content/
轉自:https://blog.csdn.net/woogeyu/article/details/51119101