RabbitMQ (十五) 映象叢集 + HAProxy1.7.8 負載均衡
RabbitMQ 預設的叢集模式,也就是普通模式,最大的問題就在於儲存佇列完整資料的節點一旦宕機,
如果是非持久化佇列,則訊息丟失;如果是持久化佇列+持久化訊息,則必須等該節點恢復.
所以後來 RabbitMQ 開始支援佇列(完整資料)複製.比如在有5個節點的叢集裡,可以指定某個佇列的完整資料在2個節點上進行儲存,從而在效能與高可用之間取得一個平衡,這就是映象模式,它屬於 RabbitMQ 的HA方案.
映象模式解決了普通模式的問題,訊息實體會主動在映象節點間同步,而不是在消費者獲取資料的時候臨時從其他節點拉取.當然,該模式的副作用也很明顯:
- 訊息需要複製到每一個節點,對於持久化訊息,網路和磁碟同步複製的開銷都會明顯增加;
- 如果映象佇列數量過多,大量的訊息進入,叢集內部的網路頻寬將會被這種同步通訊大大消耗掉.
所以映象模式適合在對可靠性要求較高的場合中使用.
綜上所述,映象模式的實質是映象佇列,一個佇列想做成映象佇列,需要先設定 policy,然後客戶端建立佇列的時候,RabbitMQ 叢集根據“佇列名稱”自動設定是普通叢集模式或映象模式.
下面我們通過管理後臺將前面搭建的單機叢集模式修改成映象模式.
搭建步驟
第一步
第二步
- Virtual host : 虛擬主機.
- Name : 策略名稱.
- Pattern : ^表示匹配所有佇列名稱.
- Apply to : 這裡選擇的是同時應用到交換機和佇列.
- ha-mode 和 ha-params 見下表(原貼:http://www.ywnds.com/?p=4741)
然後我們可以看到,該虛擬主機下面的交換機和佇列都被打上了 test_mirror 標籤
+1 表示有1個映象節點.
進入該佇列詳情,可以清晰的看到 : 策略名稱,佇列的主節點以及映象節點等.
驗證功能
將就上一篇普通叢集的程式碼.
1.生產者連線到 node1 (5672) 傳送訊息,然後關閉 node1.
通過 node2 的管理後臺可以看到佇列依然在.
但是有個細節,Node 從 rabbit1@node1 變成了 rabbit2@node2.
進入該佇列詳情,主節點已經變成了rabbit2@node2 , 而映象節點是空.
2.消費者連線到 node2 接收訊息
一切正常.
3.重新啟動 node1
可以看到,佇列的主節點沒有還原回去.
關於HA sync mode,HA mirror promotion on shutdown,HA mirror promotion on failure 的測試
一.HA sync mode
該引數有兩個值:
- manual :手動模式(預設值)
- automatic : 自動模式
手動模式下,新加入的節點不會同步老節點的佇列(及訊息).測試如下:
1.我們先往"test_queue"佇列新增10條訊息.
2.新增節點 node3
3.這時候我們再看管理後臺,多了1個紅色的"+1",這個"+1"表示有一個節點沒有同步該佇列的資料.
我們進入該佇列檢視詳情:
可以看到,有個"同步"的按鈕.我們可以手動同步.
如果我們把10條訊息消費掉後,系統也會認為資料同步了,因為3個節點的資料一樣了.這時候紅色的"+1"就會消失,而之前的藍色"+1"變成了"+2".
自動模式的測試結果就不上圖了.
二.HA mirror promotion on failure
該引數有兩個值 :
when-syncedalways (預設值)
預設值為 "always" ,如果佇列主節點發生故障,斷開連線或者從群集中刪除了,則最早的映象節點將被提升為新的主節點.但是在某些情況下,此映象節點可能沒有同步資料,這將導致資料丟失.
"when-synced" ,意味著當佇列主節點發生故障的時候,佇列將變得不可用,直到主節點恢復.如果佇列主節點永久丟失,除非將佇列刪除(同時會刪除其所有內容)並重新宣告,否則該佇列將永不可用;
這相當於通過降低安全性(將非同步映象節點升級為主節點),從而增加對佇列主機可用性的依賴,因為有時候佇列可用性比資料一致性更重要.
三.HA mirror promotion on shutdown
該引數也有兩個值 :
when-synced(預設值)always
該引數的預設值為 "when-synced", 如果佇列主節點關閉了(即顯式停止RabbitMQ服務或關閉作業系統),那麼所有節點上的該佇列都將關閉.
"always" 意味著如果佇列主節點關閉了,可以提升一個未同步的節點為新的主節點,以避免資料丟失.
但是,如果HA mirror promotion on failure 的值為 "when-synced" ,即使HA mirror promotion on shutdown 的值為 "always" ,也不會提升未同步的節點.這意味著如果佇列主節點發生故障,佇列將在主節點恢復之前變為不可用.如果佇列主機永久丟失,除非將佇列刪除（也將刪除其所有內容）並重新宣告,否則該佇列將不可用.
測試
1.刪除之前建立的 node2,node3,只保留 node1;
2.刪除原來的策略,重新建了一個,並且HA sync mode ,HA mirror promotion on failure 和HA mirror promotion on shutdown 3個引數都未設定,即都使用預設值;
3.傳送10條訊息;
4.新建 node2,並加入叢集.
目前該佇列情況如下:node1 是佇列主節點,並且 node2 尚未同步資料.
5.停止 node1, 即停止佇列主節點 (rabbitmqctl stop_app )
這時候,該佇列變成了不可用,連線 node2 傳送訊息,接收訊息都會失敗.
這個結果符合 HA sync mode ,HA mirror promotion on failure 和HA mirror promotion on shutdown 3個引數預設值的預期.
6.恢復 node1 ( rabbitmqctl start_app ),進入該佇列詳情,點選按鈕,手動同步一下佇列資料,這時候,兩個節點的狀態是:node1 為佇列主節點,node2 已同步資料
7.再次關閉 node1.
從管理後臺可以看見,該佇列依然可用,並且 node2 被提升成了佇列主節點.同樣符合HA mirror promotion on failure 和HA mirror promotion on shutdown 預設值的預期.
至於將HA mirror promotion on shutdown 設為 "always",HA mirror promotion on failure 設為 "when-synced" 的情況就不再測試了.
記憶體及硬碟控制(轉載)
一.記憶體控制
vm_memory_high_watermark 該值為記憶體閾值,預設為0.4.意思為實體記憶體的40%.40%的記憶體並不是記憶體的最大的限制,它是一個釋出的節制,當達到40%時Erlang會做GC.最壞的情況是使用記憶體80%.如果把該值配置為0.將關閉所有的publishing.
Paging 記憶體閾值,該值為預設為0.5,該值為 vm_memory_high_watermark 的20%時,將把記憶體資料寫到磁碟.
如機器記憶體16G,當 RabbitMQ佔用記憶體1.28G（16*0.4*0.2）時會把記憶體資料放到磁碟.
二.硬碟控制
當RabbitMQ的磁碟空閒空間小於50M（預設）,生產者將被BLOCK.如果採用叢集模式,磁碟節點空閒空間小於50M將導致其他節點的生產者都被block,可以通過 disk_free_limit 來對進行配置.
原貼:http://www.ywnds.com/?p=4741
HAProxy1.7.8 負載均衡
在某網站下載了一個 window 可以用的版本 haproxy-1.7.8
修改haproxy.cfg 配置檔案
global
maxconn 15000
nbproc 1
daemon
defaults
mode tcp
retries 3
option abortonclose
maxconn 2000
timeout connect 300000ms
timeout client 300000ms
timeout server 300000ms
log 192.168.1.5 local0 err
listen RabbitMQ
bind 192.168.1.5:8848
mode http
balance roundrobin
server node1 192.168.1.5:5672 weight 1 maxconn 2000 check inter 5s rise 1 fall 3
server node2 192.168.1.5:5673 weight 1 maxconn 2000 check inter 5s rise 1 fall 3
listen status
bind 192.168.1.5:1188
mode http
stats refresh 30s
stats uri /
stats auth admin:admin
#stats hide-version
stats admin if TRUE