1 集群節點安裝
單節點安裝RabbitMQ，可參考博文：
MQ RocketMQ安裝部署和配置： https://blog.csdn.net/qq_15769939/article/details/115800384
以上操作三個節點（71、72、73）同時進行操作
2 檔案同步配置
選擇71、72、73任意一個節點為Master（這里選擇71為Master），也就是說我們需要把71的Cookie檔案同步到72、73節點上去，進入/var/lib/rabbitmq目錄下，把/var/lib/rabbitmq/.erlang.cookie檔案的權限修改為777，原來是400；然后把.erlang.cookie檔案copy到各個節點下；最后把所有cookie檔案權限還原為400即可，
//進入目錄修改權限；遠程copy72、73節點
scp /var/lib/rabbitmq/.erlang.cookie 192.168.11.72:/var/lib/rabbitmq/
scp /var/lib/rabbitmq/.erlang.cookie 192.168.11.73:/var/lib/rabbitmq/
3 集群配置
3.1 停止服務
首先停止3個節點的服務：(這里不能使用原來的命令：/etc/init.d/rabbitmq-server stop)
rabbitmqctl stop
3.2 配置集群
3.2.1 組成集群
接下來我們就可以使用集群命令，配置71、72、73為集群模式，3個節點（71、72、73）執行啟動命令，后續啟動集群使用此命令即可，
rabbitmq-server -detached
3.2.2 slave加入集群
加入集群操作（重新加入集群也是如此，以最開始的主節點為加入節點）
//注意做這個步驟的時候：需要配置/etc/hosts 必須相互能夠尋址到
bhz72：rabbitmqctl stop_app
bhz72：rabbitmqctl join_cluster --ram rabbit@bhz71
bhz72：rabbitmqctl start_app
bhz73：rabbitmqctl stop_app
bhz73：rabbitmqctl join_cluster rabbit@bhz71
bhz73：rabbitmqctl start_app
//在另外其他節點上操作要移除的集群節點
rabbitmqctl forget_cluster_node rabbit@bhz71
3.2.3 修改集群名稱
修改集群名稱（默認為第一個node名稱）
rabbitmqctl set_cluster_name rabbitmq_cluster1
3.3 查看集群狀態
3.3.1 命令查看
在集群的任意一個節點執行命令：查看集群狀態
rabbitmqctl cluster_status
3.3.2 管理界面查看
訪問任意一個管控臺節點：http://192.168.11.71:15672 如圖所示
4 配置鏡像佇列
設定鏡像佇列策略（在任意一個節點上執行）
rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}'
將所有佇列設定為鏡像佇列，即佇列會被復制到各個節點，各個節點狀態一致，RabbitMQ高可用集群就已經搭建好了,我們可以重啟服務，查看其佇列是否在從節點同步，
5 訊息一致性問題
5.1 介紹
在使用rabbitmq中，訊息的一致性是非常重要的一個話題，下面我們來研究一下，在資料一致性方面，有哪些需要關注的，發送者發送訊息出來，在資料一致性的要求下，我們通常認為必須達到以下條件：
- broker持久化訊息
- publisher知道訊息已經成功持久化
首先，我們可以采用事務來解決此問題，每個訊息都必須經歷以上兩個步驟，就算一次事務成功，
事務是同步的，因此，如果采用事務，發送性能必然很差，官方給出來的性能是：
It takes a bit more than 4 minutes to publish 10000 messages.
異步的方法的效率是事務方法效率的100倍，
5.2 解決方案
我們可以采用異步的方式來解決此問題，publisher發送訊息后，不進行等待，而是異步監聽是否成功，這種方式又分為兩種模式，一種是return，另一種是confirm. 前一種是publisher發送到exchange后，異步收到訊息，第二種是publisher發送訊息到exchange,queue,consumer收到訊息后才會收到異步收到訊息，可見，第二種方式更加安全可靠，如下所示：
但是，異步也存在些局限性，如果一旦出現broker掛機或者網路不穩定，broker已經成功接收訊息，但是publisher并沒有收到confirm或return.這時，對于publisher來說，只能重發訊息解決問題，而在這里面，我們會發生重復訊息的問題，當然，如果業務型別要求資料一致性非常高，可以采用低效率的事務型解決方案：參考：http://www.rabbitmq.com/blog/2011/02/10/introducing-publisher-confirms/
6 相關資訊
上一篇：MQ RabbitMQ 高可用集群（一）：架構設計
下一篇：MQ RabbitMQ 高可用集群（三）：Ha-Proxy安裝和配置
博文不易，辛苦各位猿友點個關注和贊，感謝
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/278843.html
標籤：其他