在RabbitMQ集羣中，我們提到了RabbitMQ不能可以保證消息的可靠性，當節點崩潰時，該節點的隊列和其上的綁定信息都消失了。因爲RabbitMQ集羣中只會複製每個隊列的元數據，而不是複製其中的消息，當然我們也提到過可以利用其鏡像隊列改變這一點。
引入RabbitMQ的鏡像隊列機制，將隊列鏡像到集羣中其他的節點之上。在該實現下，如果集羣中的一個節點失效了，隊列能自動地切換到鏡像中的另一個節點以保證服務的可用性。
在通常的用法中，針對每一個鏡像隊列都包含一個master和多個slave，分別對應於不同的節點。slave會準確地按照master執行命令的順序進行命令執行，故slave與master上維護的狀態應該是相同的。除了publish外所有動作都只會向master發送，然後由master將命令執行的結果廣播給slave們，故看似從鏡像隊列中的消費操作實際上是在master上執行的。
另外RabbitMQ的鏡像隊列同時支持發送方確認和事務兩種機制。在事務機制中，只有當前事務在全部鏡像隊列中執行之後，客戶端纔會收到tx.commitOk的消息。同樣的，在發送方確認機制中，向發送者進行當前消息確認的前提是該消息被全部鏡像隊列接受了。
鏡像隊列
那麼鏡像隊列該如何進行聲明，這裏主要有兩種方式，首先我們來看在代碼中的用法，這裏其實我們在RabbitMQ隊列的屬性中，就曾提到過，如下：
其使用方式和其它的隊列屬性類似，如我們將一個隊列在RabbitMQ集羣中所有的節點上都聲明爲鏡像隊列，如下：
上述我們設置了x-ha-policy爲all，將該隊列在集羣所有的節點都進行了鏡像處理，不過假設RabbitMQ集羣很大，節點很多，那麼對性能影響就比較大，如上述所說的發送方確認和事務兩種機制中的問題。
所以這裏我們認爲沒有必要每個節點都進行鏡像，比如這個隊列只需在一臺或兩臺節點上進行鏡像就可以了，如下：
不過我們一般也不會直接在代碼中進行聲明，可能會直接通過控制檯，通過添加policy完成鏡像隊列的配置，這種方式比在代碼中相比而言會更加的靈活。
policy添加的命令爲：
rabbitmqctl set_policy [-p Vhost] Name Pattern Definition [Priority]
- -p Vhost 可選參數，針對指定vhost下的queue進行設置
- Name policy的名稱
- Pattern 隊列的匹配模式(正則表達式)
- Definition 鏡像定義，包括三個部分ha-mode, ha-params, ha-sync-mode
- ha-mode 指明鏡像隊列的模式，有效值爲 all/exactly/nodes
- all 表示在集羣中所有的節點上進行鏡像
- nodes 表示在指定的節點上進行鏡像，節點名稱通過ha-params指定
- exactly 表示在指定個數的節點上進行鏡像，節點的個數由ha-params指定
- ha-params ha-mode模式需要用到的參數
- ha-sync-mode 進行隊列中消息的同步方式，有效值爲 automatic 和 manual
- ha-mode 指明鏡像隊列的模式，有效值爲 all/exactly/nodes
- priority 可選參數，policy的優先級
按照上述的規則，我們這裏介紹給所有以queue開頭的隊列進行鏡像處理，並在集羣的兩個節點上完成進行，則policy的設置命令爲：
rabbitmqctl set_policy my_queue "^queue.*" '{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}'
上述就成功配置完成了，我們就可以去RabbitMQ的web管理頁面查看到（當然也可以直接在頁面上進行添加），如下：
HAProxy的安裝使用
上述我們利用了RabbitMQ的鏡像隊列完成了RabbitMQ中消息可能會發現丟失的情況，那麼就解決了RabbitMQ集羣的高可用了麼？當然沒有，這裏我們還記得在RabbitMQ集羣的最後，我們使用代碼取連接RabbitMQ集羣進行測試，我們共創建了兩個消費者，一個連接node1節點，一個連接node2節點，假設要是node1節點宕機了，那麼連接node1節點的消費者肯定就無法正常運行了，生產者也是同樣的道理。
這裏一般會使用HAProxy來進行處理，Haproxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，我們就利用其可以處理節點選擇以及負載的，其HAProxy安裝步驟如下：
wget http://pkgs.fedoraproject.org/repo/pkgs/haproxy/haproxy-1.7.9.tar.gz/sha512/d1ed791bc9607dbeabcfc6a1853cf258e28b3a079923b63d3bf97504dd59e64a5f5f44f9da968c23c12b4279e8d45ff3bd39418942ca6f00d9d548c9a0ccfd73/haproxy-1.7.9.tar.gz
首先我們我們需要下載haproxy的安裝包，下載完成後直接上傳至 /usr/local/src ，當然這裏我們也可以利用wget直接進行下載
tar zxvf haproxy-1.7.9.tar.gz
下載完後後，將其解壓，如下
make TARGET=linux310 ARCH=x86_64 PREFIX=/usr/local/haproxy
解壓完成後，我們進去其解壓包內，執行make TARGET=linux310 ARCH=x86_64 PREFIX=/usr/local/haproxy命令進行編譯，其參數說明如下：
-
TARGET=linux310，該值 linux310，表示的是內核版本，使用
uname -r可查看內核
![在這裏插入圖片描述]()
如上3.10.0-693.el7，此時該參數就爲linux310；kernel等於大於2.6.28的可以用：TARGET=linux2628 -
ARCH=x86_64，表示系統位數，同樣可由
uname -r查看 -
PREFIX=/usr/local/haprpxy，
/usr/local/haprpxy爲haprpxy安裝路徑。
make install PREFIX=/usr/local/haproxy
等待上述操作完成後，就可以直接安裝了，安裝路徑爲/usr/local/haproxy
上述安裝完成後，我們就需要在安裝路徑 /usr/local/haproxy 下，新建一個文件夾 conf ，然後在其中新建一個配置文件，進行相應的配置。
然後在剛剛新建的/usr/local/haproxy/conf/haproxy.cfg配置文件中添加下述配置，如下：
##########全局配置##########
global
log 127.0.0.1 local0 #日誌輸出配置,所有日誌都記錄在本機，通過local0輸出
log 127.0.0.1 local1 notice #定義haproxy日誌級別[error warring info debug]
maxconn 4096 #默認最大連接數,需考慮ulimit-n限制
daemon #以後臺形式運行harpoxy
nbproc 1 #設置進程數量
#pidfile /usr/local/haproxy/logs/haproxy.pid #pid文件路徑
#ulimit-n 819200 #ulimit-n 的數量限制
#chroot /usr/usr/local/haproxy #修改haproxy的工作目錄至指定的目錄
#uid 1 #指定運行haproxy的用戶id
#user haproxy #指定運行haproxy的用戶名,同uid
#group haproxy #運行haproxy的用戶所在的組
#debug #調試級別，建議只在開啓單進程的時候調試
##########默認配置##########
defaults
log global
mode tcp #默認的模式mode{tcp|http|health}:tcp是四層,http是七層,health只會返回ok
option tcplog #日誌類別,採用httplog
option dontlognull #不記錄健康檢查日誌信息
retries 2 #重試最大次數,兩次連接失敗就認爲是服務器不可用，也可以通過後面設置
#option forwardfor #如果後端服務器需要獲得客戶端真實ip需要配置的參數，可以從Http Header中獲得客戶端ip
option httpclose #每次請求完畢後主動關閉http通道,haproxy不支持keep-alive,只能模擬這種模式的實現
#option redispatch #當serverId對應的服務器掛掉後,強制定向到其他健康的服務器,以後將不支持
option abortonclose #當服務器負載很高時,自動結束調當前隊列處理比較久的鏈接
timeout connect 1d #連接超時時間
timeout client 1d #客戶端超時時間
timeout server 1d #服務器超時時間
timeout check 2000 #心跳檢測超時時間
balance roundrobin #負載均衡算法,輪詢方式
#balance source #設置默認負載均衡方式，類似於nginx的ip_hash
#balnace leastconn #設置默認負載均衡方式，最小連接數
#timeout http-keep-alive 10s #默認持久連接超時時間
#timeout http-request 10s #默認http請求超時時間
#timeout queue 1m #默認隊列超時時間
##########定義管理界面#########
listen admin_stats
bind 0.0.0.0:9999 #管理界面訪問的ip和port
mode http #管理界面使用的協議,http的7層模式
maxconn 10 #默認的最大連接數
option httplog #採用http日誌格式
stats refresh 30s #統計頁面自動刷新時間
stats uri /stats #統計頁面url
stats realm Haproxy Manager #統計頁面密碼框提示文本
stats auth admin:admin #統計頁面用戶名密碼
stats realm XingCloud\ Haproxy #統計頁面密碼框上提示文本
stats auth admin:admin #設置監控頁面的用戶和密碼:admin,可以設置多個用戶名
stats auth Frank:Frank #設置監控頁面的用戶和密碼：Frank
stats hide-version #隱藏統計頁面上HAProxy的版本信息
stats admin if TRUE #設置手工啓動/禁用，後端服務器(haproxy-1.4.9以後版本)
##########設置haproxy錯誤頁面##########
#errorfile 403 /home/haproxy/haproxy/errorfiles/403.http
#errorfile 500 /home/haproxy/haproxy/errorfiles/500.http
#errorfile 502 /home/haproxy/haproxy/errorfiles/502.http
#errorfile 503 /home/haproxy/haproxy/errorfiles/503.http
#errorfile 504 /home/haproxy/haproxy/errorfiles/504.http
##########定義監聽##########
listen rabbitmq_cluster
bind 0.0.0.0:5670
mode tcp
balance roundrobin
server rabbit01 node1:5672 check inter 5000 rise 2 fall 3
server rabbit02 node2:5672 check inter 5000 rise 2 fall 3
保存上述配置文件後，就可以直接啓動HAProxy，執行下列命令即可，如下：
/usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/conf/haproxy.cfg
然後我們就可以執行 lsof -i :9999 進行驗證了，如下：
上述就說明我們的HAProxy服務已經成功啓動了，這時我們就可以訪問其統計頁面了，瀏覽器訪問192.168.80.135:9999/stats，這裏會要求我們輸入密碼，這裏輸入上述配置文件中配置的賬號admin/密碼admin即可
提示：如果瀏覽器無法訪問，可以查看其上述配置文件中配置的相關端口是否開啓了，配置文件涉及端口：9999和5670，或者直接關閉防火牆。
安裝成功後，我們還是以RabbitMQ集羣最後的測試代碼來測試，這裏我們需要將其之前的代碼進行修改即可，我們將所有的生產者、消費者不再直接連接RabbitMQ服務，全部連接到HAProxy服務上即口，如：
測試截圖如下：
上述我們通過HAProxy來代理我們的RabbitMQ集羣，我們解決了RabbitMQ集羣節點宕機和負載均衡的問題，但是我們所有的服務都連接到了192.168.80.135機器上的HAProxy服務上了，那麼如果該機器宕機，或者HAProxy服務掛了，那麼整個服務就會直接癱瘓了，即存在單點故障。
那麼我們如何來解決HAProxy服務的單點故障問題呢？這裏我們可以利用Keepalived和HAProxy來結合起來，構建一個雙機熱備來保證其高可用，那麼Keepalived又該如何使用呢，這裏我們就不展開介紹了，其實之前我們也有使用過Keepalived，在構建Nginx服務高可用的使用，就曾詳細介紹過Keepalived，有興趣的話可以查看Nginx的高可用——Keepalived