Rabbitmq-集群管理

集群管理

3台虚拟机
192.168.181.140-node-linux140
192.168.181.141-node-linux141
192.168.181.142-node-linux142

安装

1. 在linux140、linux141、linux142三台Linux虚拟机中安装RabbitMQ
2. 从linux140拷贝.erlang.cookie到nodlinux141e3、linux142的相应目录
   如果没有该文件，手动创建 /var/lib/rabbitmq/.erlang.cookie ，生成Cookie字符串，或者启
   动一次RabbitMQ自动生成该文件。生产中推荐使用第三方工具生成。
   我们首先在linux140上启动单机版RabbitMQ，以生成Cookie文件
   

systemctl start rabbitmq-server

其他141，142节点也同样启动

开始准备同步 .erlang.cookie 文件。RabbitMQ的集群依赖Erlang的分布式特性，需要保持
Erlang Cookie一致才能实现集群节点的认证和通信，我们直接使用scp命令从node1远程传输

scp .erlang.cookie root@192.168.181.141:/var/lib/rabbitmq
scp .erlang.cookie root@192.168.181.142:/var/lib/rabbitmq

修改权限

修改192.168.181.141和192.168.181.142上该文件的所有者为rabbitmq:rabbitmq：

chown rabbitmq:rabbitmq /var/lib/rabbitmq/.erlang.cookie

注意.erlang.cookie文件权限为400

使用下述命令启动192.168.181.141和192.168.181.142上的RabbitMQ

加入集群

将192.168.181.141和192.168.181.142这两个节点加入到集群中
分别执行如下命令

# 停止Erlang VM上运行的RabbitMQ应用，保持Erlang VM的运行
rabbitmqctl stop_app
# 移除当前RabbitMQ虚拟主机中的所有数据：重置
rabbitmqctl reset
# 将当前RabbitMQ的主机加入到rabbit@node2这个虚拟主机的集群中。一个节点也是集群。
rabbitmqctl join_cluster rabbit@linux140
# 启动当前Erlang VM上的RabbitMQ应用
rabbitmqctl start_app

1. rabbit@linux140 表示RabbitMQ节点名称，默认前缀就是 rabbit ， @ 之后是当前虚拟主机所在的物理主机 hostname 。
2. 注意检查下hostname要可以相互ping通
3. join_cluster默认是使用disk模式，后面可以加入参数–ram启用内存模式

移出集群节点

# 将虚拟主机（RabbitMQ的节点）rabbit@node3从集群中移除，但是rabbit@node3还保留集群信
息 #
还是会尝试加入集群，但是会被拒绝。可以重置rabbit@linux142节点。
rabbitmqctl forget_cluster_node rabbit@linux142

配置

#修改集群名称（任意节点执行都可以）
rabbitmqctl set_cluster_name
#查看集群状态（任意节点执行都可以）
rabbitmqctl cluster_status

完成

RabbitMQ镜像集群配置

RabbitMQ中队列的内容是保存在单个节点本地的（声明队列的节点）。跟交换器和绑定不同，它们是对于集群中所有节点的。如此，则队列内容存在单点故障，解决方式之一就是使用镜像队列。在多个节点上拷贝队列的副本。

每个镜像队列包含一个master，若干个镜像。
master存在于称为master的节点上。
所有的操作都是首先对master执行，之后广播到镜像。
这涉及排队发布，向消费者传递消息，跟踪来自消费者的确认等。
镜像意味着集群，不应该WAN使用

发布到队列的消息会拷贝到该队列所有的镜像。消费者连接到master，当消费者对消息确认之后，
镜像删除master确认的消息。
队列的镜像提供了高可用，但是没有负载均衡。
HTTP API和CLI工具中队列对象的字段原来使用的是slave代表secondaries，现在盖字段的存在仅
是为了向后兼容，后续版本会移除。
可以使用策略随时更改队列的类型，可以首先创建一个非镜像队列，然后使用策略将其配置为镜像
队列或者反过来。非镜像队列没有额外的基础设施，因此可以提供更高的吞吐率。

master选举策略：

1. 最长的运行镜像升级为主镜像，前提是假定它与主镜像完全同步。如果没有与主服务器同步的镜像，则仅存在于主服务器上的消息将丢失。
2. 镜像认为所有以前的消费者都已突然断开连接。它重新排队已传递给客户端但正在等待确认的所有消息。这包括客户端已为其发出确认的消息，例如，确认是在到达节点托管队列主节点之前在线路上丢失了，还是在从主节点广播到镜像时丢失了。在这两种情况下，新的主服务器都别无选择，只能重新排队它尚未收到确认的所有消息。
3. 队列故障转移时请求通知的消费者将收到取消通知。当镜像队列发生了master的故障转移，系统就不知道向哪些消费者发送了哪些消息。已经发送的等待确认的消息会重新排队
4. 重新排队的结果是，从队列重新使用的客户端必须意识到，他们很可能随后会收到已经收到的消息。
5. 当所选镜像成为主镜像时，在此期间发布到镜像队列的消息将不会丢失（除非在提升的节点上发生后续故障）。发布到承载队列镜像的节点的消息将路由到队列主服务器，然后复制到所有镜像。如果主服务器发生故障，则消息将继续发送到镜像，并在完成向主服务器的镜像升级后将其添加到队列中。
6. 即使主服务器（或任何镜像）在正在发布的消息与发布者收到的确认之间失败，由客户端使用发布者确认发布的消息仍将得到确认。从发布者的角度来看，发布到镜像队列与发布到非镜像队列没有什么不同。

启用

# 对/节点配置镜像队列，使用全局复制
rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}'
# 配置过半（N/2 + 1）复制镜像队列
rabbitmqctl set_policy ha-halfmore "queueA" '{"ha-mode":"exactly", "haparams":2}'
# 指定优先级，数字越大，优先级越高
rabbitmqctl set_policy --priority 1 ha-all "^" '{"ha-mode":"all"}'

在任意一个节点上面执行即可。默认是将所有的队列都设置为镜像队列，在消息会在不同节点之间复制，各节点的状态保持一致。

https://www.rabbitmq.com/ha.html

负载均衡-HAProxy

将客户端的连接和操作的压力分散到集群中的不同节点，防止单个或几台服务器压力过大成为访问的瓶颈，甚至宕机。

HAProxy是一款开源免费，并提供高可用性、负载均衡以及基于TCP和HTTP协议的代理软件，可以支持四层、七层负载均衡，经过测试单节点可以支持10W左右并发连接。

LVS是工作在内核模式（IPVS），支持四层负载均衡，实测可以支撑百万并发连接。
Nginx支持七层的负载均衡（后期的版本也支持四层了），是一款高性能的反向代理软件和Web服务器，可以支持单机3W以上的并发连接

yum install gcc -y
tar -zxf haproxy-2.1.0.tar.gz
cd haproxy-2.1.0
make TARGET=linux-glibc
make install
mkdir /etc/haproxy
#赋权
groupadd -r -g 188 haproxy
# 添加用户
useradd -g haproxy -r -s /sbin/nologin -u 188 haproxy
#创建haproxy配置文件
touch /etc/haproxy/haproxy.cfg

觉得编译安装很麻烦，你可以简单的

yum -y install haproxy

如何使用yum安装的，那么haproxy默认在/usr/sbin/haproxy，且会自动创建配置文件/etc/haproxy/haproxy.cfg

配置HAProxy

vim /etc/haproxy/haproxy.cfg

global
log 127.0.0.1 local0 info
# 服务器最大并发连接数；如果请求的连接数高于此值，将其放入请求队列，等待其它连接被释放；
maxconn 5120
# chroot /tmp
# 指定用户
uid 188
# 指定组
gid 188
# 让haproxy以守护进程的方式工作于后台，其等同于“-D”选项的功能
# 当然，也可以在命令行中以“-db”选项将其禁用；
daemon
# debug参数
quiet
# 指定启动的haproxy进程的个数，只能用于守护进程模式的haproxy；
# 默认只启动一个进程，
# 鉴于调试困难等多方面的原因，在单进程仅能打开少数文件描述符的场景中才使用多进程模式；
# nbproc 20
nbproc 1
pidfile /var/run/haproxy.pid
defaults
log global
# tcp：实例运行于纯TCP模式，第4层代理模式，在客户端和服务器端之间将建立一个全双工的连接，
# 且不会对7层报文做任何类型的检查；
# 通常用于SSL、SSH、SMTP等应用；
mode tcp
option tcplog
option dontlognull
retries 3
option redispatch
maxconn 2000
# contimeout 5s
timeout connect 5s
# 客户端空闲超时时间为60秒则HA 发起重连机制
timeout client 60000
# 服务器端链接超时时间为15秒则HA 发起重连机制
timeout server 15000
listen rabbitmq_cluster
# VIP，反向代理到下面定义的三台Real Server
bind 192.168.181.135:5672
#配置TCP模式
mode tcp
#简单的轮询
balance roundrobin
# rabbitmq集群节点配置
# inter 每隔五秒对mq集群做健康检查，2次正确证明服务器可用，2次失败证明服务器不可用，并且配置主备机制
server rabbitmqNode1 192.168.181.140:5672 check inter 5000 rise 2 fall 2
server rabbitmqNode2 192.168.181.141:5672 check inter 5000 rise 2 fall 2
server rabbitmqNode3 192.168.181.142:5672 check inter 5000 rise 2 fall 2 
#配置haproxy web监控，查看统计信息
listen stats
bind 192.168.181.135:9000
mode http
option httplog
# 启用基于程序编译时默认设置的统计报告
stats enable
#设置haproxy监控地址为http://node1:9000/rabbitmq-stats
stats uri /rabbitmq-stats
# 每5s刷新一次页面
stats refresh 5s

启动HAProxy：

haproxy -f /etc/haproxy/haproxy.cfg

关闭

kill -9 <pid>

检查进程状态，还可以通过访问http://vip:9000/rabbitmq-stats查看状态

监控

当前云原生时代最热门的Prometheus监控平台也提供了rabbitmq_exporter，结合Grafana
漂亮美观的dashboard（可以自定义，也可以在仓库选择一些现有的），我们目前公司就是使用
Prometheus + Grafana来监控RabbitMQ的，并实现了水位告警通知

https://www.rabbitmq.com/prometheus.html