高可用叢集架構
| 節點域名 |
作業系統 |
RabbitMQ版本 |
Erlang版本 |
| rabbitmq1.mfg.tp-link.com |
Centos7.9 |
3.8.28 |
23.3-2 |
| rabbitmq2.mfg.tp-link.com |
Centos7.9 |
3.8.28 |
23.3-2 |
| rabbitmq3.mfg.tp-link.com |
Centos7.9 |
3.8.28 |
23.3-2 |
目前Centos7.9透過直接RPM包部署安裝的版本最高支援到3.8.28，Erlang相應版本支援範圍為23.2到24.2，也透過RPM包安裝部署
壓力測試
測試方案
模式：使用者辦公電腦JAVA程式模擬生產者和和消費者
測試分類：高資訊大小（10KB）/正常業務模式資訊大小（200B）
測試連線地址：rabbitmqlb1.mfg.tp-link.com
測試埠：5672/tcp
結果統計來源：RabbitMQ UI元件資料統計，折線圖統計
壓力測試統計結果
| 訊息總數 |
訊息大小 |
峰值頻寬 |
生產者速率（平均） |
消費者速率（均值） |
消費者速率（峰值） |
節點記憶體平均佔用 |
| 594,112條 |
10KB |
71.2Mbps |
750條/s |
500條/s |
750條/s |
1.15G |
| 5,998,430條 |
200B |
13Mbps |
4144條/s |
11414條/s |
17052條/s |
1.2G |
腦裂測試
方案：RabbitMQ叢集三個幾點都安裝iptables防火牆（使用firewalld防火牆模擬腦裂失敗），25672為RabbitMQ叢集節點互動埠，二三節點關閉叢集互動埠25672，一節點開放所有需要的埠，透過RabbitMQ UI管理介面以及Zabbix RabbitMQ外掛告警來判斷腦裂是否模擬成功，叢集在搭建時已設定恢復策略為Autoheal，模擬正常業務場景下的訊息傳送，後回滾防火牆操作，觀察叢集恢復情況，檢視各節點日誌關於分割槽恢復的詳情
防火牆處理結果
節點1
[root@rabbitmq1-mfg sysconfig]# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:5672
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:4369
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25672
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
節點2
[root@rabbitmq2-mfg ~]# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25672
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:15672
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
節點3
[root@rabbitmq3-mfg ~]# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25672
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:15672
RabbitMQ UI管理介面腦裂顯示
叢集節點Autoheal自動恢復相關日誌
節點1
接收到了來自二節點的Autoheal請求，得知了一二節點是losers，三節點是Winner，同時也會收到Winner三節點的Autoheal請求，但此時這是第二個Autheal請求就會忽略（已處於自動恢復狀態中），一節點關閉自身Rabbitmq程序
節點2
二節點接收到了來自三節點的Autoheal重啟通知，會將通知傳遞給下一個需要重啟的節點一，然後自身關閉Rabbitmq程序
節點3
節點三在選舉中勝出成為Winner，會將Autoheal請求傳送到Rabbitmq一二節點，等待一二節點都關閉完後再讓一二節點依次重啟加入叢集
總結
初始叢集中，所有的映象佇列的master佇列都是由Rabbitmq1-mfg一節點對外提供服務，二三節點上的佇列為slave佇列同步一節點資料，在發生腦裂後恢復後，三節點的master升格為了master佇列，一二節點的佇列變為slave佇列進行資料同步，其中master佇列的選舉依靠多維度資料進行評判：客戶端連線數，剩餘磁碟量，節點負載等，在叢集發生腦裂的過程中，訊息傳送失敗率為0%，保證了業務的連續性，在非極端情況下，資料也能保證恢復後的一致性