---

前言

運維-集群介紹

多機多節點

RabbitMQ集群對延遲?常敏感, 所以搭建RabbitMQ集群時, 多個節點應當在同?個局域?內

單機多節點

只有?個虛擬機, 我們啟動N個節點, ?端?號來區分

單機多節點的?式, 也稱為"偽集群"

多機多節點

下載

準備三臺服務器，而且都在一個局域網內

然后三臺機器分別安裝Rabbitmq，版本最好保持一致

配置hosts?件

然后開始配置集群，配置hosts?件

這個就是節點名稱

配置每個節點的hosts?件, 讓各個節點都能互相識別對?

vim /etc/hosts

格式為: IP 主機名稱
?如我的集群配置如下:

10.0.0.232 iZ2vc7a1n9gvhfp589oav8Z
10.0.0.233 iZ2vc7a1n9gvhfp589oav6Z
10.0.0.234 iZ2vc7a1n9gvhfp589oav7Z

這個ip是內網ip
輸入
ifconfig

這個就是內網ip

more /etc/hostname

這個是查主機名稱

為什么用內網ip
因為在同一個局域網
然后開始修改host

vim /etc/hosts

然后就是每臺機器都是這樣改

配置Erlang Cookie

RabbitMQ 節點和 CLI ?具(如rabbitmqctl) 使?Cookie來進??份驗證, 確認它們之間是否被允許相
互通信. 為了使兩個節點可以通信, 它們必須具有相同的共享密鑰, 稱為 Erlang Cookie . Cookie是
?個字符串, 通常存儲在本地?件中. 每個集群節點必須具有相同的Cookie.
Cookie ?件的位置:
RabbitMQ啟動時, erlang 虛擬機會?動創建該?件, 通常位
于 /var/lib/rabbitmq/.erlang.cookie 和 $HOME/.erlang.cookie

先停?所有節點的服務

systemctl stop rabbitmq-server

在配置 Erlang Cookie

只需將?個節點上的 .erlang.cookie ?件分別拷?到另外兩個節點上就可以
?如把node3節點的?件, 分別拷?到node1和node2對應的機器上
在node3上進?如下操作

拷?node3節點的?件到node1
scp /var/lib/rabbitmq/.erlang.cookie root@iZ2vc7a1n9gvhfp589oav8Z:/var/lib/rabbitmq/
然后是輸入node1的密碼就可以了

拷?node3節點的?件到node2
scp /var/lib/rabbitmq/.erlang.cookie root@iZ2vc7a1n9gvhfp589oav6Z:/var/lib/rabbitmq/

然后是輸入node2的密碼就可以了

說白了就是同步erlang.cookie

啟動節點

以后端的?式啟動三臺RabbitMQ, 啟動命令
rabbitmq-server -detached

構建集群

為了將集群中的三個節點連接起來, 需要告訴另外兩個節點加?另?個節點, ?如node1和node2加?
node3節點.
加?node3之前, 必須重置兩個新加?的成員, 也就是node1和node2
分別在要加?的兩個機器上, 執?下?的操作命令：

#1. 關閉RabbitMQ服務
rabbitmqctl stop_app
#2. 重置當前節點
rabbitmqctl reset
#3.加?節點 后?跟的是node3節點
rabbitmqctl join_cluster rabbit@iZ2vc7a1n9gvhfp589oav7Z
#4. 啟動服務
rabbitmqctl start_app

rabbit@iZ2vc7a1n9gvhfp589oav7Z是節點名稱

查看集群狀態

rabbitmqctl cluster_status

這樣就可以都看到所有節點了

cluster搭建起來后, 如果在管理界?中, Nodes部分看到"Node statistics not available", 說明在該節點
上web管理插件還未啟?

解決辦法:
啟動 rabbitmq_management 插件即可
在顯?提?信息的節點上運? rabbitmq-plugins enable rabbitmq_management

單機多節點

安裝

啟動兩個節點

rabbitmqctl status #查看RabbitMQ狀態

端?號介紹:
? 25672這是Erlang分布式節點通信的默認端?, Erlang是RabbitMQ的底層通信協議.
? 15672這是 Web管理界?的默認端?, 通過這個端?可以訪問RabbitMQ的Web管理控制臺, ?于
查看和管理消息隊列.
? 5672這是 AMQP (Advanced Message Queuing Protocol) 協議的默認端?, ?于客?端與
RabbitMQ服務器之間的通信.

再啟動兩個節點

RABBITMQ_NODE_PORT=5673 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15673}]" RABBITMQ_NODENAME=rabbit2 rabbitmq-server -detachedRABBITMQ_NODE_PORT=5674 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15674}]" RABBITMQ_NODENAME=rabbit3 rabbitmq-server -detached

驗證RabbitMQ啟動成功

在云服務器開通 15673, 15674端?號

然后就是分別測試這些端口

搭建集群

停?服務并重置
停??的是為了重置

rabbitmqctl -n rabbit2 stop_app
rabbitmqctl -n rabbit2 reset
rabbitmqctl -n rabbit3 stop_app
rabbitmqctl -n rabbit3 reset

把rabbit2, rabbit3添加到集群

rabbit@hcss-ecs-6fa6

rabbitmqctl -n rabbit2 join_cluster rabbit@hcss-ecs-2618rabbitmqctl -n rabbit3 join_cluster rabbit@hcss-ecs-2618

這個報警就忽略掉

rabbit@hcss-ecs-2618是節點名稱，可以在管理界面看，也可以用命令rabbitmqctl status來查看
這樣就加入成功了

加入成功，但是沒有運行成功

重啟

rabbitmqctl -n rabbit2 start_app
rabbitmqctl -n rabbit3 start_app

查看集群狀態
rabbitmqctl cluster_status -n rabbit

宕機演示

我們添加隊列，選擇主節點

弄好集群之后，賬號都是共用的

而且虛擬機也是同步共用的

隊列也是會同步的

這里可以發送消息
然后所有節點都有這個消息的
說明數據都是同步的

如果一個機器宕機呢

我們直接關閉Rabbit節點

rabbitmqctl -n rabbit stop_app

集群少了一個機器了

消息也丟失了
因為這個消息就是在這個節點上的，這個節點關了，消息就丟失了，雖然消息同步

仲裁隊列介紹

每個隊列都有自己的主節點
每個隊列的消息就是放在自己對應的主節點上的，但是也會在從節點上顯示
主節點宕機了，對應隊列也完了
因為隊列是沒有復制的，所以主節點沒了，數據就沒了

RabbitMQ 的仲裁隊列是?種基于 Raft ?致性算法實現的持久化、復制的 FIFO 隊列. 仲裁隊列提供隊列復制的能?, 保障數據的?可?和安全性. 使?仲裁隊列可以在 RabbitMQ 節點間進?隊列數據的復制, 從?達到在?個節點宕機時, 隊列仍然可以提供服務的效果.
仲裁隊列官網

仲裁隊列是RabbitMQ 3.8版本最重要的改動. 他是鏡像隊列的替代?案. 在 RabbitMQ 3.8 版本問世之前, 鏡像隊列是實現數據?可?的唯??段, 但是它有?些設計上的缺陷, 這也是 RabbitMQ 提供仲裁隊列的原因. 經典鏡像隊列已被棄?，并計劃在將來版本中移除, 如果當前使?經典鏡像隊列的
RabbitMQ 安裝需要遷移, 可以參考官?提供的遷移指南
官網

raft算法協議

論文介紹
Raft 是?種?于管理和維護分布式系統?致性的協議, 它是?種共識算法, 旨在實現?可?性和數據的持久性**. Raft 通過在節點間復制數據來保證分布式系統中的?致性，即使在節點故障的情況下也能保證數據不會丟失.**
在分布式系統中, 為了消除單點提?系統可?性, 通常會使?副本來進?容錯, 但這會帶來另?個問題,即如何保證多個副本之間的?致性？副本就是從節點
共識算法（Consensus Algorithm）就是做這個事情的, 它允許多個分布式節點就某個值或?系列值達成?致性協議. 即使在?些節點發?故障, ?絡分區或其他問題的情況下, 共識算法也能保證系統的?致性和數據的可靠性.
常?的共識算法有: Paxos, Raft, Zab等
? Paxos: ?種經典的共識算法, ?于解決分布式系統中的?致性問題.
? Raft：?種較新的共識算法, Paxos 不易實現, raft是對Paxos算法的簡化和改進, 旨在易于理解和實
現.
? Zab：ZooKeeper 使?的共識算法, 基于 Paxos 算法., ?部分和Raft相同, 主要區別是對于Leader的
任期, Raft叫做term, Zab叫做epoch, 狀態復制的過程中, raft的?跳從Leader向Follower發送, ?
ZAB則相反.
? Gossip: Gossip算法每個節點都是對等的, 即沒有??之分. Gossip算法中的每個節點都會將數據改
動告訴其他節點（類似傳?卦）

raft基本概念

Raft 使? Quorum 機制來實現共識和容錯, 我們將對 Raft 集群的操作必須得到?多數(> N/2)節點的同意才能提交.
節點指的是分布式系統中的?個獨?成員
當我們向 Raft 集群發起?系列讀寫操作時, 集群內部究竟發?了什么呢? 我們先來簡單了解?下.
Raft 集群必須存在?個主節點(Leader), 客?端向集群發起的所有操作都必須經由主節點處理. 所以
Raft 核?算法中的第?部分就是選主(Leader election). 沒有主節點集群就?法?作, 先選出?個主節
點, 再考慮其它事情

主節點會負責接收客?端發過來的操作請求, 將操作包裝為?志同步給其它節點, 在保證?部分節點都同步了本次操作后, 就可以安全地給客?端回應響應了. 這?部分?作在 Raft 核?算法中叫?志復制(Log replication).
因為主節點的責任?常?, 所以只有符合條件的節點才可以當選主節點.
為了保證集群對外展現的?致性, 主節點在處理操作?志時, 也?定要謹慎, 這部分在Raft核?算法中叫 安全性(Safety).Raft算法將?致性問題分解為三個?問題: Leader選舉, ?志復制和安全性.
下?我們詳細介紹下Raft的選主過程.

選主

選主(Leader election)就是在集群中抉擇出?個主節點來負責?些特定的?作. 在執?了選主過程后, 集群中每個節點都會識別出?個特定的, 唯?的節點作為 leader.
節點??
在 Raft 算法中，每個節點都處于以下三種??之?
? Leader(領導者): 負責處理所有客?請求，并將這些請求作為?志項復制到所有 Follower. Leader
定期向所有 Follower 發送?跳消息, 以維持其領導者地位, 防? Follower 進?選舉過程.
? Follower(跟隨者): 接收來? Leader 的?志條?, 并在本地應?這些條?. 跟隨者不直接處理客?請
求.
? Candidate(候選者): 當跟隨者在?段時間內沒有收到來? Leader 的?跳消息時，它會變得不確定
Leader 是否仍然可?. 在這種情況下, 跟隨者會轉變??成為 Candidate, 并開始嘗試通過投票過程
成為新的 Leader

在正常情況下, 集群中只有?個 Leader, 剩下的節點都是 follower, 下圖展?了這些狀態和它們之間的轉換關系

可以看出所有節點在啟動時, 都是follow狀態, 在?段時間內如果沒有收到來?leader的?跳, 從
follower切換到candidate, 發起選舉. 如果收到多數派(majority)的投票(含??的?票) 則切換到
leader狀態. Leader?般會?直?作直到它發?異常為?

任期

Raft 將時間劃分成任意?度的任期(term). 每?段任期從?次選舉開始, 在這個時候會有?個或者多個candidate 嘗試去成為 leader. 在成功完成?次leaderelection之后,?個leader就會?直節管理集群直到任期結束. 在某些情況下, ?次選舉?法選出 leader, 這個時候這個任期會以沒有 leader ?結束(如下圖t3). 同時?個新的任期(包含?次新的選舉) 會很快重新開始

Term 更像是?個邏輯時鐘(logic clock)的作?, 有了它，就可以發現哪些節點的狀態已經過期. 每?個節點都保存?個 current term, 在通信時帶上這個 term的值.
每?個節點都存儲著?個當前任期號(current term number). 該任期號會隨著時間單調遞增. 節點之間通信的時候會交換當前任期號, 如果?個節點的當前任期號?其他節點?, 那么它就將??的任期號更新為較?的那個值. 如果?個 candidate 或者 leader 發現??的任期號過期了, 它就會?刻回到
follower 狀態. 如果?個節點接收了?個帶著過期的任期號的請求, 那么它會拒絕這次請求.
Raft 算法中服務器節點之間采? RPC 進?通信, 主要有兩類 RPC 請求:
? RequestVote RPCs: 請求投票, 由 candidate 在選舉過程中發出
? AppendEntries RPCs: 追加條?, 由 leader 發出, ?來做?志復制和提供?跳機制

raft選取過程

Raft 采??種?跳機制來觸發 leader 選舉, 當服務器啟動的時候, 都是follow狀態. 如果follower在
election timeout內沒有收到來?leader的?跳(可能沒有選出leader, 也可能leader掛了, 或者leader與
follower之間?絡故障), 則會主動發起選舉

步驟如下:

1. 率先超時的節點, ?增當前任期號然后切換為 candidate 狀態, 并投???票
2. 以并?的?式發送?個 RequestVote RPCs 給集群中的其他服務器節點（企圖得到它們的投票）
3. 等待其他節點的回復

在這個過程中, 可能出現三種結果
a. 贏得選舉, 成為Leader(包括??的?票)
b. 其他節點贏得了選舉, 它??切換到follower
c. ?段時間內沒有收到majority投票, 保持candidate狀態, 重新發出選舉

投票要求:
? 每?個服務器節點會按照 先來先服務原則(first-come-first-served)只投給?個 candidate.
? 候選?知道的信息不能???的少

接下來對這三種情況進?說明:
第?種情況: 贏得了選舉之后, 新的leader會?刻給所有節點發消息, ??告之, 避免其余節點觸發新的選舉

第?種情況: ?如有三個節點A B C, A B同時發起選舉, ?A的選舉消息先到達C, C給A投了?票, 當B的消息到達C時, 已經不能滿?上?提到的第?個約束, 即C不會給B投票, 這時候A就勝出了. A勝出之后, 會給B,C發?跳消息, 節點B發現節點A的term不低于??的term, 知道有已經有Leader了, 于是把??轉換成follower.

第三種情況: 沒有任何節點獲得majority投票. ?如所有的 follower 同時變成 candidate, 然后它們都將
票投給??, 那這樣就沒有 candidate 能得到超過半數的投票了. 當這種情況發?的時候, 每個
candidate 都會進??次超時響應, 然后通過?增任期號來開啟?輪新的選舉, 并啟動另?輪的
RequestVote RPCs. 如果沒有額外的措施, 這種?結果的投票可能會?限重復下去

為了解決上述問題，Raft 采? 隨機選舉超時時間（randomized election timeouts） 來確保很少產?
?結果的投票，并且就算發?了也能很快地解決。為了防?選票?開始就被?分，選舉超時時間是從?個固定的區間（?如，150-300ms）中隨機選擇。這樣可以把服務器分散開來以確保在?多數情況下會只有?個服務器率先結束超時，那么這個時候，它就可以贏得選舉并在其他服務器結束超時之前發送?跳

Raft 動畫演?在線地址

消息復制

每個仲裁隊列都有多個副本, 它包含?個主和多個從副本. replication factor 為 5的仲裁隊列將會有 1個主副本和 4 個從副本. 每個副本都在不同的 RabbitMQ 節點上
客?端(?產者和消費者)只會與主副本進?交互, 主副本再將這些命令復制到從副本. 當主副本所在的節點下線, 其中?個從副本會被選舉成為主副本, 繼續提供服務.

消息復制和主副本選舉的操作, 需要超過半數的副本同意. 當?產者發送?條消息, 需要超過半數的隊列副本都將消息寫?磁盤以后才會向?產者進?確認, 這意味著少部分?較慢的副本不會影響整個隊列的性能.

仲裁隊列使用與演示

@Bean("quorumQueue")
public Queue quorumQueue() {return QueueBuilder.durable("quorum.queue").quorum().build();
}

這個類型也是仲裁隊列的意思
創建時選擇Type為Quorum, 指定主副本

這里端口號隨便寫一個，記得開通

然后是發送消息

聲明就是多了一個quorm而已

+2的意思就是有兩個副本

leader是rabbit3，這個是因為我們配置的優先是rabbit3

還顯示了在線成員

這個創建仲裁隊列，node就是選擇主節點，記得在有權限的虛擬機上操作

可以看到這個隊列的主節點就是rabbit2了

然后發送消息都是會同步的，而且主節點宕機了也不會有事

我們把rabbit3停了

可以看出，選主了，主節點變成rabbiti了

然后重啟rabbit3

但是rabbit不是主節點了現在

可以看到, 仲裁隊列后?有?個 + 2 字樣, 代表這個隊列有2個鏡像節點.
仲裁隊列默認的鏡像數為5, 即?個主節點, 4個從副本節點.
如果集群中節點數量少于 5, ?如我們搭建了3個節點的集群, 那么創建的仲裁隊列就是 1 主 2 從.
如果集群中的節點數?于 5 個的話, 那么就只會在 5 個節點中創建出 1主 4 從

意思就是七個節點也是1主 4 從

HAProxy安裝

我們這個項目的缺點就是5674宕機了，就運行不了了

怎么辦呢
雖然集群沒有問題，但是程序有問題了
有兩個問題
1.如果我們訪問的是node1, 但是node1掛了, 咱們的程序也會出現問題, 所以最好是有?個統?的?
?, ?個節點故障時, 流量可以及時轉移到其他節點.
2. 如果所有的客?端都與node1建議連接, 那么node1的?絡負載必然會??增加, ?其他節點?由于
沒有那么多的負載?造成硬件資源的浪費

這時候要負載均衡了

引?負載均衡之后, 各個客?端的連接可以通過負載均衡分攤到集群的各個節點之中, 從?避免前?的問題.

這?主要討論的是如何有效地對RabbitMQ集群使?軟件負載均衡技術,?前主流的?式有在客?端內
部實現負載均衡,或者使?HAProxy、LVS等負載均衡有軟件來實現. 咱們這?講?下使?HAProxy來實現負載均衡.

負載均衡不是平均分配
接下來我們來安裝HAProxy, 實現負載均衡.
HAProxy（High Availability Proxy）是?個開源的負載均衡器和TCP/HTTP應?程序的代理服務器, 它被設計?來提供?可?性, 負載均衡和代理功能. HAProxy主要?于分發?絡流量到多個后端服務器, 以提??絡的可靠性和性能

安裝

#更新軟件包
sudo apt-get update
#查找haproxy
sudo apt list|grep haproxy
#安裝haproxy
sudo apt-get install haproxy

驗證安裝

#查看服務狀態
sudo systemctl status haproxy
#查看版本
haproxy -v 
#如果要設置HAProxy服務開機?啟，可以使?：
sudo systemctl enable haproxy

修改haproxy.cfg

就是怎么分發

vim /etc/haproxy/haproxy.cfg

# haproxy web 管理界面
listen statsbind *:8100       mode httpstats enablestats realm Haproxy\ Statistics    stats uri /stats auth admin:admin
# 配置負載均衡
listen rabbitmqbind *:5670mode tcpbalance roundrobinserver  rabbitmq1 127.0.0.1:5672  check inter 5000 rise 2 fall 3server  rabbitmq2 127.0.0.1:5673  check inter 5000 rise 2 fall 3server  rabbitmq3 127.0.0.1:5674  check inter 5000 rise 2 fall 3

# haproxy web 管理界?---》瀏覽器要訪問的
listen stats #設置?個監聽器, 統計HAProxy的統計信息bind *:8100 #指定了監聽器綁定到的IP地址和端?mode http #監聽器的?作模式為HTTPstats enable #啟?統計??stats realm Haproxy\ Statisticsstats uri /stats auth admin:admin #haproxy登錄賬號和密碼
# 配置負載均衡
listen rabbitmq #設置監聽器bind *:5670 #監聽器綁定到的IP地址和端?, 也就是集群前端IP, 供producer和consumer來進?選擇，由于5672端?已經默認使?, 這?選擇5670端?mode tcp #由于RabbitMQ使?AMQP協議，它是?個基于TCP的協議，所以這?使?TCP模
式balance roundrobin #指定負載均衡策略為輪詢#負載均衡中的集群節點配置，這?選擇的rabbit節點server rabbitmq1 127.0.0.1:5672 check inter 5000 rise 2 fall 3server rabbitmq2 127.0.0.1:5673 check inter 5000 rise 2 fall 3server rabbitmq3 127.0.0.1:5674 check inter 5000 rise 2 fall 3

rabbitmq3是給haproxy 用的，不是節點名稱
還有bind *:8100的8100和 bind *:5670的5670可以換的
check inter 5000 rise 2 fall 3是健康檢查，就是每隔五秒鐘檢查一次，檢查五次，但是不會放棄這個節點的

還需要開通8100和5670端口號

然后復制到vim /etc/haproxy/haproxy.cfg這個里面
拼接進去

重啟haproxy

sudo systemctl restart haproxy

查看HAProxy

http://124.71.229.73:8100/

rabbit3就是一個停掉的狀態


這樣就變好了

HAProxy使用

這里改成5670就可以了

配置的5670是HAProxy的一個端口號

發現成功發送了
現在把rabbit節點停掉



繼續發送消息

發現還是可以發送的
說明有一個節點宕機不影響HAProxy的使用，不影響集群的使用，不影響程序的使用
如何HAProxy掛了呢
那么所有都訪問不了了
因為配置的端口就是HAProxy的-

如果HAProxy主機突然宕機或者?卡失效,那么雖然RabbitMQ集群沒有任何故障, 但是對于外界的客
?端來說所有的連接都會被斷開,結果將是災難性的. 確保負載均衡服務的可靠性同樣顯得?分重要.
通常情況下, 會使?Keepalived 等?可?解決?案對haproxy做主備, 在HAProxy主節點故障時?動
將流量轉移到備?節點

總結