RabbitMQ分佈式集群架構和高可用性（HA）


(一） 功能和原理

設計集群的目的
  • 允許消費者和生產者在RabbitMQ節點崩潰的情況下繼續運行
  • 通過增加更多的節點來擴展消息通信的吞吐量

1 集群配置方式

RabbitMQ可以通過三種方法來部署分佈式集群系統，分別是：cluster,federation,shovel
  • cluster:
    • 不支持跨網段，用於同一個網段內的局域網
    • 可以隨意的動態增加或者減少
    • 節點之間需要運行相同版本的RabbitMQ和Erlang
  • federation:應用於廣域網，允許單台服務器上的交換機或隊列接收發佈到另一台服務器上交換機或隊列的消息，可以是單獨機器或集群。federation隊列類似於單向點對點連接，消息會在聯盟隊列之間轉發任意次，直到被消費者接受。通常使用federation來連接internet上的中間服務器，用作訂閱分發消息或工作隊列。
  • shovel:連接方式與federation的連接方式類似，但它工作在更低層次。可以應用於廣域網。

2 節點類型

  • RAM node:內存節點將所有的隊列、交換機、綁定、用戶、權限和vhost的元數據定義存儲在內存中，好處是可以使得像交換機和隊列聲明等操作更加的快速。
  • Disk node:將元數據存儲在磁盤中，單節點系統只允許磁盤類型的節點，防止重啟RabbitMQ的時候，丟失系統的配置信息。
問題說明： RabbitMQ要求在集群中至少有一個磁盤節點，所有其他節點可以是內存節點，當節點加入或者離開集群時，必須要將該變更通知到至少一個磁盤節點。如果集群中唯一的一個磁盤節點崩潰的話，集群仍然可以保持運行，但是無法進行其他操作（增刪改查），直到節點恢復。
解決方案：設置兩個磁盤節點，至少有一個是可用的，可以保存元數據的更改。

3 Erlang Cookie

Erlang Cookie是保證不同節點可以相互通信的密鑰，要保證集群中的不同節點相互通信必須共享相同的Erlang Cookie。具體的目錄存放在/var/lib/rabbitmq/.erlang.cookie。
說明：這就要從rabbitmqctl命令的工作原理說起，RabbitMQ底層是通過Erlang架構來實現的，所以rabbitmqctl會啟動Erlang節點，並基於Erlang節點來使用Erlang系統連接RabbitMQ節點，在連接過程中需要正確的Erlang Cookie和節點名稱，Erlang節點通過交換Erlang Cookie以獲得認證。

4 鏡像隊列

功能和原理 RabbitMQ的Cluster集群模式一般分為兩種，普通模式和鏡像模式。
  • 普通模式：默認的集群模式，以兩個節點（rabbit01、rabbit02）為例來進行說明。對於Queue來說，消息實體只存在於其中一個節點rabbit01（或者rabbit02），rabbit01和rabbit02兩個節點僅有相同的元數據，即隊列的結構。當消息進入rabbit01節點的Queue後，consumer從rabbit02節點消費時，RabbitMQ會臨時在rabbit01、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連接的節點。

實例列舉：
1 
2

queue_args("x-ha-policy":"all") //定义字典来设置额外的队列声明参数
channel.queue_declare(queue="hello-queue",argument=queue_args)
如果需要設定特定的節點（以rabbit@localhost為例），再添加一個參數
1 
2 
3

queue_args("x-ha-policy":"nodes",
           "x-ha-policy-params":["rabbit@localhost"])
channel.queue_declare(queue="hello-queue",argument=queue_args)

可以通過命令行查看那個主節點進行了同步
1

rabbitmqctl list_queue name slave_pids synchronised_slave_pids

(二） RabbitMQ Cluster 配置

1 單機多節點部署

在啟動RabbitMQ節點之後，服務器默認的節點名稱是Rabbit和監聽端口5672，如果想在同一台機器上啟動多個節點，那麼其他的節點就會因為節點名稱和端口與默認的衝突而導致啟動失敗，可以通過設置環境變量來實現，具體方法如下：
  • 首先在機器上設置兩個節點rabbit和rabbit_01
1 
2 
3 
4 
5

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文件來進行設置：
1 
2 
3 
4

NODE_PORT=5672
NODENAME=rabbit
NODE_PORT=5673
NODENAME=rabbit_01
  • 將rabbit_01節點添加到第一個集群節點rabbit中
1 
2 
3 
4

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节点的应用
1 
2 
3 
4 
5 
6 
7

//可以看到如下信息，说明节点添加成功，表明都是磁盘类型的节点
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 192.168.118.133 DISK CentOS 7.0 - 64位
rabbitmqCluster01 192.168.118.134 DISK CentOS 7.0 - 64位
rabbitmqCluster02 192.168.118.135 DISK CentOS 7.0 - 64位



cluster部署過程：
  • 局域網配置 分別在三個節點的/etc/hosts下設置相同的配置信息
1 
2 
3

  192.168.118.133 rabbitmqCluster
  192.168.118.134 rabbitmqCluster01
  192.168.118.135 rabbitmqCluster02
  • 設置不同節點間同一認證的Erlang Cookie 採用從主節點copy的方式保持Cookie的一致性
1 
2

[root@rabbitmqCluster01]# scp /var/lib/rabbitmq/.erlang.cookie 192.168.118.134:/var/lib/rabbitmq
[root@rabbitmqCluster02]# scp /var/lib/rabbitmq/.erlang.cookie 192.168.118.135:/var/lib/rabbitmq
  • 使用-detached運行各節點
1 
2

rabbitmqctl stop
rabbitmq-server -detached
  • 查看各節點的狀態
1 
2 
3

[root@rabbitmqCluster]#rabbitmqctl cluster_status
[root@rabbitmqCluster01]#rabbitmqctl cluster_status
[root@rabbitmqCluster02]#rabbitmqctl cluster_status
  • 創建並部署集群，以rabbitmqCluster01節點為例：
1 
2 
3

[root@rabbitmqCluster01]#rabbitmqctl stop_app
[root@rabbitmqCluster01]#rabbitmqctl join_cluster rabbit@rabbitmqCluster
[root@rabbitmqCluster01]#rabbitmqctl start_app
  • 查看集群狀態
1

[root@rabbitmqCluster]#rabbitmqctl cluster_status

RabbitMQ負載均衡配置

前言：從目前來看，基於RabbitMQ的分佈式通信框架主要包括兩部分內容，一是要確保可用性和性能，另一個就是編寫當節點發生故障時知道如何重連到集群的應用程序。負載均衡就是解決處理節點的選擇問題。

安裝HAProxy

選擇開源的HAProxy為RabbitMQ集群做負載均衡器，在CentOS 7.0中安裝HAProxy。
  • 安裝epel
1

rpm -ivh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm//
  • 安裝HAProxy
1

yum -y install haproxy
  • 配置HAProxy
1 
2

cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak
vim /etc/haproxy/haproxy.cfg
  • 添加配置信息
1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11

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
  • 設置開機啟動
1 
2

chkconfig haproxy on
service haproxy start
  • 訪問localhost:8100/stats就可以看到具體的控制界面。

留言

張貼留言

這個網誌中的熱門文章

Json概述以及python對json的相關操作

圖片
什麼是json： JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。易於人閱讀和編寫。同時也易於機器解析和生成。它基於JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一個子集。JSON採用完全獨立於語言的文本格式，但是也使用了類似於C語言家族的習慣（包括C, C++, C#, Java, JavaScript, Perl, Python等）。這些特性使JSON成為理想的數據交換語言。 JSON建構於兩種結構： “名稱/值”對的集合（A collection of name/value pairs）。不同的語言中，它被理解為對象（object），紀錄（record），結構（struct），字典（dictionary），哈希表（hash table），有鍵列表（keyed list），或者關聯數組（associative array）。 值的有序列表（An ordered list of values）。在大部分語言中，它被理解為數組（array）。 這些都是常見的數據結構。事實上大部分現代計算機語言都以某種形式支持它們。這使得一種數據格式在同樣基於這些結構的編程語言之間交換成為可能。 jso官方說 ​​明參見：http://json.org/ Python操作json的標準api庫參考：http://docs.python.org/library/json.html 對簡單數據類型的encoding 和decoding： 使用簡單的json.dumps方法對簡單數據類型進行編碼，例如： import json obj = [[ 1 , 2 , 3 ], 123 , 123.123 , 'abc' ,{ 'key1' :( 1 , 2 , 3 ), 'key2' :( 4 , 5 , 6 )}] encodedjson = json.dumps(obj) print repr (obj) print encodedjson 輸出： [[1, 2, 3], 123, 123.123, 'abc', {'ke...
閱讀完整內容

Docker容器日誌查看與清理

1. 問題 docker容器日誌導致主機磁盤空間滿了。 docker logs -f container_name 劈裡啪啦一大堆，很佔用空間，不用的日誌可以清理掉了。  2. 解決方法 2.1 找出Docker容器日誌 在linux上，容器日誌一般存放在 /var/lib/docker/containers/container_id/ 下面，查看各個日誌文件大小的腳本docker_log_size.sh，內容如下： #!/bin/sh echo "======== docker containers logs file size ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs do ls -lh $log done # chmod +x docker_log_size.sh # ./docker_log_size.sh 2.2 清理Docker容器日誌（治標） 如果docker容器正在運行，那麼使用 rm -rf 方式刪除日誌後，通過 df -h 會發現磁盤空間並沒有釋放。 原因是在Linux或者Unix系統中，通過 rm -rf 或者文件管理器刪除文件，將會從文件系統的目錄結構上解除鏈接（unlink）。 如果文件是被打開的（有一個進程正在使用），那麼進程將仍然可以讀取該文件，磁盤空間也一直被佔用。 正確姿勢是 cat /dev/null > *-json.log ，當然你也可以通過 rm -rf 刪除後重啟docker。 接下來，提供一個日誌清理腳本 clean_docker_log.sh ，內容如下： #!/bin/sh echo "======== start clean docker containers logs ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs d...
閱讀完整內容

利用 Keepalived 提供 VIP

Keepalived 是一種基於 VRRP 協定實現的高可靠 Web 服務方案，用於防止單點故障問題。因此一個 Web 服務運作至少會擁有兩台伺服器執行 Keepalived，一台作為 master，一台作為 backup，並提供一個虛擬 IP（VIP），master 會定期發送特定訊息給 backup 伺服器，當 backup 沒收到 master 訊息時，表示 master 已故障，這時候 backup 會接管 VIP，繼續提供服務，來確保服務的高可靠性。 VRRP VRRP（Virtual Router Redundancy Protocol，虛擬路由器備援協定），是一個提供備援路由器來解決單點故障問題的協定，該協定有兩個重要概念： * VRRP 路由器與虛擬路由器：VRRP 路由器是表示運作 VRRP 的路由器，是一個實體裝置，而虛擬路由器是指由 VRRP 建立的邏輯路由器。一組 VRRP 路由器協同運作，並一起構成一台虛擬路由器，該虛擬路由對外提供一個唯一固定的 IP 與 MAC 位址的邏輯路由器。 * 主控制路由器（master）與備援路由器（backup）：主要是在一組 VRRP 中的兩種互斥角色。一個 VRRP 群組中只能擁有一台是 master，但可以有多個 backup 路由器。 VRRP 協定使用選擇策略從路由器群組挑選一台作為 master 來負責 ARP 與轉送 IP 封包，群組中其他路由器則作為 backup 的角色處理等待狀態。當由於某種原因造成 master 故障時，backup 會在幾秒內成為 master 繼續提供服務，該階段不用改變任何 IP 與 MAC 位址。 Keepalived 節點配置 IP ADDRESS ROLE 172.16.1.101 vip 172.16.1.102 master 172.16.1.103 backup 安裝與設定 這 ubuntu 14.04 LTS Server 中已經內建了 Keepalived 可以透過 apt-get 來安裝： $ sudo apt-get install -y keepalived 也可以透過 source code 進行安裝，流程如下： $ sudo apt-get install build-essential libssl-dev $ wge...
閱讀完整內容