RabbitMQ消息中间件技术精讲(五)
RabbitMQ集群镜像队列 延迟队列 docker docker-compose
第五章 RabbitMQ集群架构
文章目录
- 第五章 RabbitMQ集群架构
5.1-RabbitMQ集群架构模式-主备模式(Warren)
-
适用场景
-
一般在并发和数据量不高的情况下,主备模式具有非常好用且简单的优点
-
主备模式,主节点提供读写,从节点不支持读和写,只当做备用节点,当主节点发生故障,从节点转换为主节点;主从模式,主节点提供读写,从节点不支持写,但支持读
-
所谓的主备,就是
warren
兔子窝模式,就是一个主/备方案(主节点如果挂了,从节点提供服务,和activemq
利用zookeeper
做主/备一样)
-
-
HaProxy
配置listen rabbitmq_cluster # 集群名称 bind 0.0.0.0:5672 mode tcp # 配置 tcp 模式 balance roundrobin #简单的轮询 server bhz76 192.168.2.58:5672 check inter 5000 rise 2 fall 3 # 主节点 server bhz76 192.168.2.63:5672 backup check inter 5000 rise 2 fall 3 # 备用节点 # inter 每隔5秒对mq集群进行健康检测,2次正确心跳表示服务器可用,3次失败心跳表示服务器不可用
5.2-RabbitMQ集群架构模式-远程模式(Shovel)
- 远程模式可以实现双活的一种模式,简称
Shovel
模式,所谓远程模式,就是我们可以把消息进行不同数据中心的复制工作,我们可以跨地域的让两个mq集群互联,目前很少使用
-
集群配置
# 首先启动rabbitmq 插件,命令如下 rabbitmq-plugins enable amqp_client rabbitmq-plugins enable rabbitmq_shovel # 创建rabbitmq.config配置文件 touch /etc/rabbitmq/rabbitmq.config # 添加配置,详情见图 # 源服务器,和远程目标服务器使用相同的RabbitMQ配置文件
5.3-RabbitMQ集群架构模式-镜像模式(Mirror)
- 镜像模式,非常经典的模式,可以保证数据100%不丢失,在实际工作中使用最多。并且镜像模式配置非常简单,一般互联网大厂都会采用这种集群模式
- 镜像队列,目的是为了保障rabbitmq数据的高可靠性解决方案,主要是为了实现数据的同步,一般来说是2-3个节点实现数据同步,集群架构如下:
5.4-RabbitMQ集群架构模式-多活模式(Federation)
-
多活模式,是实现异地数复制的主流模式,因为远程模式配置比较复杂,所以一般异地集群采用多活模式。这种模式需要依赖
RabbitMQ
的federation
插件,可以实现持续的可靠的AMQP
数据通信,并且多活模式配置简单 -
部署采用双中心(或多中心),那么在两套(或多套)数据中心中个部署一套RabbitMQ集群,各中心的RabbitMQ服务除了需要为业务提供正常的消息服务外,中心之间还需要实现部分队列消息共享
-
federation
插件是一个不需要构建Cluster
,而在Brokers
之间传输消息的高性能插件,连接双方可以使用不同的users
和virtual hosts
,双方也可以使用不同版本的rabbitmq
和Erlang
,该插件使用的是AMQP
协议,可以接受不连续的传输
5.5-RabbitMQ集群镜像队列构建实现可靠性存储
目标
-
高可扩展性 (搭建镜像队列,可以进行水平扩展)
-
数据安全冗余 (在镜像队列基础上,设置镜像策略,使得每个节点的数据一致性)
-
高可用 (在镜像队列基础上,使用
Haproxy
进行负载均衡,再使用Keepalived
负载均衡,保证单点故障时集群依然有效)
1.RabbitMq集群环境节点
服务器ip | hostname | 节点说明 | 端口 | 管控台地址 |
---|---|---|---|---|
192.168.1.1 | Bhz1 | master | 5672 | ip:15672 |
192.168.1.2 | Bhz2 | slave | 5672 | ip:15672 |
192.168.1.3 | Bhz3 | slave | 5672 | ip:15672 |
192.168.1.4 | Bhz4 | haproxy+keepalived | 8100 | ip:8100/rabbitmq-stats |
192.168.1.5 | Bhz5 | haproxy+keepalived | 8100 | ip:8100/rabbitmq-stats |
2.配置集群
-
方法三:使用
K8S
进行,在三台服务器上构建集群 -
k8s可以自动化调度、运维docker容器
-
k8s已经成为微服务基础架构的“事实标准”
-
容器编排
-
pod: k8s最小业务单元,内含一个或多个容器
-
StatefulSet:定义一组有状态pod,k8s将自动维护,比如RabbitMQ容器停止了,k8s将自动重启
-
Deployment:定义一组无状态pod,k8s将自动维护
-
Service:一组pod的抽象访问方式,相当于负载均衡器
5.6-RabbitMQ集群整合负载均衡基础组件HAProxy
1.介绍
HaProxy
是一款提供高可用、负载均衡以及基于TCP
第四层和Http
第七层应用的代理软件,支持虚拟机,免费(已经有商业版和社区版了)。- 支持数万的并发连接,并且很简单安全的整合到当前架构中,同时保护web服务器不会暴露到网络上
2.优点
- 单进程、事件驱动模型,显著降低了上下文切换的开销和内存占用
- 单缓冲(single buffering)机制能以不复制任何数据的方式完成读写操作,可以节约大量的CPU时钟周期和内存带宽
- 借助Linux操作系统,实心零拷贝(zero-copy)
- 可实现即时内存分配
- 采用树形存储(二叉树)
3.安装配置
# 1. 下载依赖包
yum install gcc vim wget
wget https://www.haproxy.org/download/1.6/src/haproxy-1.6.16.tar.gz
# 2. 解压到指定目录
tar -zxvf haproxy-1.6.5.tar.gz -C /usr/local
# 3. 进入目录、进行编译、安装
cd /usr/local/haproxy-1.6.5
make TARGET=linux31 PREFIX=/usr/local/haproxy
make install PREFIX=/usr/local/haproxy
mkdir /etc/haproxy
# 赋权
groupadd -r -g 149 haproxy
useradd -g haproxy -r -s /sbin/nologin -u 149 haproxy
# 4. 创建配置文件,并进行配置,详情如下,配置时注意1.4和1.5两台服务器都是要配置
touch /etc/haproxy/haproxy.cfg
# 5. 启动haproxy,指定配置文件启动
/usr/local/haproxy/sbin/haproxy -f /etc/haproxy/haproxy.cfg
# 查看haproxy 进程状态
ps -ef |gref haproxy
# 6. 访问haproxy管控台 http:192.168.1.4:8100/rabbitmq-stats
4.配置haproxy.cfg
配置文件
# 更改配置文件haproxy.cfg,可参考:https://www.cnblogs.com/zyd112/p/8888945.html
# 全局配置
global
log 127.0.0.1 local3 info
maxconn 100000
chroot /usr/local/haproxy(安装地址)
# user haproxy
uid 99
gid 99
# group haproxy
daemon # 设置为后台进程
quiet
nbproc 4 # 进程数量(可以设置多个进程提高性能)
ulimit-n 65535 # ulimit的数量限制
pidfile /var/run/haproxy.pid
# 默认配置
defaults
# mode 有tcp 和 http 两种模式
mode tcp
log global
option tcplog
option dontlognull
option redispatch
retries 3
maxconn 500
timeout connect 10s
# 客户端空闲超过1分钟,则HA发起重连
timeout client 1m
# 服务端超时1分钟,则HA发起重连
timeout server 1m
timeout check 10s
# Haproxy控制台管理
listen admin_stats
stats enable
bind 192.168.1.4:8100
mode http
option httplog
log global
maxconn 10
stats refresh 5s # 统计页面自动刷新时间
stats uri /rabbitmq-stats # 访问的uri:ip:8100/rabbitmq-stats
stats realm haproxy
#stats auth admin:rabbitmq # 认证用户名和密码
#stats hide-version # 隐藏HAProxy的版本号
#stats admin if TRUE # 管理界面,如果认证成功了,可通过webui管理节点
# 监听rabbit集群
frontend rabbitmq_cluster
bind 0.0.0.0:5672
mode tcp # 默认的模式mode { tcp|http|health },tcp是4层,http是7层,health只会返回OK
option redispatch # 当serverId对应的服务器挂掉后,强制定向到其他健康的服务器
option abortonclose # 当服务器负载很高的时候,自动结束掉当前队列处理比较久的链接
balance roundrobin # 负载均衡算法 (简单轮询机制)
server Bhz1 192.168.1.1:5672 check inter 5000 rise 2 fall 3
server Bhz2 192.168.1.2:5672 check inter 5000 rise 2 fall 3
server Bhz3 192.168.1.3:5672 check inter 5000 rise 2 fall 3
maxconn 100000 # 最大链接数
timeout connect 60s # 连接超时
timeout client 30000 # 客户端超时
timeout server 30000 #服务器超时
5.7-RabbitMQ集群整合高可用组件KeepAlived
1.介绍
keepalived
是通过VRRP
协议实现高可用功能。VRRP = virtual router redundancypProtocol
虚拟路由器冗余协议,目的是解决静态路由单点故障问题,保证在个别节点宕机时,整个网络可以不间断运行- 主要作用有两个,一方面具有管理
LVS
负载均衡的功能,同时对LVS
集群节点进行健康检查功能;另一方面可实现系统网络服务的高可用failover
2.高可用原理
- 主节点会不断向从节点发送(播发方式)心跳,用来告诉从节点自己还活着
- 当主节点发生故障时,无法发送心跳检测,从节点无法得知主节点是否正常,于是调用自身接管程序,接管主节点的ip资源和服务
- 当主节点恢复时,从节点又会恢复到原来的备用角色(这点跟redis集群架构的主观下线和客观下线不同,即使主节点恢复,也会作为从节点)
3.安装配置
# 1. 下载软件包
yum install -y openssl openssl-devel
wget http://www.keepalived.org/software/keepalived-1.2.18.tar.gz
# 2. 解压、编译、安装
tar -zxvf keepalived-1.2.18.tar.gz -C /usr/local
cd keepalived-1.2.18/ && ./configure --prefix=/usr/local/keepalived
make && make install
# 创建文件夹,将keepalived配置文件进行复制
mkdir /etc/keepalived
cp /usr/local/keepalived/etc/keeplived/keepalived.conf /etc/keepalived/
# 复制keepalived脚本文件
cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/
cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
ln -s /usr/local/sbin/keepalived /usr/sbin/
# 如果存在则进行删除 rm /sbin/keepalived
ln -s /usr/local/keepalived/sbin/keepalived /sbin/
# 设置开机自启动
chkconfig keepalived on
# 3. 配置keepalived配置文件
vim /etc/keepalived/keepalived.conf
4.配置keepalived.conf
# 主节点
global_defs
{
router_id Bhz4 # 节点名字
}
vrrp_script chk_haproxy {
script "/etc/keepalived/haproxy_check.sh" # 执行脚本位置
interval 2 # 检测时间间隔
weight -20 # 如果条件成立则权重减少20
}
vrrp_instance VI_1 {
state MASTER # 主节点为MASTER,备份节点为BACKUP
interface eth0 #这个要和本机网卡名字一样
virtual_router_id 4 #虚拟路由ip号,这个数值 master和slave必须统一,我们一般选择主节点的ip地址后两位
mcast_src_ip 192.168.11.79 # 本机ip地址
priority 100 # 优先级配置(0-254)这个数值决定哪台服务器是master
advert_int 1 # 组播信息发送间隔,测试中的两个keepalived节点必须保持一致,1s
nopreempt
authentication { # 认证匹配
auth_type PASS
auth_pass 123456 # 指定密码
}
virtual_ipaddress {
192.168.1.11 # 虚拟ip,可以指定多个
}
track_script {
chk_haproxy
}
}
#从节点
global_defs
{
router_id Bhz5 # 节点名字
}
vrrp_script chk_haproxy {
script "/etc/keepalived/haproxy_check.sh" # 执行脚本位置
interval 2 # 检测时间间隔
weight -20 # 如果条件成立则权重减少20
}
vrrp_instance VI_1 {
state BACKUP # 主节点为MASTER,备份节点为BACKUP
interface eth0 #这个要和本机网卡名字一样
virtual_router_id 4 #虚拟路由ip号,这个数值 master和slave必须统一,我们一般选择主节点的ip地址后两位
mcast_src_ip 192.168.11.80 # 本机ip地址
priority 90 # 优先级配置(0-254)这个数值决定哪台服务器是master
advert_int 1 # 组播信息发送间隔,测试中的两个keepalived节点必须保持一致,1s
nopreempt
authentication { # 认证匹配
auth_type PASS
auth_pass 123456 # 指定密码
}
virtual_ipaddress {
192.168.1.11 # 虚拟ip,可以指定多个
}
track_script {
chk_haproxy
}
}
5.执行脚本内容;
#!/bin/bash
COUNT=`ps -C haproxy --no-header | wc -l`
if [$COUNT -eq 0];then
/usr/local/haproxy/sbin/haproxy -f /etc/haproxy/haproxy.cfg
sleep 2
if [`ps -C haproxy --no-header | wc -l ` -eq 0];then
killall keepalived
fi
fi
-
给执行脚本赋权,添加可执行权限
chmod +x /etc/keepalived/haproxy_check.sh
6.启动keepalived
# 启动,如果4,5两个节点没有启动haproxy,则运行
/usr/local/haproxy/sbin/haproxy -f /etc/haproxy/haproxy.cfg
# 查看 haproxy 进程状态
ps -ef | grep haproxy
# 启动两台服务器的 keepalived
service keepalived start | stop | status | restart
# 查看状态
ps -ef | grep haproxy
ps -ef | grep keepalived
5.8-RabbitMQ集群配置文件详解
-
集群节点模式:
Disk
为磁盘模式存储;Ram
为内存模式存储 -
tcp_listerners
设置rabbitmq
监听端口,默认5672 -
disk_free_limit
磁盘低水位线, 若磁盘容量低于指定值,则停止接收数据,默认值{mem_relative,1.0}
-
vm_memory_high_watermark
设置内存低水位线,若低于该水位线,则开启流量控制,默认值是0.4,即内存总量的40% -
详细官网配置:https://www.rabbitmq.com/configure.html
5.9-RabbitMQ集群恢复与故障转移的5种解决方案
- 准备条件:A节点和B节点组成镜像队列模式
- 场景1:A从节点先停,B主节点后停
- 方案1:只要先启动B主节点,在启动A从节点就可以;或者先启动A从节点,在30秒内启动B主节点,也可以恢复成镜像队列
- 场景2:A和B同时停机
- 方案2:可能是由于机房停电造成的,只需要在30秒内连续启动A和B就可以
- 场景3:A从节点先停,B主节点后停,并且A无法恢复
- 方案3:先启动B主节点,在B服务器上,调用命令
rabbitmqctl forget_cluster_node A
从集群中解除A,在将新的从节点比如C加入集群中就可以 - 场景4:A从节点先听,B主节点后停,且B无法恢复
- 方案4:在3.4.2版本之后,启动A节点,执行
rabbitmqctl forget_cluster_node --offline B
,表明利用从节点剔除主节点,迫使A节点变为主节点,在将新的从节点比如C加入以A为主节点的集群中 - 方案5:A先停,B后停,且AB都无法恢复,但是能得到A和B的磁盘文件
- 方案5:只能通过恢复数据的方式来尝试恢复,默认的数据库文件地址为
$RABBIT_HOME/var/lib
5.10-RabbitMQ集群延迟队列插件应用
-
使用场景:消息的延迟投递、定时任务等。包括一些消息重试策略的配合使用,以及用于业务流量削锋限流、降级的异步延迟消息机制
# 1. 下载插件 # 所有插件地址 https://www.rabbitmq.com/community-plugins.html https://github.com/rabbitmq/rabbitmq-delayed-message-exchange/releases/download/3.9.0/rabbitmq_delayed_message_exchange-3.9.0.ez # 2. 将下载的文件放到指定目录 docker cp ./rabbitmq_delayed_message_exchange-3.9.0.ez rabbitmq1:/plugins # 3. 启动插件 # 进入容器 docker exec -it rabbitmq1 /bin/bash # 启动插件 rabbitmq-plugins enable rabbitmq_delayed_message_exchange # 查看插件列表 rabbitmq-plugins list # 4. 访问地址进行测试 ip:port 在添加交换机的时候,可以看到多了一种方式(x-delayed-message)
- 在主节点创建延迟交换机,创建完后会发现在两个子节点也有相同的交换机和队列,说明同步策略是成功的
- 创建普通队列,并将队列和交换机进行绑定,在管控台操作就可以
![在这里插入图片描述](https://img-blog.csdnimg.cn/c2971052f3a44ab1bed9224daae337e7.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAQWxwaGEtY2hlbg==,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)
- 规定之间之后,队列接收到相应的信息
更多推荐
所有评论(0)