之前簡單介紹了CentOS下單機部署RabbltMQ環境的操作記錄，下面詳細說下RabbitMQ集群知識，RabbitMQ是用erlang開發的，集群非常方便，因為erlang天生就是一門分布式語言,但其本身並不支持負載均衡。
Rabbit集群模式大概分為以下三種：單一模式、普通模式、鏡像模式，其中：
1）單一模式：最簡單的情況，非集群模式，沒什么好說的。
2）普通模式：默認的集群模式。
-> 對於Queue來說，消息實體只存在於其中一個節點，A、B兩個節點僅有相同的元數據，即隊列結構。
-> 當消息進入A節點的Queue中后，consumer從B節點拉取時，RabbitMQ會臨時在A、B間進行消息傳輸，把A中的消息實體取出並經過B發送給consumer。
-> 所以consumer應盡量連接每一個節點，從中取消息。即對於同一個邏輯隊列，要在多個節點建立物理Queue。否則無論consumer連A或B，出口總在A，會產生瓶頸。
-> 該模式存在一個問題就是當A節點故障后，B節點無法取到A節點中還未消費的消息實體。
-> 如果做了消息持久化，那么得等A節點恢復，然后才可被消費；如果沒有持久化的話，然后就沒有然后了。
3）鏡像模式：把需要的隊列做成鏡像隊列，存在於多個節點，屬於RabbitMQ的HA方案。
-> 該模式解決了上述問題，其實質和普通模式不同之處在於，消息實體會主動在鏡像節點間同步，而不是在consumer取數據時臨時拉取。
-> 該模式帶來的副作用也很明顯，除了降低系統性能外，如果鏡像隊列數量過多，加之大量的消息進入，集群內部的網絡帶寬將會被這種同步通訊大大消耗掉。
-> 所以在對可靠性要求較高的場合中適用於該模式（比如下面圖中介紹該種集群模式）。
RabbitMQ集群中的基本概念：
1）RabbitMQ的集群節點包括內存節點、磁盤節點。顧名思義內存節點就是將所有數據放在內存，磁盤節點將數據放在磁盤。不過，如前文所述，如果在投遞消息時，打開了消息的持久化，那么即使是內存節點，數據還是安全的放在磁盤。
2）一個rabbitmq集 群中可以共享 user，vhost，queue，exchange等，所有的數據和狀態都是必須在所有節點上復制的，一個例外是，那些當前只屬於創建它的節點的消息隊列，盡管它們可見且可被所有節點讀取。rabbitmq節點可以動態的加入到集群中，一個節點它可以加入到集群中，也可以從集群環集群會進行一個基本的負載均衡。
RabbitMQ集群中有兩種節點：
1）Ram內存節點：只保存狀態到內存（一個例外的情況是：持久的queue的持久內容將被保存到disk）
2）Disk磁盤節點：保存狀態到內存和磁盤。
內存節點雖然不寫入磁盤，但是它執行比磁盤節點要好。RabbitMQ集群中，只需要一個磁盤節點來保存狀態就足夠了；如果集群中只有內存節點，那么不能停止它們，否則所有的狀態，消息等都會丟失。
RabbitMQ集群思路：
那么具體如何實現RabbitMQ高可用，我們先搭建一個普通集群模式，在這個模式基礎上再配置鏡像模式實現高可用，Rabbit集群前增加一個反向代理，生產者、消費者通過反向代理訪問RabbitMQ集群。
上圖中3個RabbitMQ運行在同一主機上，分別用不同的服務端口。當然在生產環境里，多個RabbitMQ肯定是運行在不同的物理服務器上，否則就失去了高可用的意義。
RabbitMQ集群模式配置
該設計架構可以如下：在一個集群里，有3台機器，其中1台使用磁盤模式，另2台使用內存模式。2台內存模式的節點，無疑速度更快，因此客戶端（consumer、producer）連接訪問它們。而磁盤模式的節點，由於磁盤IO相對較慢，因此僅作數據備份使用，另外一台作為反向代理。
配置RabbitMQ集群非常簡單，只需要幾個命令，如下面范例，簡單說下配置的幾個步驟：
第一步：queue、kevintest1、kevintest2做為RabbitMQ集群節點，分別安裝RabbitMq-Server ，安裝后分別啟動RabbitMq-server。
啟動命令 # Rabbit-Server start
第二步：在安裝好的三台節點服務器中，分別修改/etc/hosts文件，指定queue、kevintest1、kevintest2的hosts。
172.16.3.32 queue 172.16.3.107 kevintest1 172.16.3.108 kevintest2 三台節點的hostname要正確，主機名分別是queue、kevintest1、kevintest2，如果修改hostname，建議安裝rabbitmq前修改。請注意RabbitMQ集群節點必須在同一個網段里， 如果是跨廣域網效果就差。
第三步：設置每個節點Cookie
Rabbitmq的集群是依賴於erlang的集群來工作的，所以必須先構建起erlang的集群環境。Erlang的集群中各節點是通過一個magic cookie來實現的，這個cookie存放在 /var/lib/rabbitmq/.erlang.cookie 中，文件是400的權限。所以必須保證各節點cookie保持一致，否則節點之間就無法通信。 # ll /var/lib/rabbitmq/.erlang.cookie -r-------- 1 rabbitmq rabbitmq 21 12月 6 00:40 /var/lib/rabbitmq/.erlang.cookie 將queue的/var/lib/rabbitmq/.erlang.cookie這個文件，拷貝到kevintest1、kevintest2的同一位置（反過來亦可），該文件是集群節點進行通信的驗證密鑰，所有 節點必須一致。拷完后重啟下RabbitMQ。復制好后別忘記還原.erlang.cookie的權限，否則可能會遇到錯誤 # chmod 400 /var/lib/rabbitmq/.erlang.cookie 設置好cookie后先將三個節點的rabbitmq重啟 # rabbitmqctl stop # rabbitmq-server start
第四步：停止所有節點RabbitMq服務，然后使用detached參數獨立運行，這步很關鍵，尤其增加節點停止節點后再次啟動遇到無法啟動，都可以參照這個順序
[root@queue ~]# rabbitmqctl stop
[root@kevintest1 ~]# rabbitmqctl stop
[root@kevintest2 ~]# rabbitmqctl stop
[root@queue ~]# rabbitmq-server -detached
[root@kevintest1 ~]# rabbitmq-server -detached
[root@kevintest2 ~]# rabbitmq-server -detached
分別查看下每個節點
[root@queue ~]# rabbitmqctl cluster_status
Cluster status of node rabbit@queue ...
[{nodes,[{disc,[rabbit@queue]}]},
{running_nodes,[rabbit@queue]},
{partitions,[]}]
...done.
[root@kevintest1 ~]# rabbitmqctl cluster_status
Cluster status of node rabbit@kevintest1...
[{nodes,[{disc,[rabbit@kevintest1]}]},
{running_nodes,[rabbit@kevintest1]},
{partitions,[]}]
...done.
[root@kevintest2 ~]# rabbitmqctl cluster_status
Cluster status of node rabbit@kevintest2...
[{nodes,[{disc,[rabbit@kevintest2]}]},
{running_nodes,[rabbit@kevintest2]},
{partitions,[]}]
...done.
第五步：將kevintest1、kevintest2作為內存節點與queue連接起來，在kevintest1上，執行如下命令：
[root@kevintest1 ~]# rabbitmqctl stop_app [root@kevintest1 ~]# rabbitmqctl join_cluster --ram rabbit@queue [root@kevintest1 ~]# rabbitmqctl start_app [root@kevintest2 ~]# rabbitmqctl stop_app [root@kevintest2 ~]# rabbitmqctl join_cluster --ram rabbit@queue #上面已經將kevintest1與queue連接，也可以直接將kevintest2與kevintest1連接，同樣而已加入集群中 [root@kevintest2 ~]# rabbitmqctl start_app 1）上述命令先停掉rabbitmq應用，然后調用cluster命令，將kevintest1連接到，使兩者成為一個集群，最后重啟rabbitmq應用。 2）在這個cluster命令下，kevintest1、kevintest2是內存節點，queue是磁盤節點（RabbitMQ啟動后，默認是磁盤節點）。 3）queue如果要使kevintest1或kevintest2在集群里也是磁盤節點，join_cluster 命令去掉--ram參數即可 #rabbitmqctl join_cluster rabbit@queue 只要在節點列表里包含了自己，它就成為一個磁盤節點。在RabbitMQ集群里，必須至少有一個磁盤節點存在。
第六步：在queue、kevintest1、kevintest2上，運行cluster_status命令查看集群狀態：
# rabbitmqctl cluster_status
Cluster status of node rabbit@queue ...
[{nodes,[{disc,[rabbit@queue]},{ram,[rabbit@kevintest2,rabbit@kevintest1]}]},
{running_nodes,[rabbit@kevintest2,rabbit@kevintest1,rabbit@queue]},
{partitions,[]}]
...done.
[root@kevintest1 rabbitmq]# rabbitmqctl cluster_status
Cluster status of node rabbit@kevintest1 ...
[{nodes,[{disc,[rabbit@queue]},{ram,[rabbit@kevintest2,rabbit@kevintest1]}]},
{running_nodes,[rabbit@kevintest2,rabbit@queue,rabbit@kevintest1]},
{partitions,[]}]
...done.
[root@kevintest2 rabbitmq]# rabbitmqctl cluster_status
Cluster status of node rabbit@kevintest2 ...
[{nodes,[{disc,[rabbit@queue]},{ram,[rabbit@kevintest2,rabbit@kevintest1]}]},
{running_nodes,[rabbit@kevintest1,rabbit@queue,rabbit@kevintest2]},
{partitions,[]}]
...done.
這時可以看到每個節點的集群信息，分別有兩個內存節點一個磁盤節點
第七步：往任意一台集群節點里寫入消息隊列，會復制到另一個節點上，我們看到兩個節點的消息隊列數一致：
[root@kevintest2 ~]# rabbitmqctl list_queues -p hrsystem Listing queues … test_queue 10000 …done. [root@kevintest1 ~]# rabbitmqctl list_queues -p hrsystem Listing queues … test_queue 10000 …done. [root@queue ~]# rabbitmqctl list_queues -p hrsystem Listing queues … test_queue 10000 …done. -p參數為vhost名稱
這樣RabbitMQ集群就正常工作了,這種模式更適合非持久化隊列，只有該隊列是非持久的，客戶端才能重新連接到集群里的其他節點，並重新創建隊列。假如該隊列是持久化的，那么唯一辦法是將故障節點恢復起來；為什么RabbitMQ不將隊列復制到集群里每個節點呢？這與它的集群的設計本意相沖突，集群的設計目的就是增加更多節點時，能線性的增加性能（CPU、內存）和容量（內存、磁盤）。理由如下：當然RabbitMQ新版本集群也支持隊列復制（有個選項可以配置）。比如在有五個節點的集群里，可以指定某個隊列的內容在2個節點上進行存儲，從而在性能與高可用性之間取得一個平衡。
=============清理RabbitMQ消息隊列中的所有數據============
方法如下： # rabbitmqctl list_queues //查看所有隊列數據 # rabbitmqctl stop_app //要先關閉應用，否則不能清除 # rabbitmqctl reset # rabbitmqctl start_app # rabbitmqctl list_queues //這時候看到listing 及queues都是空的
=========================================================================================
RabbitMQ集群：
1）RabbitMQ broker集群是多個erlang節點的邏輯組，每個節點運行rabbitmq應用，他們之間共享用戶、虛擬主機、隊列、exchange、綁定和運行時參數；
2）RabbitMQ集群之間復制什么信息：除了message queue（存在一個節點，從其他節點都可見、訪問該隊列，要實現queue的復制就需要做queue的HA）之外，任何一個rabbitmq broker上的所有操作的data和state都會在所有的節點之間進行復制；
3）RabbitMQ消息隊列是非常基礎的關鍵服務。本文3台rabbitMQ服務器構建broker集群，1個master，2個slave。允許2台服務器故障而服務不受影響。
RabbitMQ集群的目的
1）允許消費者和生產者在RabbitMQ節點崩潰的情況下繼續運行
2）通過增加更多的節點來擴展消息通信的吞吐量
RabbitMQ集群運行的前提：
1）集群所有節點必須運行相同的erlang及rabbitmq版本
2）hostname解析，節點之間通過域名相互通信，本文為3個node的集群，采用配置hosts的形式。
RabbitMQ端口及用途
1）5672 客戶端連接用途
2）15672 web管理接口
3）25672 集群通信用途
RabbitMQ集群的搭建方式：
1）通過rabbitmqctl手工配置 （本文采用此方式）
2）通過配置文件聲明
3）通過rabbitmq-autocluster插件聲明
4）通過rabbitmq-clusterer插件聲明
RabbitMQ集群故障處理機制：
1）rabbitmq broker集群允許個體節點down機，
2）對應集群的的網絡分區問題（ network partitions）
RabbitMQ集群推薦用於LAN環境，不適用WAN環境；要通過WAN連接broker，Shovel or Federation插件是最佳的解決方案；Shovel or Federation不同於集群。
RabbitMQ集群的節點運行模式：
為保證數據持久性，目前所有node節點跑在disk模式，如果今后壓力大，需要提高性能，考慮采用ram模式
RabbitMQ節點類型
1）RAM node:內存節點將所有的隊列、交換機、綁定、用戶、權限和vhost的元數據定義存儲在內存中，好處是可以使得像交換機和隊列聲明等操作更加的快速。
2）Disk node:將元數據存儲在磁盤中，單節點系統只允許磁盤類型的節點，防止重啟RabbitMQ的時候，丟失系統的配置信息。
問題說明：
RabbitMQ要求在集群中至少有一個磁盤節點，所有其他節點可以是內存節點，當節點加入或者離開集群時，必須要將該變更通知到至少一個磁盤節點。
如果集群中唯一的一個磁盤節點崩潰的話，集群仍然可以保持運行，但是無法進行其他操作（增刪改查），直到節點恢復。
解決方案：設置兩個磁盤節點，至少有一個是可用的，可以保存元數據的更改。
RabbitMQ集群節點之間是如何相互認證的：
1）通過Erlang Cookie，相當於共享秘鑰的概念，長度任意，只要所有節點都一致即可。
2）rabbitmq server在啟動的時候，erlang VM會自動創建一個隨機的cookie文件。cookie文件的位置是/var/lib/rabbitmq/.erlang.cookie 或者 /root/.erlang.cookie，為保證cookie的完全一致，采用從一個節點copy的方式。
Erlang Cookie是保證不同節點可以相互通信的密鑰，要保證集群中的不同節點相互通信必須共享相同的Erlang Cookie。具體的目錄存放在/var/lib/rabbitmq/.erlang.cookie。
說明：這就要從rabbitmqctl命令的工作原理說起，RabbitMQ底層是通過Erlang架構來實現的，所以rabbitmqctl會啟動Erlang節點，並基於Erlang節點來使用Erlang系統連接RabbitMQ節點，在連接過程中需要正確的Erlang Cookie和節點名稱，Erlang節點通過交換Erlang Cookie以獲得認證。
=======以下記錄CentOS6.9下RabbitMQ集群部署過程=======
集群機器信息：
rabbitmq01.kevin.cn 192.168.1.40
rabbitmq02.kevin.cn 192.168.1.41
rabbitmq03.kevin.cn 192.168.1.42
1）設置hosts主機解析,rabbitmq 集群通信用途，所有節點配置相同。
[root@rabbitmq01 ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.1.40 rabbitmq01.kevin.cn
192.168.1.41 rabbitmq02.kevin.cn
192.168.1.42 rabbitmq03.kevin.cn
其他兩個節點的hosts配置一致。
2）三台節點服務器上都要部署rabbitmq環境，可以參考：http://www.cnblogs.com/kevingrace/p/7693042.html
前台運行rabbitmq服務:
# /etc/init.d/rabbitmq-server start (用戶關閉連接后,自動結束進程)
或者
# rabbitmq-server start
設置開機啟動
# chkconfig rabbitmq-server on
后台運行rabbitmq服務：
# rabbitmq-server -detached
# lsof -i:5672
# lsof -i:15672
# lsof -i:25672
查看各節點狀態：
# rabbitmqctl status
或者
# /etc/init.d/rabbitmq-server status
3）設置節點間認證的cookie。可以把其中一個節點（比如rabbitmq01）的文件使用scp拷貝到其他兩個節點上
[root@rabbitmq01 ~]# cat /var/lib/rabbitmq/.erlang.cookie
FXQTFVXIUWEBZRLXFQOZ
[root@rabbitmq02 ~]# cat /var/lib/rabbitmq/.erlang.cookie
FXQTFVXIUWEBZRLXFQOZ
[root@rabbitmq03 ~]# cat /var/lib/rabbitmq/.erlang.cookie
FXQTFVXIUWEBZRLXFQOZ
同步完cookie之后，重啟rabbitmq-server。
# /etc/init.d/rabbitmq-server restart
4）為了把集群中的3個節點聯系起來，可以將其中兩個節點加入到另一個節點中。
比如：將rabbitmq01、rabbitmq03分別加入到集群rabbitmq02中，其中rabbitmq01和rabbitmq02節點為內存節點。rabbitmq02為磁盤節點。
注意：rabbitmqctl stop_app ---僅關閉應用，節點不被關閉
[root@rabbitmq01 ~]# rabbitmqctl stop_app
[root@rabbitmq01 ~]# rabbitmqctl join_cluster --ram rabbit@rabbitmq02
[root@rabbitmq01 ~]# rabbitmqctl start_app
[root@rabbitmq03 ~]# rabbitmqctl stop_app
[root@rabbitmq03 ~]# rabbitmqctl join_cluster --ram rabbit@rabbitmq02
[root@rabbitmq03 ~]# rabbitmqctl start_app
查看RabbitMQ集群情況（三個節點查看的結果一樣）
[root@rabbitmq01 ~]# rabbitmqctl cluster_status
Cluster status of node rabbit@rabbitmq01 ...
[{nodes,[{disc,[rabbit@rabbitmq02]},
{ram,[rabbit@rabbitmq03,rabbit@rabbitmq01]}]},
{running_nodes,[rabbit@rabbitmq03,rabbit@rabbitmq02,rabbit@rabbitmq01]},
{cluster_name,<<"rabbit@rabbitmq02.kevin.cn">>},
{partitions,[]},
{alarms,[{rabbit@rabbitmq03,[]},
{rabbit@rabbitmq02,[]},
{rabbit@rabbitmq01,[]}]}]
RabbitMQ集群的名字默認是第一個節點的名字，比如上面集群的名字是rabbitmq01。
修改RabbitMQ集群的名字kevinmq
# rabbitmqctl set_cluster_name kevinmq
# rabbitmqctl cluster_status
重啟集群：
# rabbitmqctl stop
# rabbitmq-server -detached
# rabbitmqctl cluster_status //觀察集群的運行狀態變化
5）重要信息：
當整個集群down掉時，最后一個down機的節點必須第一個啟動到在線狀態，如果不是這樣，節點會等待30s等最后的磁盤節點恢復狀態，然后失敗。
如果最后下線的節點不能上線，可以通過forget_cluster_node 指令來踢出集群。
如果所有的節點不受控制的同時宕機，比如掉電，會進入所有的節點都會認為其他節點比自己宕機的要晚，即自己先宕機，這種情況下可以使用
force_boot指令來啟動一個節點。
6）打破集群：
當一個節點不屬於這個集群的時候，需要及時踢出，可以通過本地或者遠程的方式
# rabbitmqctl stop_app
# rabbitmqctl reset
# rabbitmqctl start_app
這樣再次查看RabbitMQ集群的時候，該節點就不會在這里面了
# rabbitmqctl cluster_status
7）客戶端連接集群測試
通過web管理頁面進行創建隊列、發布消息、創建用戶、創建policy等。
http://192.168.1.41:15672/
或者通過rabbitmqadmin命令行來測試
[root@rabbitmq02 ~]# wget https://192.168.1.41:15672/cli/rabbitmqadmin
[root@rabbitmq02 ~]# chmod +x rabbitmqadmin
[root@rabbitmq02 ~]# mv rabbitmqadmin /usr/sbin/
Declare an exchange
[root@rabbitmq02 ~]# rabbitmqadmin declare exchange name=my-new-exchange type=fanout
exchange declared
Declare a queue, with optional parameters
[root@rabbitmq02 ~]# rabbitmqadmin declare queue name=my-new-queue durable=false
queue declared
Publish a message
[root@rabbitmq02 ~]# rabbitmqadmin publish exchange=my-new-exchange routing_key=test payload="hello, world"
Message published
And get it back
[root@rabbitmq02 ~]# rabbitmqadmin get queue=test requeue=false
+-------------+----------+---------------+--------------+------------------+-------------+
| routing_key | exchange | message_count | payload | payload_encoding | redelivered |
+-------------+----------+---------------+--------------+------------------+-------------+
| test | | 0 | hello, world | string | False |
+-------------+----------+---------------+--------------+------------------+-------------+
測試后發現問題問題：
[root@rabbitmq01 ~]# rabbitmqctl stop_app
[root@rabbitmq01 ~]# rabbitmqctl stop
在stop_app或者stop掉broker之后在rabbitmq01節點的上隊列已經不可用了，重啟rabbitmq01的app或broker之后，雖然集群工作正常，但rabbitmq01上隊列中消息會被清空（queue還是存在的）
對於生產環境而已，這肯定是不可接受的，如果不能保證隊列的高可用，那么做集群的意義也不太大了，還好rabbitmq支持Highly Available Queues，下面介紹下queue的HA。
=================Queue HA配置===============
默認情況下，RabbitMQ集群中的隊列存在於集群中的單個節點上，這要看創建隊列時聲明在那個節點上創建，而exchange和binding則默認存在於集群中所有節點。
隊列可以通過鏡像來提高可用性，HA依賴rabbitmq cluster，所以隊列鏡像也不適合WAN部署，每個被鏡像的隊列包含一個master和一個或者多個slave，當master
因任何原因故障時，最老的slave被提升為新的master。發布到隊列的消息被復制到所有的slave上，消費者無論連接那個node，都會連接到master；如果master確
認要刪除消息，那么所有slave就會刪除隊列中消息。隊列鏡像可以提供queue的高可用性，但不能分擔負載，因為所有參加的節點都做所有的工作。
1. 配置隊列鏡像
通過policy來配置鏡像，策略可在任何時候創建，比如先創建一個非鏡像的隊列，然后在鏡像，反之亦然。
鏡像隊列和非鏡像隊列的區別是非鏡像隊列沒有slaves，運行速度也比鏡像隊列快。
設置策略，然后設置ha-mode，3種模式：all、exactly、nodes。
每個隊列都有一個home node，叫做queue master node
1）設置policy，以ha.開頭的隊列將會被鏡像到集群其他所有節點，一個節點掛掉然后重啟后需要手動同步隊列消息
# rabbitmqctl set_policy ha-all-queue "^ha\." '{"ha-mode":"all"}'
2）設置policy，以ha.開頭的隊列將會被鏡像到集群其他所有節點,一個節點掛掉然后重啟后會自動同步隊列消息（生產環境采用這個方式）
# rabbitmqctl set_policy ha-all-queue "^ha\." '{"ha-mode":"all","ha-sync-mode":"automatic"}'
2. 問題：
配置鏡像隊列后，其中1台節點失敗，隊列內容是不會丟失，如果整個集群重啟，隊列中的消息內容仍然丟失，如何實現隊列消息內容持久化那？
集群節點跑在disk模式，創建見消息的時候也聲明了持久化，為什么還是不行那？
因為創建消息的時候需要指定消息是否持久化，如果啟用了消息的持久化的話，重啟集群消息也不會丟失了，前提是創建的隊列也應該是創建的持久化隊列。
客戶端連接rabbitMQ集群服務的方式：
1）客戶端可以連接集群中的任意一個節點，如果一個節點故障，客戶端自行重新連接到其他的可用節點；（不推薦，對客戶端不透明）
2）通過動態DNS，較短的ttl
3）通過HA+4層負載均衡器（比如haproxy+keepalived）
==========Haproxy+keepalived的部署===============
消息隊列作為公司的關鍵基礎服務，為給客戶端提供穩定、透明的rabbitmq服務，現通過Haproxy+keepalived構建高可用的rabbitmq統一入口，及基本的負載均衡服務。
為簡化安裝配置，現采用yum的方式安裝haproxy和keepalived，可參考 基於keepalived+nginx部署強健的高可用7層負載均衡方案。
在兩台兩台服務器部署haproxy+Keepalived環境，部署過程一樣。
haroxy01.kevin.cn 192.168.1.43
haroxy02.kevin.cn 192.168.1.44
1）安裝
[root@haproxy01 ~]# yum install haproxy keepalived -y
[root@haproxy01 ~]# /etc/init.d/keepalived start
2）設置關鍵服務開機自啟動
[root@haproxy01 ~]# chkconfig --list|grep haproxy
[root@haproxy01 ~]# chkconfig haproxy on
[root@haproxy01 ~]# chkconfig --list|grep haproxy
3) 配置將haproxy的log記錄到 /var/log/haproxy.log
[root@haproxy01 ~]# more /etc/rsyslog.d/haproxy.conf
$ModLoad imudp
$UDPServerRun 514
local0.* /var/log/haproxy.log
[root@haproxy01 ~]# /etc/init.d/rsyslog restart
4）haproxy的配置，2台機器上的配置完全相同
[root@haproxy01 ~]# more /etc/haproxy/haproxy.cfg
#---------------------------------------------------------------------
# Example configuration for a possible web application. See the
# full configuration options online.
#
# https://haproxy.1wt.eu/download/1.4/doc/configuration.txt
#
#---------------------------------------------------------------------
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
# to have these messages end up in /var/log/haproxy.log you will
# need to:
#
# 1) configure syslog to accept network log events. This is done
# by adding the '-r' option to the SYSLOGD_OPTIONS in
# /etc/sysconfig/syslog
#
# 2) configure local2 events to go to the /var/log/haproxy.log
# file. A line like the following can be added to
# /etc/sysconfig/syslog
#
# local2.* /var/log/haproxy.log
#
log 127.0.0.1 local2 notice
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon
# turn on stats unix socket
stats socket /var/lib/haproxy/stats
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
mode tcp
option tcplog
option dontlognull
option http-server-close
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 3000
###haproxy statistics monitor by laijingli 20160222
listen statics 0.0.0.0:8888
mode http
log 127.0.0.1 local0 debug
transparent
stats refresh 60s
stats uri / haproxy-stats
stats realm Haproxy \ statistic
stats auth laijingli:xxxxx
#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
frontend kevin_rabbitMQ_cluster_frontend
mode tcp
option tcpka
log 127.0.0.1 local0 debug
bind 0.0.0.0:5672
use_backend kevin_rabbitMQ_cluster_backend
frontend kevin_rabbitMQ_cluster_management_frontend
mode tcp
option tcpka
log 127.0.0.1 local0 debug
bind 0.0.0.0:15672
use_backend kevin_rabbitMQ_cluster_management_backend
#---------------------------------------------------------------------
# round robin balancing between the various backends
#---------------------------------------------------------------------
backend kevin_rabbitMQ_cluster_backend
balance roundrobin
server rabbitmq01.kevin.cn 192.168.1.40:5672 check inter 3s rise 1 fall 2
server rabbitmq02.kevin.cn 192.168.1.41:5672 check inter 3s rise 1 fall 2
server rabbitmq03.kevin.cn 192.168.1.42:5672 check inter 3s rise 1 fall 2
backend kevin_rabbitMQ_cluster_management_backend
balance roundrobin
server rabbitmq01.kevin.cn 192.168.1.40:15672 check inter 3s rise 1 fall 2
server rabbitmq02.kevin.cn 192.168.1.41:15672 check inter 3s rise 1 fall 2
server rabbitmq03.kevin.cn 192.168.1.42:15672 check inter 3s rise 1 fall 2
5）keepalived配置，特別注意2台服務器上的keepalived配置不一樣。
=======================先看下haroxy01.kevin.cn機器上的配置===========================
[root@haproxy01 ~]# more /etc/keepalived/keepalived.conf
global_defs {
notification_email {
wangshibo@kevin.cn
102533678@qq.com
}
notification_email_from notice@kevin.cn
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id haproxy43 ## xxhaproxy101 on master , xxhaproxy102 on backup
}
###simple check with killall -0 which is less expensive than pidof to verify that nginx is running
vrrp_script chk_nginx {
script "killall -0 nginx"
interval 1
weight 2
fall 2
rise 1
}
vrrp_instance KEVIN_GATEWAY {
state MASTER ## MASTER on master , BACKUP on backup
interface em1
virtual_router_id 101 ## KEVIN_GATEWAY virtual_router_id
priority 200 ## 200 on master , 199 on backup
advert_int 1
###采用單播通信，避免同一個局域網中多個keepalived組之間的相互影響
unicast_src_ip 192.168.1.43 ##本機ip
unicast_peer {
192.168.1.44 ##對端ip
}
authentication {
auth_type PASS
auth_pass 123456
}
virtual_ipaddress {
192.168.1.45 ## VIP
}
###如果只有一塊網卡的話監控網絡接口就沒有必要了
#track_interface {
# em1
#}
track_script {
chk_nginx
}
###狀態切換是發送郵件通知，本機記錄log，后期會觸發短信通知
notify_master /usr/local/bin/keepalived_notify.sh notify_master
notify_backup /usr/local/bin/keepalived_notify.sh notify_backup
notify_fault /usr/local/bin/keepalived_notify.sh notify_fault
notify /usr/local/bin/keepalived_notify.sh notify
smtp_alert
}
###simple check with killall -0 which is less expensive than pidof to verify that haproxy is running
vrrp_script chk_haproxy {
script "killall -0 haproxy"
interval 1
weight 2
fall 2
rise 1
}
vrrp_instance kevin_rabbitMQ_GATEWAY {
state BACKUP ## MASTER on master , BACKUP on backup
interface em1
virtual_router_id 111 ## kevin_rabbitMQ_GATEWAY virtual_router_id
priority 199 ## 200 on master , 199 on backup
advert_int 1
###采用單播通信，避免同一個局域網中多個keepalived組之間的相互影響
unicast_src_ip 192.168.1.43 ##本機ip
unicast_peer {
192.168.1.44 ##對端ip
}
authentication {
auth_type PASS
auth_pass 123456
}
virtual_ipaddress {
192.168.1.46 ## VIP
}
###如果只有一塊網卡的話監控網絡接口就沒有必要了
#track_interface {
# em1
#}
track_script {
chk_haproxy
}
###狀態切換是發送郵件通知，本機記錄log，后期會觸發短信通知
notify_master /usr/local/bin/keepalived_notify_for_haproxy.sh notify_master
notify_backup /usr/local/bin/keepalived_notify_for_haproxy.sh notify_backup
notify_fault /usr/local/bin/keepalived_notify_for_haproxy.sh notify_fault
notify /usr/local/bin/keepalived_notify_for_haproxy.sh notify
smtp_alert
}
=============================再看下haroxy02.kevin.cn機器上的配置==========================
[root@haproxy02 ~]# more /etc/keepalived/keepalived.conf
global_defs {
notification_email {
wangshibo@kevin.cn
102533678@qq.com
}
notification_email_from notice@kevin.cn
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id haproxy44 ## xxhaproxy101 on master , xxhaproxy102 on backup
}
###simple check with killall -0 which is less expensive than pidof to verify that nginx is running
vrrp_script chk_nginx {
script "killall -0 nginx"
interval 1
weight 2
fall 2
rise 1
}
vrrp_instance KEVIN_GATEWAY {
state BACKUP ## MASTER on master , BACKUP on backup
interface em1
virtual_router_id 101 ## KEVIN_GATEWAY virtual_router_id
priority 199 ## 200 on master , 199 on backup
advert_int 1
###采用單播通信，避免同一個局域網中多個keepalived組之間的相互影響
unicast_src_ip 192.168.1.44 ##本機ip
unicast_peer {
192.168.1.43 ##對端ip
}
authentication {
auth_type PASS
auth_pass YN_API_HA_PASS
}
virtual_ipaddress {
192.168.1.45 ## VIP
}
###如果只有一塊網卡的話監控網絡接口就沒有必要了
#track_interface {
# em1
#}
track_script {
chk_nginx
}
###狀態切換是發送郵件通知，本機記錄log，后期會觸發短信通知
notify_master /usr/local/bin/keepalived_notify.sh notify_master
notify_backup /usr/local/bin/keepalived_notify.sh notify_backup
notify_fault /usr/local/bin/keepalived_notify.sh notify_fault
notify /usr/local/bin/keepalived_notify.sh notify
smtp_alert
}
###simple check with killall -0 which is less expensive than pidof to verify that haproxy is running
vrrp_script chk_haproxy {
script "killall -0 haproxy"
interval 1
weight 2
fall 2
rise 1
}
vrrp_instance kevin_rabbitMQ_GATEWAY {
state MASTER ## MASTER on master , BACKUP on backup
interface em1
virtual_router_id 111 ## kevin_rabbitMQ_GATEWAY virtual_router_id
priority 200 ## 200 on master , 199 on backup
advert_int 1
###采用單播通信，避免同一個局域網中多個keepalived組之間的相互影響
unicast_src_ip 192.168.1.44 ##本機ip
unicast_peer {
192.168.1.43 ##對端ip
}
authentication {
auth_type PASS
auth_pass YN_MQ_HA_PASS
}
virtual_ipaddress {
192.168.1.46 ## VIP
}
###如果只有一塊網卡的話監控網絡接口就沒有必要了
#track_interface {
# em1
#}
track_script {
chk_haproxy
}
###狀態切換是發送郵件通知，本機記錄log，后期會觸發短信通知
notify_master /usr/local/bin/keepalived_notify_for_haproxy.sh notify_master
notify_backup /usr/local/bin/keepalived_notify_for_haproxy.sh notify_backup
notify_fault /usr/local/bin/keepalived_notify_for_haproxy.sh notify_fault
notify /usr/local/bin/keepalived_notify_for_haproxy.sh notify
smtp_alert
}
配置中用到的通知腳本，2台haproxy服務器上完全一樣：
[root@haproxy01 ~]# more /usr/local/bin/keepalived_notify.sh
#!/bin/bash
###keepalived notify script for record ha state transtion to log files
###將將狀態轉換過程記錄到log，便於排錯
logfile=/var/log/keepalived.notify.log
echo --------------- >> $logfile
echo `date` [`hostname`] keepalived HA role state transition: $1 $2 $3 $4 $5 $6 >> $logfile
###將狀態轉換記錄到nginx的文件，便於通過web查看ha狀態（一定注意不要開放到公網）
echo `date` `hostname` $1 $2 $3 $4 $5 $6 "
" > /usr/share/nginx/html/index_for_nginx.html
###將nginx api和rabbitmq的ha log記錄到同一個文件里
cat /usr/share/nginx/html/index_for* > /usr/share/nginx/html/index.html
6）haproxy監控頁面。
訪問地址http://192.168.1.43:8888
7）查看keepalived中高可用服務運行在那台服務器上
https://192.168.1.43
8）通過VIP訪問rabbitMQ服務
http://192.168.1.46:5672
9）其他問題
rabbitmq服務客戶端使用規范
1）使用vhost來隔離不同的應用、不同的用戶、不同的業務組
2）消息持久化，exchange、queue、message等持久化需要在客戶端聲明指定