1. 單機(jī)多節(jié)點(diǎn)

1.1 搭建RabbitMQ?

①安裝RabbitMQ

略?

②確認(rèn)RabbitMQ運(yùn)?沒(méi)問(wèn)題

#查看RabbitMQ狀態(tài)

?rabbitmqctl status

?

?

節(jié)點(diǎn)名稱:

?

端口號(hào):

• 25672:Erlang分布式節(jié)點(diǎn)通信的默認(rèn)端?, Erlang是RabbitMQ的底層通信協(xié)議.
• 15672:?Web管理界?的默認(rèn)端?, 通過(guò)這個(gè)端?可以訪問(wèn)RabbitMQ的Web管理控制臺(tái), ?于查看和管理消息隊(duì)列
• 5672:?AMQP 協(xié)議的默認(rèn)端?, ?于客?端與 RabbitMQ服務(wù)器之間的通信.

③再啟動(dòng)兩個(gè)節(jié)點(diǎn)

?

啟動(dòng)命令:

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

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

④驗(yàn)證RabbitMQ啟動(dòng)成功

在云服務(wù)器開(kāi)通 15673, 15674端?號(hào):

分別測(cè)試:

119.91.154.99:15673/

119.91.154.99:15674/

?

1.2 搭建集群

①停?服務(wù)并重置

rabbitmqctl -n rabbit2 stop_app

rabbitmqctl -n rabbit2 reset

rabbitmqctl -n rabbit3?stop_app

rabbitmqctl -n rabbit3?reset

運(yùn)行結(jié)果:

?

②把rabbit2, rabbit3添加到集群

rabbit@localhost是主節(jié)點(diǎn)的node Name?

rabbitmqctl -n rabbit2 join_cluster rabbit@localhost

rabbitmqctl -n rabbit3?join_cluster rabbit@localhost

③重啟rabbit2,rabbit3

rabbitmqctl -n rabbit2 start_app

rabbitmqctl -n rabbit3?start_app?

?

④查看集群狀態(tài)

?rabbitmqctl cluster_status -n rabbit

?

通過(guò)主節(jié)點(diǎn)(rabbit)管理界?, 可以看到集群其他節(jié)點(diǎn):

2. 宕機(jī)演示

2.1 添加隊(duì)列

添加bit虛擬機(jī),其它節(jié)點(diǎn)也有了這個(gè)虛擬機(jī)

在bit虛擬機(jī)中添加隊(duì)列:

2.2 添加之后,可以看到三個(gè)節(jié)點(diǎn)都有隊(duì)列了

?

2.3 往testQueue隊(duì)列中發(fā)送?條數(shù)據(jù)(從任?節(jié)點(diǎn)都可以)

?

發(fā)送之后, 觀察3個(gè)節(jié)點(diǎn)的隊(duì)列中均有消息:

2.4 關(guān)閉主節(jié)點(diǎn)

?

關(guān)閉后可以看到rabbit2和rabbit3沒(méi)有該隊(duì)列的數(shù)據(jù)了

?

也就是說(shuō), 這個(gè)數(shù)據(jù)只在主節(jié)點(diǎn)存在, 從節(jié)點(diǎn)沒(méi)有?

如何解決這個(gè)問(wèn)題呢, 就需要引?"仲裁隊(duì)列"

3. 仲裁隊(duì)列(Quorum Queues)

RabbitMQ 的仲裁隊(duì)列是?種基于 Raft ?致性算法實(shí)現(xiàn)的持久化、復(fù)制的 FIFO 隊(duì)列. 仲裁隊(duì)列提供隊(duì)列復(fù)制的能?, 保障數(shù)據(jù)的?可?和安全性.

使?仲裁隊(duì)列可以在 RabbitMQ 節(jié)點(diǎn)間進(jìn)?隊(duì)列數(shù)據(jù)的復(fù)制, 從?達(dá)到在?個(gè)節(jié)點(diǎn)宕機(jī)時(shí), 隊(duì)列仍然可以提供服務(wù)的效果?

3.1 Raft協(xié)議介紹

Raft 是?種?于管理和維護(hù)分布式系統(tǒng)?致性的協(xié)議, 它是?種共識(shí)算法, 旨在實(shí)現(xiàn)?可?性和數(shù)據(jù)的 持久性. Raft 通過(guò)在節(jié)點(diǎn)間復(fù)制數(shù)據(jù)來(lái)保證分布式系統(tǒng)中的?致性，即使在節(jié)點(diǎn)故障的情況下也能保證數(shù)據(jù)不會(huì)丟失.

在分布式系統(tǒng)中, 為了消除單點(diǎn)提?系統(tǒng)可?性, 通常會(huì)使?副本來(lái)進(jìn)?容錯(cuò), 但這會(huì)帶來(lái)另?個(gè)問(wèn)題, 即如何保證多個(gè)副本之間的?致性？

共識(shí)算法就是做這個(gè)事情的, 它允許多個(gè)分布式節(jié)點(diǎn)就某個(gè)值或?系列值達(dá)成?致性協(xié)議. 即使在?些節(jié)點(diǎn)發(fā)?故障, ?絡(luò)分區(qū)或其他問(wèn)題的情況下, 共識(shí)算法也能保證系統(tǒng)的?致性和數(shù)據(jù)的可靠性.

常?的共識(shí)算法有: Paxos, Raft, Zab等,此處用Raft算法

3.2 Raft 基本概念

Raft 使? Quorum 機(jī)制來(lái)實(shí)現(xiàn)共識(shí)和容錯(cuò), 我們將對(duì) Raft 集群的操作必須得到?多數(shù)(> N/2)節(jié)點(diǎn)的同意才能提交.?

Raft 集群必須存在?個(gè)主節(jié)點(diǎn)(Leader), 客?端向集群發(fā)起的所有操作都必須經(jīng)由主節(jié)點(diǎn)處理. 所以 Raft 核?算法中的第?部分就是選主(Leader election). 沒(méi)有主節(jié)點(diǎn)集群就?法?作, 先選出?個(gè)主節(jié)點(diǎn), 再考慮其它事情

主節(jié)點(diǎn)會(huì)負(fù)責(zé)接收客?端發(fā)過(guò)來(lái)的操作請(qǐng)求, 將操作包裝為?志同步給其它節(jié)點(diǎn), 在保證?部分節(jié)點(diǎn)都 同步了本次操作后, 就可以安全地給客?端回應(yīng)響應(yīng)了. 這?部分?作在 Raft 核?算法中叫?志復(fù)制 (Log replication).

因?yàn)橹鞴?jié)點(diǎn)的責(zé)任?常?, 所以只有符合條件的節(jié)點(diǎn)才可以當(dāng)選主節(jié)點(diǎn). 為了保證集群對(duì)外展現(xiàn)的?致 , 主節(jié)點(diǎn)在處理操作?志時(shí), 也?定要謹(jǐn)慎, 這部分在Raft核?算法中叫安全性(Safety).

Raft算法將?致性問(wèn)題分解為三個(gè)?問(wèn)題: Leader選舉, ?志復(fù)制和安全性.

---

選主(Leader election)

?選主(Leader election)就是在集群中抉擇出?個(gè)主節(jié)點(diǎn)來(lái)負(fù)責(zé)?些特定的?作.

在執(zhí)?了選主過(guò)程后, 集群中每個(gè)節(jié)點(diǎn)都會(huì)識(shí)別出?個(gè)特定的, 唯?的節(jié)點(diǎn)作為 leader

角色

• Leader(領(lǐng)導(dǎo)者): 負(fù)責(zé)處理所有客?請(qǐng)求，并將這些請(qǐng)求作為?志項(xiàng)復(fù)制到所有 Follower. Leader 定期向所有 Follower 發(fā)送?跳消息, 以維持其領(lǐng)導(dǎo)者地位, 防? Follower 進(jìn)?選舉過(guò)程.?
• Follower(跟隨者): 接收來(lái)? Leader 的?志條?, 并在本地應(yīng)?這些條?. 跟隨者不直接處理客?請(qǐng)求.?
• Candidate(候選者): 當(dāng)跟隨者在?段時(shí)間內(nèi)沒(méi)有收到來(lái)? Leader 的?跳消息時(shí)，它會(huì)變得不確定 Leader 是否仍然可?. 在這種情況下, 跟隨者會(huì)轉(zhuǎn)變??成為 Candidate, 并開(kāi)始嘗試通過(guò)投票過(guò)程成為新的 Leader.

在正常情況下, 集群中只有?個(gè) Leader, 剩下的節(jié)點(diǎn)都是 follower.

所有節(jié)點(diǎn)在啟動(dòng)時(shí), 都是follow狀態(tài), 在?段時(shí)間內(nèi)如果沒(méi)有收到來(lái)?leader的?跳, 從 follower切換到candidate, 發(fā)起選舉. 如果收到多數(shù)派(majority)的投票(含??的?票) 則切換到 leader狀態(tài). Leader?般會(huì)?直?作直到它發(fā)?異常為?.

---

任期

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

Term 更像是?個(gè)邏輯時(shí)鐘(logic clock)的作?, 有了它，就可以發(fā)現(xiàn)哪些節(jié)點(diǎn)的狀態(tài)已經(jīng)過(guò)期. 每?個(gè)節(jié)點(diǎn)都保存?個(gè) current term, 在通信時(shí)帶上這個(gè) term的值.

每?個(gè)節(jié)點(diǎn)都存儲(chǔ)著?個(gè)當(dāng)前任期號(hào)(current term number). 該任期號(hào)會(huì)隨著時(shí)間單調(diào)遞增. 節(jié)點(diǎn)之間通信的時(shí)候會(huì)交換當(dāng)前任期號(hào), 如果?個(gè)節(jié)點(diǎn)的當(dāng)前任期號(hào)?其他節(jié)點(diǎn)?, 那么它就將??的任期號(hào)更新為較?的那個(gè)值. 如果?個(gè) candidate 或者 leader 發(fā)現(xiàn)??的任期號(hào)過(guò)期了, 它就會(huì)?刻回到 follower 狀態(tài). 如果?個(gè)節(jié)點(diǎn)接收了?個(gè)帶著過(guò)期的任期號(hào)的請(qǐng)求, 那么它會(huì)拒絕這次請(qǐng)求.

Raft 算法中服務(wù)器節(jié)點(diǎn)之間采? RPC 進(jìn)?通信, 主要有兩類 RPC 請(qǐng)求:

• RequestVote RPCs: 請(qǐng)求投票, 由 candidate 在選舉過(guò)程中發(fā)出
• AppendEntries RPCs: 追加條?, 由 leader 發(fā)出, ?來(lái)做?志復(fù)制和提供?跳機(jī)制

---

選舉過(guò)程?

Raft 動(dòng)畫(huà)演?官方在線地址: https://raft.github.io/??

Raft 采??種?跳機(jī)制來(lái)觸發(fā) leader 選舉, 當(dāng)服務(wù)器啟動(dòng)的時(shí)候, 都是follow狀態(tài). 如果follower在 election timeout內(nèi)沒(méi)有收到來(lái)?leader的?跳(可能沒(méi)有選出leader, 也可能leader掛了, 或者leader與 follower之間?絡(luò)故障), 則會(huì)主動(dòng)發(fā)起選舉

所有節(jié)點(diǎn)均為follow狀態(tài):

步驟如下:

• 率先超時(shí)的節(jié)點(diǎn), ?增當(dāng)前任期號(hào)然后切換為 candidate 狀態(tài), 并投???票
• 以并?的?式發(fā)送?個(gè) RequestVote RPCs 給集群中的其他服務(wù)器節(jié)點(diǎn)（企圖得到它們的投票）
• 等待其他節(jié)點(diǎn)的回復(fù)

S1節(jié)點(diǎn)率先超時(shí),把任期號(hào)改為2,切換為candidate 狀態(tài), 并投???票:

在這個(gè)過(guò)程中, 可能出現(xiàn)三種結(jié)果

• 贏得選舉, 成為L(zhǎng)eader(包括??的?票)?
• 其他節(jié)點(diǎn)贏得了選舉, 它??切換到follower?
• ?段時(shí)間內(nèi)沒(méi)有收到majority投票, 保持candidate狀態(tài), 重新發(fā)出選舉

投票要求:

• 每?個(gè)服務(wù)器節(jié)點(diǎn)會(huì)按照 先來(lái)先服務(wù)原則(first-come-first-served)只投給?個(gè) candidate.
• 候選人知道的信息不能比自己少

---

接下來(lái)對(duì)這三種情況進(jìn)?說(shuō)明:

①贏得了選舉之后, 新的leader會(huì)?刻給所有節(jié)點(diǎn)發(fā)消息, ??告之, 避免其余節(jié)點(diǎn)觸發(fā)新的選舉.

②?如有三個(gè)節(jié)點(diǎn)A B C, A B同時(shí)發(fā)起選舉, ?A的選舉消息先到達(dá)C, C給A投了?票, 當(dāng)B的消息到達(dá)C時(shí), 已經(jīng)不能滿?上?提到的第?個(gè)約束, 即C不會(huì)給B投票, 這時(shí)候A就勝出了. A勝出之后, 會(huì)給 B,C發(fā)?跳消息, 節(jié)點(diǎn)B發(fā)現(xiàn)節(jié)點(diǎn)A的term不低于??的term, 知道有已經(jīng)有Leader了, 于是把??轉(zhuǎn)換成follower.

S5收到S1的心跳消息,發(fā)現(xiàn)S1的term不低于自己,知道有l(wèi)eader了,把自己切換為follower:

③沒(méi)有任何節(jié)點(diǎn)獲得majority投票. ?如所有的 follower 同時(shí)變成 candidate, 然后它們都將票投給??, 那這樣就沒(méi)有 candidate 能得到超過(guò)半數(shù)的投票了. 當(dāng)這種情況發(fā)?的時(shí)候, 每個(gè) candidate 都會(huì)進(jìn)??次超時(shí)響應(yīng), 然后通過(guò)?增任期號(hào)來(lái)開(kāi)啟?輪新的選舉, 并啟動(dòng)另?輪的 RequestVote RPCs. 如果沒(méi)有額外的措施, 這種?結(jié)果的投票可能會(huì)?限重復(fù)下去

注意:

為了解決上述問(wèn)題，Raft 采?隨機(jī)選舉超時(shí)時(shí)間來(lái)確保很少產(chǎn)??結(jié)果的投票，并且就算發(fā)?了也能很快地解決。

為了防?選票?開(kāi)始就被?分，選舉超時(shí)時(shí)間是從?個(gè)固定的區(qū)間（?如，150-300ms）中隨機(jī)選擇。這樣可以把服務(wù)器分散開(kāi)來(lái)以確保在?多數(shù)情況下會(huì)只有?個(gè)服務(wù)器率先結(jié)束超時(shí)，那么這個(gè)時(shí)候，它就可以贏得選舉并在其他服務(wù)器結(jié)束超時(shí)之前發(fā)送?跳。?

3.3 Raft 協(xié)議下的消息復(fù)制?

每個(gè)仲裁隊(duì)列都有多個(gè)副本, 它包含?個(gè)主和多個(gè)從副本. replication factor 為 5的仲裁隊(duì)列將會(huì)有 1個(gè) 主副本和 4 個(gè)從副本. 每個(gè)副本都在不同的 RabbitMQ 節(jié)點(diǎn)上

客?端(?產(chǎn)者和消費(fèi)者)只會(huì)與主副本進(jìn)?交互, 主副本再將這些命令復(fù)制到從副本. 當(dāng)主副本所在的節(jié)點(diǎn)下線, 其中?個(gè)從副本會(huì)被選舉成為主副本, 繼續(xù)提供服務(wù).

消息復(fù)制和主副本選舉的操作, 需要超過(guò)半數(shù)的副本同意. 當(dāng)?產(chǎn)者發(fā)送?條消息, 需要超過(guò)半數(shù)的隊(duì)列副本都將消息寫(xiě)?磁盤(pán)以后才會(huì)向?產(chǎn)者進(jìn)?確認(rèn), 這意味著少部分?較慢的副本不會(huì)影響整個(gè)隊(duì)列的性能.

3.4 仲裁隊(duì)列的使?

①創(chuàng)建仲裁隊(duì)列

1)使?Spring框架代碼創(chuàng)建

2)使?管理平臺(tái)創(chuàng)建

創(chuàng)建時(shí)選擇Type為Quorum, 指定主副本?

?

②創(chuàng)建后觀察管理平臺(tái)

?

+2表示有兩個(gè)副本?

點(diǎn)進(jìn)去看隊(duì)列詳情:

對(duì)比普通隊(duì)列:

③接收/發(fā)送消息

?

3.5 宕機(jī)演示?

①?給仲裁隊(duì)列 quorum_queue 發(fā)送消息

?

②停掉隊(duì)列主副本所在的節(jié)點(diǎn)

?

觀察其他節(jié)點(diǎn), 可以看到quorum_queue 隊(duì)列的內(nèi)容依然存在:

并且, 因?yàn)橹鞲北舅诠?jié)點(diǎn)宕機(jī)了, quorum_queue 主副本從rabbit@localhost 轉(zhuǎn)移到了 rabbit3@localhost+1

隊(duì)列詳細(xì)信息: 只剩下兩個(gè)成員了:

?

4.?HAProxy 負(fù)載均衡

?對(duì)?量業(yè)務(wù)訪問(wèn)、?并發(fā)請(qǐng)求,可以使??性能的服務(wù)器來(lái)提升RabbitMQ服務(wù)的負(fù)載能?.

當(dāng)單機(jī)容量達(dá)到極限時(shí), 可以采取集群的策略來(lái)對(duì)負(fù)載能?做進(jìn)?步的提升, 但這?還存在?些問(wèn)題.

試想如果?個(gè)集群中有3個(gè)節(jié)點(diǎn), 我們?cè)趯?xiě)代碼時(shí), 訪問(wèn)哪個(gè)節(jié)點(diǎn)呢?

答案是訪問(wèn)任何?個(gè)節(jié)點(diǎn)都可以.

---

這時(shí)候就存在兩個(gè)問(wèn)題:

• 如果我們?cè)L問(wèn)的是node1, 但是node1掛了, 咱們的程序也會(huì)出現(xiàn)問(wèn)題, 所以最好是有?個(gè)統(tǒng)?的??, ?個(gè)節(jié)點(diǎn)故障時(shí), 流量可以及時(shí)轉(zhuǎn)移到其他節(jié)點(diǎn).
• 如果所有的客?端都與node1建議連接, 那么node1的?絡(luò)負(fù)載必然會(huì)??增加, ?其他節(jié)點(diǎn)?由于沒(méi)有那么多的負(fù)載?造成硬件資源的浪費(fèi).

引?負(fù)載均衡之后, 各個(gè)客?端的連接可以通過(guò)負(fù)載均衡分?jǐn)偟郊旱母鱾€(gè)節(jié)點(diǎn)之中, 從?避免前?的問(wèn)題.

這?講?下使?HAProxy來(lái)實(shí)現(xiàn)負(fù)載均衡.

4.1 安裝

安裝HAProxy

?#更新軟件包

sudo apt-get update

#查找haproxy

sudo apt list|grep haproxy

#安裝haproxy

sudo apt-get install haproxy

驗(yàn)證安裝

#查看服務(wù)狀態(tài)

sudo systemctl status haproxy

#查看版本

haproxy -v

#如果要設(shè)置HAProxy服務(wù)開(kāi)機(jī)?啟，可以使?：

sudo systemctl enable haproxy

修改haproxy.cfg

vim /etc/haproxy/haproxy.cfg

加入以下內(nèi)容:

# haproxy web 管理界面
listen stats
? ? bind *:8100 ? ? ??
? ? mode http
? ? stats enable
? ? stats realm Haproxy\ Statistics ? ?
? ? stats uri /
? ? stats auth admin:admin
# 配置負(fù)載均衡
listen rabbitmq
? ? bind *:5670
? ? mode tcp
? ? balance roundrobin
? ? server ?rabbitmq1 127.0.0.1:5672 ?check inter 5000 rise 2 fall 3
? ? server ?rabbitmq2 127.0.0.1:5673 ?check inter 5000 rise 2 fall 3
? ? server ?rabbitmq3 127.0.0.1:5674 ?check inter 5000 rise 2 fall 3?

?解釋:

• server rabbitmq1 : 定義RabbitMQ服務(wù)的內(nèi)部標(biāo)識(shí), 這?的rabbitmq1 是指haproxy內(nèi)部使?的, 不是指RabbitMQ的節(jié)點(diǎn)名稱
• 127.0.0.1:5672 : RabbitMQ真實(shí)的IP和端?
• check inter 5000 : 定義每隔多少毫秒檢查RabbitMQ服務(wù)是否可?
• rise 2 : 定義RabbitMQ服務(wù)在發(fā)?故障之后,需要多少次健康檢查才能被再次確認(rèn)可?.
• fall 3 : 定義需要經(jīng)歷多少次失敗的健康檢查之后,HAProxy才會(huì)停?使?此RabbitMQ服務(wù)

重啟HAPROXY

sudo systemctl restart haproxy?

查看HAProxy

通過(guò)119.91.154.99:8100訪問(wèn)

?

?

4.2 使用

①修改配置文件

spring:rabbitmq:addresses: amqp://admin:admin@119.91.154.99:5670/ops

②聲明隊(duì)列 test_cluster

?

③發(fā)送消息

?

④測(cè)試

?

⑤宕機(jī)演示

停?其中?個(gè)節(jié)點(diǎn), 繼續(xù)測(cè)試步驟2的代碼:

再次發(fā)送:

顯?隊(duì)列中有兩條數(shù)據(jù)

?

⑥集群恢復(fù)

觀察消息也同步到當(dāng)前節(jié)點(diǎn)了:?

?