这是我参与11月更文挑战的第13天,活动详情查看:2021最后一次更文挑战
1.Rabbit MQ集群
rabbitmq有3种模式,但集群模式是2种。详细如下:
-
单一模式:即单机情况不做集群,就单独运行一个rabbitmq而已。之前我们一直在用
-
普通模式:默认模式,以两个节点(A、B)为例来进行说明
-
当消息进入A节点的Queue后,consum er从B节点消费时,RabbitMQ会在A和B之间创建临时通道进行消息传输,把A中的消息实体取出并经过通过交给B发送给consumer
-
当A故障后,B就无法取到A节点中未消费的消息实体
- 如果做了消息持久化,那么得等A节点恢复,然后才可被消费
- 如果没有持久化的话,就会产生消息丢失的现象
-
-
镜像模式:非常经典的mirror 镜像模式,保证100% 数据不丢失。
- 高可靠性解决方案,主要就是实现数据的同步,一般来讲是2 - 3 个节点实现数据同步
- 对于100% 数据可靠性解决方案,一般是采用3 个节点。
- 在实际工作中也是用得最多的,并且实现非常的简单,一般互联网大厂都会构建这种镜像集群模式
-
还有主备模式,远程模式,多活模式等,本次课程不作为重点,可自行查阅资料了解
1.1 集群搭建
前置条件:准备两台linux,并安装好rabbitmq
- 集群步骤如下:
- 修改/etc/hosts 映射文件
1号服务器:
127.0.0.1 A localhost localhost.localdomain localhost4
localhost4.localdomain4
::1 A localhost localhost.localdomain localhost6
localhost6.localdomain6
192.168.204.141 A
192.168.204.142 B
2号服务器:
127.0.0.1 B localhost localhost.localdomain localhost4
localhost4.localdomain4
::1 B localhost localhost.localdomain localhost6
localhost6.localdomain6
192.168.204.141 A
192.168.204.142 B
- 相互通信,cookie必须保持一致,同步 rabbitm q的cookie 文件:跨服务器拷贝.erlang.cookie(隐藏文件,使用ls -all 显示)
scp /var/lib/rabbitmq/.erlang.cookie 192.168.204.142:/var/lib/rabbitmq
修改cook ie文件,要重启服务器,reboot
- 停止防火墙,启动rabbitmq服务
systemctl stop firewalld
systemctl start rabbitmq- ser ver
- 加入集群节点
rabbitmqctl stop_app
rabbitmqctl join_cluster rabbit@A
rabbitmqctl start_app
- 查看节点状态
rabbitmqctl cluster_status
-
查看管理端
- 搭建集群结构之后,之前创建的交换机、队列、用户都属于单一结构,在新的集群环境中是不能用的
- 所以在新的集群中重新手动添加用户即可(任意节点添加,所有节点共享)
rabbitmqctl add_user root 123123
rabbitmqctl set_user_tags root administraor
rabbitmqctl set_permissions -p "/" root " . * " " . * " " . * "
- 注意:当节点脱离集群还原成单一结构后,交换机,队列和用户等数据都会重新回来
- 此时,集群搭建完毕,但是默认采用的模式“普通模式”,可靠性不高
1.2 镜像模式
-
将所有队列设置为镜像队列,即队列会被复制到各个节点,各个节点状态一致
- 语法:set_policy {name} {pattern} {definition}
-
name:策略名,可自定义
-
pattern:队列的匹配模式(正则表达式)
- "^" 可以使用正则表达式,比如"^queue_" 表示对队列名称以“queue_”开头的所有队列进行镜像,而"^"表示匹配所有的队列
-
definition:镜像定义,包括三个部分ha-m ode, ha-param s, ha-sync-m ode
-
ha-mode:(High Available,高可用)模式,指明镜像队列的模式,有效值为all/exactly/nodes,当前策略模式为all,即复制到所有节点,包含新增节点
- all :表示在集群中所有的节点上进行镜像 - exactly:表示在指定个数的节点上进行镜像,节点的个数由ha-par ams指定 - nodes :表示在指定的节点上进行镜像,节点名称通过ha-params 指定
-
-
ha-params:ha-mode模式需要用到的参数
-
ha-sync-mode:进行队列中消息的同步方式,有效值为automatic和manual
-
- 语法:set_policy {name} {pattern} {definition}
rabbitmqctl set_policy xall "^" '{ "ha-mode" :"all"} '
- 通过管理端设置镜像策略
1.3 HAProxy实现镜像队列的负载均衡
-
虽然我们在程序中访问A服务器,可以实现消息的同步,虽然在同步,但都是A服务器在接收消息,A太累
-
是否可以想Nginx一样,做负载均衡,A和B轮流接收消息,再镜像同步
1.3.1 HAProxy简介
- HA(HighAvailable,高可用),Proxy(代理)
- HAProxy是一款提供高可用性,负载均衡,并且基于TCP和HTTP应用的代理软件
- HAProxy完全免费
- HAProxy可以支持数以万计的并发连接
- HAProxy可以简单又安全的整合进架构中,同时还保护web服务器不被暴露到网络上
1.3.2 HAProxy与Nginx
-
OSI:(OpenSystem Interconnection:开放式系统互联 是把网络通信的工作分为7层,分别是物理层,数据链路层,网络层,传输层,会话层,表示层和应用层)
-
Nginx的优点:
- 工作在OSI第7层,可以针对http应用做一些分流的策略
- Nginx对网络的依赖非常小,理论上能ping通就就能进行负载功能,屹立至今的绝对优势
- Nginx安装和配置比较简单,测试起来比较方便;
- Nginx不仅仅是一款优秀的负载均衡器/反向代理软件,它同时也是功能强大的Web应用服务器
-
HAProxy的优点:
- 工作在网络4层和7层,支持TCP与Http协议,
- 它仅仅就只是一款负载均衡软件;单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度,在并发处理上也是优于Nginx的
- 支持8种负载均衡策略 ,支持心跳检测
-
性能上HA胜,功能性和便利性上Nginx胜
-
对于Http协议,Haproxy处理效率比Nginx高。所以,没有特殊要求的时候或者一般场景,建议使用Haproxy来做Http协议负载
-
但如果是Web应用,那么建议使用Nginx!
1.3.3安装和配置
HAProxy下载:www.haproxy.org/download/1.…
- 解压
tar -zxvf haproxy-1.8.12.tar.gz
- make时需要使用 TARGET指定内核及版本
uname -r 3.10.0-514.6.2.el7.x86_64
根据内核版本选择编译参数:
- 进入目录,编译和安装
cd haproxy-1.8.12
make TARGET=linux2628 PREFIX=/usr/local/haproxy
make install PREFIX=/usr/local/haproxy
- 安装成功后,查看版本
/usr/local/haproxy/sbin/haproxy -v
- 配置启动文件,复制haproxy文件到/usr/sbin下 ,复制haproxy脚本,到/etc/init.d下
cp /usr/local/haproxy/sbin/haproxy /usr/sbin/
cp ./examples/haproxy.init /etc/init.d/haproxy
chmod 755 /etc/init.d/haproxy
- 创建系统账号
useradd -r haproxy
- haproxy.cfg配置文件需要自行创建
mkdir /etc/haproxy
vim/etc/haproxy/haproxy.cfg
- 添加配置信息到haproxy.cfg
#全局配置
global
#设置日志
log 127.0.0.1 local0 info
#当前工作目录
chroot /usr/local/haproxy
#用户与用户组
user haproxy
group haproxy
#运行进程ID
uid 99
gid 99
#守护进程启动
daemon
#最大连接数
maxconn 4096
#默认配置
defaults
#应用全局的日志配置
log global
#默认的模式mode {tcp|http|health},TCP是4层,HTTP是7层,health只返回OK
mode tcp
#日志类别tcplog
option tcplog
#不记录健康检查日志信息
option dontlognull
#3次失败则认为服务不可用
retries 3
#每个进程可用的最大连接数
maxconn 2000
#连接超时
timeout connect 5s
#客户端超时30秒,ha就会发起重新连接
timeout client 30s
#服务端超时15秒,ha就会发起重新连接
timeout server 15s
#绑定配置
listen rabbitmq_cluster
bind 192.168.204.143:5672
#配置TCP模式
mode tcp
#简单的轮询
balance roundrobin
#RabbitMQ集群节点配置,每隔5秒对mq集群做检查,2次正确证明服务可用,3次失败证
明服务不可用
server A 192.168.204.141:5672 check inter 5000 rise 2 fall 3
server B 192.168.204.142:5672 check inter 5000 rise 2 fall 3
#haproxy监控页面地址
listen monitor
bind 192.168.204.143:8100
mode http
option httplog
stats enable
# 监控页面地址 http://192.168.204.143:8100/monitor
stats uri /monitor
stats refresh 5s
- 启动HAProxy
service haproxy start
记得关闭防火墙: systemctl stop firewalld
-
项目发消息,只需要将服务器地址修改为143即可,其余不变
-
所有的请求都会交给HAProxy,其负载均衡给每个rabbitmq服务器
1.4 KeepAlived搭建高可用的HAProxy集群
如果HAProxy服务器宕机,rabbitmq服务器就不可用了。所以我们需要对HAProxy也要做高可用的集群
1.4.1 概述
-
Keepalived是Linux下一个轻量级别的高可用热备解决方案
-
Keepalived的作用是检测服务器的状态,它根据TCP/IP参考模型的第三、第四层、第五层交换机制检测每个服务节点的状态,如果有一台web服务器宕机,或工作出现故障,Keepalived将检测到,并将有故障的服务器从系统中剔除,同时使用其他服务器代替该服务器的工作,当服务器工作正常后Keepalived自动将服务器加入到服务器群中,这些工作全部自动完成,不需要人工干涉,需要人工做的只是修复故障的服务器。
-
keepalived基于vrrp(VirtualRouterRedundancyProtocol,虚拟路由冗余协议)协议,vrrp它是一种主备(主机和备用机)模式的协议,通过VRRP可以在网络发生故障时透明的进行设备切换而不影响主机之间的数据通信
-
两台主机之间生成一个虚拟的ip,我们称漂移ip,漂移ip由主服务器承担,一但主服务器宕机,备份服务器就会抢夺漂移ip,继续工作,有效的解决了群集中的单点故障
-
将多台路由器设备虚拟成一个设备,对外提供统一ip(VIP)
1.4.2安装 KeepAlived
- 修改hosts文件的地址映射
ip | 用途 | 主机名 |
---|---|---|
192.168.204.143 | KeepAlivedHAProxy | C |
192.168.204.144 | KeepAlivedHAProxy | D |
- 安装keepalived
yuminstall -y keepalived
- 修改配置文件(内容大改,不如删掉,重新创建)
rm -rf /etc/keepalived/keepalived.conf
vim /etc/keepalived/keepalived.conf
!ConfigurationFileforkeepalived
global_defs{
router_idC ##非常重要,标识本机的hostname
}
vrrp_scriptchk_haproxy{
script"/etc/keepalived/haproxy_check.sh" ##执行的脚本位置
interval2 ##检测时间间隔
weight-20 ##如果条件成立则权重减20
}
vrrp_instanceVI_1{
stateMASTER ##非常重要,标识主机,备用机143改为 BACKUP
interfaceens33 ##非常重要,网卡名(ifconfig查看)
virtual_router_id66 ##非常重要,自定义,虚拟路由ID号(主备节点要相同)
priority100 ##优先级(0-254),一般主机的大于备机
advert_int1 ##主备信息发送间隔,两个节点必须一致,默认1秒
authentication{ ##认证匹配,设置认证类型和密码,MASTER和BACKUP必须使
用相同的密码才能正常通信
auth_typePASS
auth_pass1111
}
track_script{
chk_haproxy ##检查haproxy健康状况的脚本
}
virtual_ipaddress{ ##简称“VIP”
192.168.204.66/24 ##非常重要,虚拟ip,可以指定多个,以后连接mq就用这个虚
拟ip
}
}
virtual_server192.168.204.665672{ ##虚拟ip的详细配置
delay_loop6 #健康检查间隔,单位为秒
lb_algorr #lvs调度算法rr|wrr|lc|wlc|lblc|sh|dh
lb_kindNAT #负载均衡转发规则。一般包括DR,NAT,TUN3种
protocolTCP #转发协议,有TCP和UDP两种,一般用TCP
real_server192.168.204.1435672{ ##本机的真实ip
weight1 #默认为1,0为失效
}
}
- 创建执行脚本 /etc/keepalived/haproxy_check.sh
#!/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
Keepalived组之间的心跳检查并不能察觉到HAproxy负载是否正常,所以需要使用此脚本。
在Keepalived主机上,开启此脚本检测 HAproxy是否正常工作,如正常工作,记录日志。
如进程不存在,则尝试重启HAproxy,2秒后检测,如果还没有,则关掉主Keepalived,此时备 Keepalived检测到主 Keepalived挂掉,接管VIP,继续服务
- 授权,否则不能执行
chmod +x /etc/keepalived/haproxy_check.sh
- 启动keepalived(两台都启动)
systemctl stop firewalld
service keepalived start | stop | status | restart
- 查看状态
ps -ef | grep haproxy
ps -ef | grep keepalived
- 查看ip情况 ip addr 或 ip a
ip a
此时,安装完毕,按照上面的步骤就可以安装第二台了(服务器hostname和ip注意要修改)
常见的网络错误:子网掩码、网关等信息要一致
1.4.3测试ip漂移的规则
-
查看虚拟ip ip addr 或 ip a
-
目前,C节点是主机,所以虚拟ip在C节点
- 停止C的keepalived,虚拟ip漂移到D节点
- 重新启动C节点keepalived,虚拟ip依旧在D节点,并不会由于C的回归而回归
- 停止D的keepalived,虚拟ip再漂移回C节点
- 测试vip+端口是否提供服务(在141,A服务器上测试)
url 192.168.204.66:5672
AMQP ## 正常提供 AMQP服务,表示通过vip访问mq服务正常