本文使用的高可用架构是 Keepalived + HAproxy，用 HAproxy 来做 RabbitMQ 负载均衡和高可用，用 Keepalived 来保证 HAproxy 的高可用。
RabbitMQ 集群的安装过程这里不再赘述，可以参考 https://blog.csdn.net/WoogeYu/article/details/51119101。
这里使用的三节点集群的安装方式，规划如下：
组件 IP 端口
RabbitMQ 主 192.168.151.7 5672
RabbitMQ 从 192.168.151.18 5672
RabbitMQ 从 192.168.151.19 5672
HAproxy 主 192.168.151.18
HAproxy 从 192.168.151.19
Keepalived 主 192.168.151.18
Keepalived 从 192.168.151.19
VIP 192.168.151.108
RabbitMQ 集群安装
在 192.168.151.7、192.168.151.18、192.168.151.19 三个节点上分别安装配置。
安装
yum -y install rabbitmq-server
service rabbitmq-server start
配置
rabbitmqctl add_user admin admin
rabbitmqctl set_user_tags admin administrator
set_permissions -p / admin ‘.*’ ‘.*’ ‘.*’
rabbitmqctl set_permissions -p / admin ‘.*’ ‘.*’ ‘.*’
rabbitmq-plugins enable rabbitmq_management
局域网配置
分别在三个节点的 /etc/hosts 下设置相同的配置信息
192.168.151.7 HRB-PCRP1-M-BCCLM-CTL7
192.168.151.18 HRB-PCRP1-M-BCCLM-CTL18
192.168.151.19 HRB-PCRP1-M-BCCLM-CTL19
设置不同节点间同一认证的 Erlang Cookie
采用从主节点 copy 的方式保持 Cookie 的一致性。
# scp /var/lib/rabbitmq/.erlang.cookie 192.168.151.18:/var/lib/rabbitmq
# scp /var/lib/rabbitmq/.erlang.cookie 192.168.151.19:/var/lib/rabbitmq12
使用 -detached 运行各节点
rabbitmqctl stop
rabbitmq-server -detached
查看各节点的状态
rabbitmqctl cluster_status
创建并部署集群，以 192.168.151.7 节点为例：
# rabbitmqctl stop_app
# rabbitmqctl reset
# rabbitmqctl join_cluster rabbit@HRB-PCRP1-M-BCCLM-CTL7
# rabbitmqctl start_app
查看集群状态
# rabbitmqctl cluster_status
Cluster status of node ‘rabbit@HRB-PCRP1-M-BCCLM-CTL7’ …
[{nodes,[{disc,[‘rabbit@HRB-PCRP1-M-BCCLM-CTL18’,
‘rabbit@HRB-PCRP1-M-BCCLM-CTL19’,
‘rabbit@HRB-PCRP1-M-BCCLM-CTL7’]}]},
{running_nodes,[‘rabbit@HRB-PCRP1-M-BCCLM-CTL18’,
‘rabbit@HRB-PCRP1-M-BCCLM-CTL19’,
‘rabbit@HRB-PCRP1-M-BCCLM-CTL7’]},
{cluster_name,<<“rabbit@HRB-PCRP1-M-BCCLM-CTL7”>>},
{partitions,[]},
{alarms,[{‘rabbit@HRB-PCRP1-M-BCCLM-CTL18’,[]},
{‘rabbit@HRB-PCRP1-M-BCCLM-CTL19’,[]},
{‘rabbit@HRB-PCRP1-M-BCCLM-CTL7’,[]}]}]
RabbitMQ 集群至此安装完成。可以通过访问各节点的 http://192.168.151.7:15672/ 管理页面查看 RabbitMQ 状态。用户名密码使用之前配置的 admin/admin。
Keepalived 监控 192.168.151.18、192.168.151.19 上的 HAproxy，利用 Keepalived 的 VIP 漂移技术，若两台服务器上的 HAprox 都工作正常，则 VIP 与优先级别高的服务器（主服务器）绑定，当主服务器当掉时，则与从服务器绑定，而 VIP 则是暴露给外部访问的 IP；HAproxy 利用 Keepalived 生产的 VIP 对多台 RabbitMQ 进行读负载均衡。
下面对上面的 RabbitMQ 集群进行高可用配置，HAproxy 和 Keepalived 的安装方法这里不再赘述。
高可用架构 Keepalived + HAproxy
其中 Keepalived 来控制 HAproxy 的高可用，HAproxy 的作用是控制下层应用的负载均衡，同时可以用来保证下层应用的高可用。
HAproxy
HAproxy 是一个七层的负载均衡高度器，和 nginx 是属于一个层次上的，而 lvs 是一个四层的负载均衡高度器，它最多只能工作在 TCP/IP 协议栈上，所以对于代理转发，HAproxy 做的可以比 lvs 更细腻。
HAProxy 提供高可用性、负载均衡以及基于 TCP 和 HTTP 应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。HAProxy 特别适用于那些负载特大的 web 站点，这些站点通常又需要会话保持或七层处理。HAProxy 运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中，同时可以保护你的 web 服务器不被暴露到网络上。
HAproxy 配置
这里仅列出了主要内容。
HAProxy配置中分成五部分内容，当然这些组件不是必选的，可以根据需要选择部分作为配置。
#global ：参数是进程级的，通常和操作系统（OS）相关。这些参数一般只设置一次，如果配置无误，就不需要再次配置进行修改
#defaults：配置默认参数的，这些参数可以被利用配置到frontend，backend，listen组件
#frontend：接收请求的前端虚拟节点，Frontend可以根据规则直接指定具体使用后端的 backend(可动态选择)。
#backend ：后端服务集群的配置，是真实的服务器，一个Backend对应一个或者多个实体服务器。
#listen ：Frontend和Backend的组合体。
listen rabbitmq
bind 192.168.151.108:5673
balance roundrobin
mode tcp
option tcplog
option tcpka
bind-process 7
timeout client 15s
timeout connect 3s
timeout server 15s
server HRB-PCRP1-M-BCCLM-CTL7 192.168.151.7:5672 check inter 5000 rise 2 fall 3
server HRB-PCRP1-M-BCCLM-CTL18 192.168.151.18:5672 check inter 5000 rise 2 fall 3
server HRB-PCRP1-M-BCCLM-CTL19 192.168.151.19:5672 check inter 5000 rise 2 fall 3
# weight – 调节服务器的负重
# check – 允许对该服务器进行健康检查
# inter – 设置连续的两次健康检查之间的时间，单位为毫秒(ms)，默认值 2000(ms)
# rise – 指定多少次连续成功的健康检查后，可认定该服务器处于可操作状态，默认值 2
# fall – 指定多少次不成功的健康检查后，认为服务器为当掉状态，默认值 3
# maxconn – 指定可被发送到该服务器的最大并发连接数
# 配置haproxy web监控，查看统计信息
listen private_monitoring :8100
mode http
option httplog
stats enable
#设置haproxy监控地址为http://localhost:8100/stats
stats uri /stats
stats refresh 5s
这里使用了一个 listen 块来同时实现前端和后端，也可以由前端（frontend）和后端（backend）配置。
最后我们打开 http://192.168.151.18:8100/stats，看一下监控页面，如果显示出正常就表明已经将 HAProxy 负载均衡配置好了！
注意点
启动 HAproxy 时可能会出现 cannot bind socket 的异常，这是因为 HAproxy 配置中使用了 VIP，但此时还没有启动 Keepalived，那么就还没有 VIP 绑定。
这时需要在 /etc/sysctl.conf 文件中配置如下内容：
net.ipv4.ip_nonlocal_bind = 1 # 意思是启动haproxy的时候，允许忽视VIP的存在
net.ipv4.ip_forward = 1 # 打开内核的转发功能
然后运行 sysctl –p 使其生效。
Keepalived
Keepalived 的作用是检测服务器的健康状态，在所有可能出现单点故障的地方为其提供高可用。如果有一台服务器死机，或工作出现故障，Keepalived 将检测到，并将有故障的服务器从系统中剔除，当服务器工作正常后 Keepalived 自动将服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的服务器。
这里使用的实现方式是单活方式，即主节点的 HAproxy 正常运行，备节点的会被停止。当主节点的出现故障时，备节点的 HAproxy 会自动启动。当主节点的恢复后，备节点的会自动停止。
当然 Keepalived 的高可用控制不止这一种，也可以有其他配置方式。
Keepalived 主节点配置
vrrp_script chk_haproxy {
script “service haproxy status” # 服务探测，返回0说明服务是正常的
interval 1 # 每隔1秒探测一次
weight -2 # 不正常时，权重-1，即haproxy上线，权重加2；下线，权重减2
}
vrrp_instance haproxy {
state MASTER # 主机为MASTER，备机为BACKUP
interface bond0 # 监测网络端口，用ipconfig查看
virtual_router_id 108 # 主备机必须相同
priority 100 # 主备机取不同的优先级，主机要大。
advert_int 1 # VRRP Multicast广播周期秒数
authentication {
auth_type PASS # VRRP认证方式
auth_pass 1234 # VRRP口令 主备机密码必须相同
}
track_script { # 调用haproxy进程检测脚本，备节点不配置
chk_haproxy
}
track_interface {
bond0
}
virtual_ipaddress { # VIP 漂移地址 即集群IP地址
192.168.151.108/25 dev bond0
}
}
Keepalived 备节点
vrrp_instance haproxy {
state BACKUP
interface bond0
virtual_router_id 108
priority 99
advert_int 1
authentication {
auth_type PASS
auth_pass 1234
}
track_interface {
bond0
}
virtual_ipaddress {
192.168.151.108
}
notify_master “/etc/keepalived/notify.sh master” # 当前节点成为master时，通知脚本执行任务，一般用于启动某服务
notify_backup “/etc/keepalived/notify.sh backup” # 当前节点成为backup时，通知脚本执行任务，一般用于关闭某服务
}
notify.sh 脚本
放在 /etc/keepalived/ 目录下，并赋予可执行权限。
#!/bin/bash
case “$1” in
master)
notify master
service haproxy start
exit 0
;;
backup)
notify backup
service haproxy stop
exit 0
;;
fault)
notify fault
service haproxy stop
exit 0
;;
*)
echo ‘Usage: `basename $0` {master|backup|fault}’
exit 1
;;
esac
Keepalived 执行过程
MASTER – 初始 priority 为 100，BACKUP – 初始 priority 为 99
模拟 MASTER 产生故障：
当检测到 chk_haproxy 执行结果为 down 时，priority 每次减少 2，变为 98；低于 BACKUP 的 priority；
此时 MASTER 变成 BACKUP；
同时 BACKUP 变成 MASTER，同时执行 notify_master 的脚本文件（启动haproxy）；
模拟 MASTER 故障恢复：
当 MASTER 节点的 HAproxy 恢复后，原 MASTER 的优先级又变为 100，高于原 BACKUP 的 priority；
此时原 MASTER 由 BACKUP 又抢占成了 MASTER；
同时原 BACKUP 由 MASTER 又变了 BACKUP，同时执行 notify_backup 的脚本文件（关闭haproxy）；
