rabbitmq高可用

1.全局图

客户端通过VIP建立通信链路;通信链路通过Keeaplived的Master节点路由到对应的HAProxy之上;HAProxy通过负载均衡算法将负载分发到集群中的各个节点之上。正常情况下客户端的连接通过图中左侧部分进行负载分发。当Keepalived的Master节点挂掉或者HAProxy挂掉无法恢复,那么Backup提升为Master,客户端的连接通过图中右侧部分进行负载分发。如果你追求要更高的可靠性,可以加入多个Backup角色的Keepalived节点来实现一主多从的多机热备。当然这样会提升硬件资源的成本,该如何抉择需要更细致的考恒,一般情况下双机热备的配备已足够满足应用需求。

2.首先要先安装rabbitmq,详情  https://www.cnblogs.com/yuzhen0228/p/10489068.html

3.配置rabbitmq cluster

先保证各个rabbitmq节点都是可以访问的,将这两个节点连接起来形成高可用的cluster,这样我们就可以让我们的exchange、queue在这两个节点之间复制,形成高可用的queue。

cd /var/lib/rabbitmq

里面有一个隐藏文件.erlang.cookie文件,这个文件是erlang用来发现和互连的基础。

我们需要做的很简单,将两个节点中的.erlang.cookie设置成一样的。

这是erlang的约定,一样的cookie hash key他认为是合法和正确的连接。

.erlang.cookie默认是只读的,你需要修改下写入权限,然后复制粘贴下cookie  字符串即可。

chmod u+w .erlang.cookie

配置好了之后接下来配置hosts文件,erlang会使用hosts文件里的配置去发现节点。

vim /etc/hosts

10.64.16.123    l-rabbitmq1
10.64.17.11      l-rabbitmq2

保证同样的配置在所有的节点上都是相同的。

验证你配置的正确不正确你只需要在你的机器上ping,试下请求的ip是不是你配置的即可。按照DNS的请求原理,hosts是最高优先权,除非浏览器有缓存,你直接用ping就不会有问题的。

选择一个节点stop,然后连接到另外节点。

这里以节点 l-rabbitmq2为例,

rabbitmqctl stop_app

rabbitmqctl join_cluster rabbit@ l-rabbitmq1

rabbitmqctl start_app

节点已经连接成功。

默认情况下节点占用的memory是总内存的40%,可以根据自己的用途仔细研究rabbitmq的配置项。为了提高性能,不需要两个节点都是disc的节点,所以我们需要启动一个节点为RAM模式。

rabbitmqctl change_cluster_node_type  ram  (需要先停掉,才能更改)

改变rabbitmq_node1为内存节点模式。

4.mirror queue policy设置

设置成镜像队列

可以在机器上,用命令行设置,也可以在管理页面进行创建

这里以命令行为例, 设置policy,以ha.开头的队列将会被镜像到集群其他所有节点,一个节点挂掉然后重启后会自动同步队列消

rabbitmqctl set_policy ha-all "^ha\." ‘{"ha-mode":"all","ha-sync-mode":"automatic"}‘               //意思表示以ha.开头的queue都会复制到各个节点

3.Keepalived

Keepalived 的作用是检测服务器的健康状态,在所有可能出现单点故障的地方为其提供高可用。如果有一台服务器死机,或工作出现故障,Keepalived 将检测到,并将有故障的服务器从系统中剔除,当服务器工作正常后 Keepalived 自动将服务器加入到服务器群中,这些工作全部自动完成,不需要人工干涉,需要人工做的只是修复故障的服务器。

这里使用的实现方式是单活方式,即主节点的 HAproxy 正常运行,备节点的会被停止。当主节点的出现故障时,备节点的 HAproxy 会自动启动。当主节点的恢复后,备节点的会自动停止。

安装keepalived
yum -y install keepalived

vim  /etc/keepalived/keepalived.conf :

主:  (10.64.16.123    l-rabbitmq1)

! Configuration File for keepalived
global_defs {
notification_email {
acassen@firewall.loc
failover@firewall.loc
sysadmin@firewall.loc
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 192.168.200.1
smtp_connect_timeout 30
router_id LVS_DEVEL
vrrp_skip_check_adv_addr
#vrrp_strict                         #要注释掉
vrrp_garp_interval 0
vrrp_gna_interval 0
}

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 eth0               # 监测网络端口,用ifconfig查看
	virtual_router_id 108        # 虚拟路由标识,同一个VRRP实例要使用同一个标识,主备机必须相同
	priority 100                 # 主备机取不同的优先级,确保主节点的优先级高过备用节点
	advert_int 1                 # VRRP Multicast广播周期秒数  用于设定主备节点间同步检查时间间隔
	authentication {
		auth_type PASS           # VRRP认证方式
        auth_pass 1234           # VRRP口令 主备机密码必须相同
	}
	track_script {               # 调用haproxy进程检测脚本,备节点不配置
		chk_haproxy
	}
	virtual_ipaddress {
		10.64.16.254             #vip
	}
	notify_master "/etc/keepalived/notify.sh master"      # 当前节点成为master时,通知脚本执行任务,一般用于启动某服务
	notify_backup "/etc/keepalived/notify.sh backup"      # 当前节点成为backup时,通知脚本执行任务,一般用于关闭某服务
}

备: (10.64.17.11      l-rabbitmq2)

! Configuration File for keepalived

global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
   # vrrp_strict                    #要注释掉
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_script chk_haproxy {
    script "service haproxy status" # 服务探测,返回0说明服务是正常的
    interval 1                      # 每隔1秒探测一次
    weight -2                       # 不正常时,权重-1,即haproxy上线,权重加2;下线,权重减2
}

vrrp_instance haproxy {
    state BACKUP            # 主机为MASTER,备机为BACKUP
    interface eth0         # 监测网络端口,用ifconfig查看
    virtual_router_id 108   # 虚拟路由标识,同一个VRRP实例要使用同一个标识,主备机必须相同
    priority 99            # 主备机取不同的优先级,确保主节点的优先级高过备用节点
    advert_int 1            # VRRP Multicast广播周期秒数  用于设定主备节点间同步检查时间间隔
    authentication {
        auth_type PASS      # VRRP认证方式
        auth_pass 1234      # VRRP口令 主备机密码必须相同
    }

    virtual_ipaddress {     # VIP 漂移地址 即集群IP地址
        10.64.16.254
    }
}

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     service keepalived restart

5.Haproxy负载代理

利用haproxy做负载均衡
安装haproxy
yum install haproxy

vim  /etc/haproxy/haproxy.cfg

在代码之后添加

#######################HAproxy监控页面#########################
listen http_front
        bind 0.0.0.0:1080           #监听端口
        stats refresh 30s           #统计页面自动刷新时间
        stats uri /haproxy?stats    #统计页面url
        stats realm Haproxy Manager #统计页面密码框上提示文本
        stats auth admin:1234      #统计页面用户名和密码设置
        #stats hide-version         #隐藏统计页面上HAProxy的版本信息

#####################RabbitMQ的管理界面###############################
listen rabbitmq_admin
    bind 10.64.16.254:15673
    server l-rabbitmq1 10.64.16.123:15672
    server l-rabbitmq2 10.64.17.11:15672

#####################RabbitMQ服务代理###########################################
listen rabbitmq_cluster 10.64.16.254:5673
    mode tcp
    stats enable
    balance roundrobin
    option tcpka
    option tcplog
    timeout client 3h
    timeout server 3h
    timeout connect 3h
    #balance url_param userid
    #balance url_param session_id check_post 64
    #balance hdr(User-Agent)
    #balance hdr(host)
    #balance hdr(Host) use_domain_only
    #balance rdp-cookie
    #balance leastconn
    #balance source //ip
    server   l-rabbitmq1 10.64.16.123:5672 check inter 5s rise 2 fall 3   #check inter 2000 是检测心跳频率,rise 2是2次正确认为服务器可用,fall 3是3次失败认为服务器不可用
    server   l-rabbitmq2 10.64.17.11:5672 check inter 5s rise 2 fall 3

启动

haproxy -f haproxy.cfg

重启动

service haproxy restart

6.搭建成功

ip a

主:

备:

http://10.64.16.254:1080/haproxy?stats 看一下监控页面,如果显示出正常就表明已经将 HAProxy 负载均衡配置好了

http://10.64.16.254:15673  rabbitmq管理页面

测试

生产者

import pika

connection = pika.BlockingConnection(    pika.ConnectionParameters(‘10.64.16.254‘,5673,virtual_host="/",credentials=pika.PlainCredentials(username="admin",password="1234"))  # 默认端口5672,可不写 )channel = connection.channel()channel.queue_declare(queue=‘ha_1‘)channel.basic_publish(exchange=‘‘,routing_key=‘ha_1‘,body=‘haha Hello World!‘) connection.close()  # 队列关闭

消费者

import pikaimport time

connection = pika.BlockingConnection(pika.ConnectionParameters(‘10.64.16.254‘,5673,virtual_host="/",credentials=pika.PlainCredentials(username="admin",password="1234"))  # 默认端口5672,可不写)channel = connection.channel()

channel.queue_declare(queue=‘ha_1‘)

def callback(ch, method, properties, body):  # 四个参数为标准格式 print(" [x] Received %r" % body)    time.sleep(15)    ch.basic_ack(delivery_tag = method.delivery_tag)    print("done")

channel.basic_consume(callback,queue=‘ha_1‘)

print(‘ [*] Waiting for messages. To exit press CTRL+C‘)channel.start_consuming()

原文地址:https://www.cnblogs.com/yuzhen0228/p/10489100.html

时间: 2024-08-30 17:04:14

rabbitmq高可用的相关文章

RabbitMQ(四):使用Docker构建RabbitMQ高可用负载均衡集群

本文使用Docker搭建RabbitMQ集群,然后使用HAProxy做负载均衡,最后使用KeepAlived实现集群高可用,从而搭建起来一个完成了RabbitMQ高可用负载均衡集群.受限于自身条件,本文使用VMware虚拟机的克隆功能克隆了两台服务器进行操作,仅作为一个demo,开发中可根据实际情况进行调整. 首先看下RabbitMQ高可用负载均衡集群长什么样子: 使用Docker构建RabbitMQ高可用负载均衡集群大概分为三个步骤: 启动多个(3个为例)RabbitMQ,构建RabbitMQ

RabbitMQ 高可用集群搭建及电商平台使用经验总结

面向EDA(事件驱动架构)的方式来设计你的消息 AMQP routing key的设计 RabbitMQ cluster搭建 Mirror queue policy设置 两个不错的RabbitMQ plugin 大型应用插件(Sharding.Rederation) Queue镜像失败手动同步 各集群配置同步方式(RabbitMQ export\import) 客户端连接方式(尽量采用AMQP组来动态链接) RabbitMQ 产线二次产品化封装(消息补偿.发送消息持久化.异常处理.监控页面.重复

RabbitMQ高可用方案总结

RabbitMQ的集群方案有以下几种: 1.普通的集群 exchange,buindling再所有的节点上都会保存一份,但是queue只会存储在其中的一个节点上,但是所有的节点都会存储一份queue的meta信息.因为这样有两个好处: 1)存储空间.如果每一个节点上都有全部的消息,有多少个节点就会有多少个消息总量的copy.加入一个队列的消息占用的空间是1G,那么三个节点就是3G 2) 性能.消息需要在节点之间传输会有很大的网络开销.如果消息设置了durable即持久化,还会增加很大的磁盘负载 

企业私有云之rabbitmq高可用

默认openstack使用rabbitmq做信息队列,如果想是云高可用,那么需要对每个涉及的组件都进行高可用配置,本文主要介绍如何使用rabbitmq做高可用. 高可用的方法为: 通过 Erlang 的分布式特性(通过 magic cookie 认证节点)进行 RabbitMQ 集群,各 RabbitMQ 服务为对等节点,即每个节点都提供服务给客户端连接,进行消息发送与接收. 这些节点通过 RabbitMQ HA 队列(镜像队列)进行消息队列结构复制.本方案中搭建 3 个节点,并且都是磁盘节点(

LVS+KeepAlived,RabbitMQ高可用负载均衡

最近团队准备对项目进行重构,其中用到了RabbitMQ,也考虑了几个方案,下边着重介绍在项目中即将采用的方案.关于RabbitMQ就不在这里详细说明,具体查看 RabbitMQ中文手册.直接看架构图: 如图所示: 前端采用keepalived+lvs实现高可用负载均衡, RabbitMQ HA 队列(镜像队列)进行消息队列结构复制.本方案中搭建两个节点,并且都是磁盘节点(所有节点状态保持一致,节点完全对等),只要有任何一个节点能够工作,RabbitMQ 集群对外就能提供服务.任务处理进程同时监控

RabbitMQ 高可用集群搭建

面向EDA(事件驱动架构)的方式来设计你的消息 AMQP routing key的设计 RabbitMQ cluster搭建 Mirror queue policy设置 两个不错的RabbitMQ plugin 大型应用插件(Sharding.Rederation) Queue镜像失败手动同步 各集群配置同步方式(RabbitMQ export\import) 客户端连接方式(尽量采用AMQP组来动态链接) RabbitMQ 产线二次产品化封装(消息补偿.发送消息持久化.异常处理.监控页面.重复

rabbitmq高可用实现

需求背景 1.业务按需求将一些功能拆分成异步任务,将消息放入队列进行处理.2.rabbitmq消息队列的使用,要求保证服务随时可用,并保证消息队列内的消息不丢失.rabibtmq在整个业务中的地位不比mysql低,高可用不可或缺. rabbitmq集群 rabbitmq简单介绍:   基于erlang语言开发,而erlang是一门分布式语言开发,适用于集群开发:rabbitmq自身也提供了多种集群方案:http://www.rabbitmq.com/ha.html    1.集群管理:没有明显的

使用glusterfs 作为 kubernetes PersistentVolume PersistentVolumeClaim 持久化仓库,高可用Rabbitmq,高可用mysql,高可用redis

glusterfs 怎么集群,网上一搜铺天盖地的 可利用这个特点做单节点高可用,因为K8S 哪怕节点宕机了 master 会在随意一台节点把挂掉的复活 当然我是在自己的环境下跑,经过网络的glusterfs,数据传输,等都有一定的性能损耗,对网络要求也特别高 小文件存储性能也不高等问题. 这里记录一下rabbitmq 单机高可用情景,mysql,mongodb, redis 等,万变不离其宗 事先创建好了 volume,卷名为 env-dev 随便找个客户机挂载 mount -t gluster

RabbitMQ 高可用之镜像队列

如果RabbitMQ集群只有一个broker节点,那么该节点的失效将导致整个服务临时性的不可用,并且可能会导致message的丢失(尤其是在非持久化message存储于非持久化queue中的时候).可以将所有message都设置为持久化,并且使用持久化的queue,但是这样仍然无法避免由于缓存导致的问题:因为message在发送之后和被写入磁盘并执行fsync之间存在一个虽然短暂但是会产生问题的时间窗.通过publisher的confirm机制能够确保客户端知道哪些message已经存入磁盘,尽