RabbitMQ高可用集群搭建

一、RabbitMQ集群架构模式

1.1 主备模式

实现RabbitMQ的高可用集群,一般在并发和数据量不高的情况下,这种模型非常的好用且简单。主备模式也称之为Warren模式。

所谓主备模式指的是主节点提供读写功能,而从节点不提供读写功能,从节点只是主节点的一个容灾节点,在主节点出现故障或者宕机的时候能够实现一个自动的切换。

在这里插入图片描述

1.1.1 HaProxy配置

HaProxy是一个TCP级别的代理
在这里插入图片描述

  • listen 集群名称
  • bind 绑定的TCP的端口
  • mode 使用TCP简单轮询
  • balance roundrobin
  • server 节点名称 节点ip
  • check inter 5000 rise 2 fall 3 每隔5秒对MQ集群做一次健康检查,2次成功证明服务器可用,3次失败证明服务器不可用

1.2 主从模式

所谓主从模式指的是主节点提供读写功能,而从节点只提供读的功能。

1.3 远程模式

远程模式:远程模式可以实现双活的一种模式,简称Shovel模式,所谓Shovel就是我们可以把消息进行不同数据中心的复制工作,我们可以跨地域的让两个MQ集群互联。

在这里插入图片描述
在使用了shovel插件后,模型变成了近端同步确认,远端异步确认的方式,大大提高了订单确认速度,并且还能保证可靠性。
在这里插入图片描述

这种模式的工作机制是:当一个消息打到一个节点的时候,它除了有一个工作队列之外还有一个备份队列,当工作队列压力过大的时候,消息就会进入备份队列,备份队列通过shovel插件和另一个节点相连接,消息会由备份队列发送到另一个压力不是很大的节点,从而在另一个节点进行消费。

1.3.1 配置步骤

启动RabbitMQ插件

rabbitmq-plugins enable amqp_client
rabbitmq-plugins enable rabbitmq_shovel

创建rabbitmq.config文件

touch /etc/rabbitmq/rabbitmq.config

在这里插入图片描述

源服务器和目的服务器都使用相同的配置文件

1.4 镜像模式

集群模式非常经典的就是Mirror镜像模式,保证100%数据不丢失,在实际工作中也是用的最多的。并且实现集群非常的简单。

1.4.1 Mirror镜像队列

目的是为了保证rabbitmq数据的高可靠性解决方案,主要就是实现数据的同步,一般来讲是2-3个节点实现数据同步(对于100%数据可靠性解决方案一般是3节点)

1.4.2 集群架构

在这里插入图片描述

1.5 多活模式

这种模式也是实现异地数据复制的主流模式,因为Shovel模式配置比较复杂,所以一般来说实现异地集群都是使用这种双活或者多活模型来实现的。这种模型需要依赖rabbitmq的federation插件,可以实现持续的可靠的AMQP数据通信,多活模式在实际配置与应用非常简单。

1.5.1 架构

在这里插入图片描述

通过Federation插件让两个集群之间的数据实现同步复制。

1.5.2 Federation插件

Federation插件是一个不需要构建Cluster,而在Brokers之间传输消息的高性能插件,Federation插件可以在Brokers或者Cluster之间传输消息,连接的双方可以使用不同的users和virtual hosts。双方也可以使用版本不同的RabbitMQ和Erlang。Federation插件使用AMQP协议通讯,可以接受不连续的传输。

二、镜像模式集群搭建

2.1 节点准备

准备三台已经安装好RabbitMQ的服务器
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
解决默认用户guest无法登录UI界面

原因:guest用户只能在本地登录,对于它所安装的服务器来说,我们的电脑并不能算的是本地,所以我们需要新增一个管理员用户

步骤:

  • 添加管理员账号:rabbitmqctl add_user 用户名 密码
  • 设置权限:rabbitmqctl set_user_tags 用户名 administrator

如此设置,我们就可以使用刚刚添加的管理员账号登录RabbitMQ的UI界面。

2.2 停止三个节点的RabbitMQ服务

2.3 文件同步

选择HadoopNode01、HadoopNode02、HadoopNode03任意一个节点为Master(这里选择HadoopNode01为Master),也就是说我们需要把HadoopNode01的Cookie文件同步到HadoopNode02、HadoopNode03节点上去。进入到/var/lib/rabbitmq目录下,把/var/lib/rabbitmq/.erlang.cookie文件的权限修改为777,然后把.erlang.cookie文件copy到各个节点下;最后把所有cookie文件的权限还原为400即可。

scp /var/lib/rabbitmq/.erlang.cookie 192.168.9.133:/var/lib/rabbitmq/
scp /var/lib/rabbitmq/.erlang.cookie 192.168.9.134:/var/lib/rabbitmq/
chmod 400 .erlang.cookie

2.4 组成集群

接下来就可以使用集群命令,配置HadoopNode01、HadoopNode02、HadoopNode03为集群模式,3个节点执行启动命令。

rabbitmq-server -detached

2.5 配置Host映射

编辑/etc/hosts

192.168.9.132 HadoopNode01
192.168.9.133 HadoopNode02
192.168.9.134 HadoopNode03

2.6 slave加入集群

分别在HadoopNode02和HadoopNode03两个节点上执行以下命令

[root@HadoopNode02 ~]# rabbitmqctl stop_app
[root@HadoopNode02 ~]# rabbitmqctl join_cluster rabbit@HadoopNode01
[root@HadoopNode02 ~]# rabbitmqctl start_app

效果
在这里插入图片描述
如果要从集群中移除某个节点(以HadoopNode02为例)

rabbitmqctl forget_cluster_node rabbit@HadoopNode02

2.7 设置集群名称

rabbitmqctl set_cluster_name rabbitmq_cluster

以上命令在整个集群的任意节点执行一次即可。

2.8 查看集群状态

rabbitmqctl cluster_status

在这里插入图片描述
此时再去访问任意一个节点的控制台就会发现变化
在这里插入图片描述

可以看到RabbitMQ已经有了三个节点。但是它们都是以磁盘存储的方式启动的,想要以内存存储的方式启动,只需要在上述的启动命令里面加一个参数即可:rabbitmqctl join_cluster -ram rabbit@HadoopNode01

2.9 配置镜像队列

设置镜像队列策略(在任意一个节点执行即可)

rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}'

将所有队列设置为镜像队列,即队列会被复制到各个节点,各个节点状态一致,RabbitMQ高可用集群就已经搭建好了,我们可以重启服务,查看其队列是否在从节点同步。

2.10 Haproxy

Haproxy是一款提供高可用性、负载均衡以及基于TCP和HTTP应用的代理软件,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。

2.10.1 Haproxy性能最大化

Haproxy借助于OS上几种常见的技术来实现性能的最大化

  1. 单进程、事件驱动模型显著降低了上下文切换的开销及内存占用
  2. 在任何可用的情况下,单缓冲的机制能以不复制任何数据的方式完成读写操作,这会节约大量的CPU时钟周期及内存带宽。
  3. 借助于Linux 2.6(>=2.6.27.19)上的splice()系统调用,Haproxy可以实现零复制转发(Zero-copy forwarding),在Linux 3.5及以上的OS中还可以实现零复制启动
  4. 内存分配器在固定大小的内存池中可实现即时内存分配,这能够显著减少创建一个会话的时长
  5. 树型存储:侧重于使用作者多年前开发的弹性二叉树,实现以O(log(N))的低开销来保持计时器命令、保持运行队列命令及管理轮询及最少连接队列。

2.10.2 Haproxy安装

下载依赖包

yum install -y gcc

下载Haproxy

yum install -y haproxy

编辑Haproxy的配置文件

vim /etc/haproxy/haproxy.cfg

配置如下

global
    log         127.0.0.1 local2
    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
defaults
#   使用四层代理模式,"mode http"为7层代理模式
    mode                    tcp
    log                     global
#   因为上面把mode设置成了tcp,所以这里把httplog改成tcplog
    option                  tcplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
#   客户端空闲超时时间为60秒,超过该时间,HA发起重连机制
    timeout client          1m
#   服务端连接超时时间为60秒,超过该事件,HA发起重连机制
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000
listen rabbitmq_cluster
    # 定义监听地址和端口,本机的5672端口
    bind 0.0.0.0:5672
    # 配置 tcp 模式
    mode tcp
    # balance url_param userid
    # balance url_param session_id check_post 64
    # 简单的轮询
    balance roundrobin
    #rabbitmq集群节点配置 #inter 每隔五秒对mq集群做健康检查,2次正确证明服务器可用,
    #2次失败证明服务器不可用,并且配置主备机制
    server HadoopNode01 192.168.9.132:5672 check inter 5000 rise 2 fall 2
    server HadoopNode02 192.168.9.133:5672 check inter 5000 rise 2 fall 2
    server HadoopNode03 192.168.9.134:5672 check inter 5000 rise 2 fall 2
# 配置 haproxy web 监控,查看统计信息
listen stats
    bind *:8100
    mode http
    option httplog
    stats enable
    # 设置 haproxy 监控地址为:http://localhost:8100/rabbitmq-stats
    stats uri /rabbitmq-stats
    stats refresh 5s

启动Haproxy

haproxy -f /etc/haproxy/haproxy.cfg

重启Haproxy

service haproxy restart

至此,Haproxy配置成功,可以访问主机名:8100/rabbitmq-stats,可以看到:
在这里插入图片描述

2.11 安装KeepAlived(为node04和node05安装)

2.11.1 什么是Keepalived

KeepAlived软件主要是通过VRRP协议实现高可用功能的。VRRP是Virtual Router RedundancyProtocol(虚拟路由器冗余协议)的缩写,VRRP出现的目的就是为了解决静态路由单点故障问题的,它能保证当个别节点宕机的时候,真个网络可以不间断的运行,所以,KeepAlived一方面具有配置管理LVS的功能,同时还具有对LVS下面节点上进行健康检查的功能,另一方面也可实现系统网络服务的高可用功能。

2.11.2 KeepAlived重要特性

  1. 管理LVS负载均衡软件
  2. 实现LVS集群节点的健康检查
  3. 作为系统网络服务的高可用性

2.11.3 KeepAlived高可用原理

在KeepAlived服务正常工作时,主Master节点会不断地向从节点发送心跳消息,用以告诉备Backup节点自己还活着,当主Master节点发生故障时,就无法发送心跳消息,备节点也就因此无法继续检测到来自主Master节点的心跳了,于是调用自身的接管程序,接管主Master节点的IP资源及服务。而当主Master节点恢复时,备Backup节点又会释放主节点故障时自身接管的IP资源及服务,恢复到原来的备用角色。

这里将HadoopNode04作为keepalived的主节点,HadoopNode05作为备用节点。并且当HadoopNode04宕机恢复服务后,需要抢回VIP。
安装所需依赖包

yum install -y openssl openssl-devel

下载KeepAlived

wget http://www.keepalived.org/software/keepalived-1.2.18.tar.gz

解压到指定目录

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

把keepalived的配置文件复制到创建的文件夹中

cp /usr/local/keepalived/etc/keepalived/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
ln -s /usr/local/keepalived/sbin/keepalived /sbin

设置开机启动

chkconfig keepalived on

到此,keepalived安装完毕。
编辑KeepAlived的配置文件

vim /etc/keepalived/keepalived.conf

主节点的配置文件内容如下:

! Configuration File for keepalived
global defs {
    router_id HadoopNode04 ##标识节点的字符串,通常为hostname
}

vrrp_script chk_haproxy{
    script "/etc/keepalived/haproxy_check.sh"   ## 执行脚本位置
    interval 2  ##检查时间间隔
    weight -20 ##如果条件成立则权重减20
}

vrrp_instance VI_1 {
    state MASTER ##主节点为MASTER,备份节点为BACKUP
    interface ens33 ##绑定虚拟ip的网络接口(网卡)
    virtual_router_id 135    ##虚拟路由id号,主备节点相同
    mcast_src_ip 192.168.9.135 ##本机ip地址
    priority 100    ##优先级(0-254)
    nopreempt
    advert_int 1    ##组播信息发送间隔,两个节点必须一致,默认1s
    authentication {    ##认证匹配
        auth_type PASS
        auth_pass 123456
    }
    track_script {
        chk_haproxy
    }
    virtual_ipaddress {
        192.168.9.70 ##虚拟ip,可以指定多个
    }
}

备节点的配置文件内容如下:

! Configuration File for keepalived
global defs {
    router_id HadoopNode05 ##标识节点的字符串,通常为hostname
}

vrrp_script chk_haproxy{
    script "/etc/keepalived/haproxy_check.sh"   ## 执行脚本位置
    interval 2  ##检查时间间隔
    weight -20 ##如果条件成立则权重减20
}

vrrp_instance VI_1 {
    state BACKUP ##主节点为MASTER,备份节点为BACKUP
    interface ens33 ##绑定虚拟ip的网络接口(网卡)
    virtual_router_id 135    ##虚拟路由id号,主备节点相同
    mcast_src_ip 192.168.9.136 ##本机ip地址
    priority 90    ##优先级(0-254)
    nopreempt
    advert_int 1    ##组播信息发送间隔,两个节点必须一致,默认1s
    authentication {    ##认证匹配
        auth_type PASS
        auth_pass 123456
    }
    track_script {
        chk_haproxy
    }
    virtual_ipaddress {
        192.168.9.70 ##虚拟ip,可以指定多个
    }
}

vrrp_instance 的 interface 为VIP需要挂载的网卡上,我这里都放在虚拟机的ens33上。HadoopNode04的 state 为 MASTER,HadoopNode05为 BACKUP ,priority 要保证HadoopNode04大于HadoopNode05,这样就能实现HadoopNode04宕机之后恢复服务,能够从HadoopNode05抢回VIP;如果需要实现不抢回VIP,则HadoopNode04和HadoopNode05的state都设置为BACKUP,并且vrrp_instance 都添加nopreempt,表示不抢夺VIP(实际上已经加了)。

添加执行脚本haproxy_check.sh
内容如下,两个节点都一样

#!/bin/bash
COUNT = `ps -C haproxy --no-header | wc -l`
if [$COUNT -eq 0];then
    /usr/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 haproxy_check.sh

keepalived的启动相关命令

service keepalived start | stop | status | restart

查看状态

ps -ef | grep haproxy
ps -ef | grep keepalived

结果
在这里插入图片描述
至此,基于KeepAlived和Haproxy的RabbitMQ集群已经搭建完成。
在这里插入图片描述

在这张架构图里面,KeepAlived扮演的角色是高可用,而Haproxy扮演的角色扮演的角色是负载均衡,它们通力合作,保证了RabbitMQ集群的高可用和负载均衡。当KeepAlived的VIP节点挂点之后,它所绑定的虚拟IP就会“漂移”到另一个节点上,当节点恢复之后,它会重新从别的节点手中夺回VIP,重新作为MASTER节点提供服务。

RabbitMQ本身并不直接支持分布式事务,但是可以通过一些机制来实现分布式事务。 一种常用的方式是使用两阶段提交(Two-Phase Commit,简称2PC)协议来实现分布式事务。在这种方案中,事务的协调者(coordinator)会与多个参与者(participants)进行通信,以确保所有参与者在提交或者回滚事务时的一致性。 在RabbitMQ中,可以将消息生产者作为事务的协调者,将消息消费者作为参与者。下面是一个简单的示例: 1. 生产者发送消息到RabbitMQ,并开启一个事务。 2. 生产者将消息发送给消费者,并等待消费者返回确认消息。 3. 如果所有的消费者都成功处理了消息,则协调者发送“prepare”消息给所有的参与者。 4. 参与者收到“prepare”消息后,将消息持久化到本地存储,并发送“ready”消息给协调者。 5. 协调者收到所有参与者的“ready”消息后,发送“commit”消息给所有的参与者。 6. 参与者收到“commit”消息后,正式提交事务,并发送确认消息给协调者。 7. 协调者收到所有参与者的确认消息后,完成事务。 需要注意的是,如果任何一个参与者在处理消息时出现异常,协调者将发送“rollback”消息,参与者接收到“rollback”消息后会回滚事务。 这只是一个简单的示例,实际的实现可能需要考虑更多的细节和异常处理。另外,还有其他的分布式事务解决方案,如Saga模式、TCC(Try-Confirm-Cancel)模式等,也可以根据具体需求选择合适的方案。
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值