RabbitMQ秒杀场景应用

weixin_43973735

已于 2022-12-01 12:37:54 修改

阅读量816

点赞数 1

分类专栏： MQ 文章标签： rabbitmq

于 2022-12-01 12:31:45 首次发布

本文链接：https://blog.csdn.net/weixin_43973735/article/details/128130011

版权

MQ 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

1 RabbitMQ架构

在这里插入图片描述

2 交换机类型

2.1 fanout

扇型交换机将消息路由给绑定到它身上的所有队列，而不理会绑定的路由键。

ExchangeBuilder.fanoutExchange("fanout.exchange").durable(true).build() ;

2.2 direct

直连型交换机（direct exchange）是根据消息携带的路由键（routing key）将消息投递给对应绑定键的队列。

return ExchangeBuilder.directExchange("direct.exchange").durable(true).build() ;

2.3 topic

而Topic 的路由规则是一种模糊匹配，可以通过通配符满足一部分规则就可以传送。
:::info
它的约定是：
1）binding key 中可以存在两种特殊字符 * 与 # ，用于做模糊匹配，其中 * 用于匹配一个单词， # 用于匹配多个单词（可以是零个）
2）routing key 为一个句点号 “.” 分隔的字符串（我们将被句点号 “. ” 分隔开的每一段独立的字符串称为一个单词），如“topic.email”、“topic.sms"、binding key 与 routing key 一样也是句点号 “.” 分隔的字符串。
:::

ExchangeBuilder.topicExchange("topic.exchange").durable(true).build() ;

2.4 header

headers 类型的 Exchange 不依赖于 routing key 与 binding key 的匹配规则来路由消息，而是根据发送的消息内容中的 headers 属性进行匹配。

//创建交换机
ExchangeBuilder.headersExchange("headers.exchange").durable(true).build() ;
//创建队列
QueueBuilder.durable("headers.queue_01").build() ;
//绑定交换机和队列
HashMap<String , Object> headersRoutingKeyHashMap = new HashMap<String , Object>() ;
headersRoutingKeyHashMap.put("key1" , "value1");
headersRoutingKeyHashMap.put("key2" , "value2");
//BindingBuilder.bind(queue).to(exchange).whereAny(headersRoutingKeyHashMap).match();
BindingBuilder.bind(queue).to(exchange).whereAll(headersRoutingKeyHashMap).match();
//发送消息
String message = "headers exchanges message" ;
MessageProperties messageProperties = new MessageProperties() ;
messageProperties.setHeader("key1" , "value1");
messageProperties.setHeader("key2" , "value2");
Message obj = new Message(message.getBytes() , messageProperties) ;
rabbitTemplate.convertAndSend("headers.exchange" , "" , obj);

3 未支付定单回退

3.1 架构

3.2 队列ttl+死信exchange实现延时队列

1）给消息和队列设置TTL（生存时间）
队列设置：x-message-ttl=60000（队列中所有消息都只有60s存活时间）
指定消息设置：expire=60000 指定消息只有60s存活时间
2）死信exchange
消费者使用 basic.reject 或 basic.nack 并将requeue参数设置为 false 来否定的消息
3）使用介绍
①创建一个接收死信消息的队列queue_dlx;
②创建一个死信交换机exchange_dlx,并将其与死信消息队列绑定；
③创建一个延时队列queue_delay和一个direct交换机并将其二者绑定,但是不提供消费者；
④延时消息先发送到direct交换机然后路由到延时队列，超过存活时间后会转发至死信交换机然后路由到queue_dlx队列，订阅次消息队列即可消费其延时消息。
4）优缺点
优点：
①支持镜像队列复制，实现高可用
②支持大量消息（成千上万）
缺点
①只能支持固定延迟等级的消息
②使用较复杂，需要声明一堆队列和交换机

3.2 RabbitMQ延时插件

1）下载并安装延时插件
①地址：https://github.com/rabbitmq/rabbitmq-delayed-message-exchange
②解压后放到RabbitMQ安装补录的plugins下
③开启延时消息插件：rabbitmq-plugins enable rabbitmq_delayed_message_exchange
④重启RabbitMQ
2）使用
①声明一个type为“x-delayed-message”的交换机，并且在其可选参数下配置一个key为“x-delayed-type”,值为交换机类型（fanout/direct/topic/header）的属性；
②声明一个队列绑定到交换机；
③在发送消息的时候header里添加一个key为“delay”,值为过期时间的属性，单位毫秒。
优点：
①使用较为方便，基本上可以任意延时时间，并且不需要创建大量交换机和队列。
缺点：
①延时不可靠，存在消息数量较大或使用很久后延迟不准确（会推迟），见 issues#72
②无备份机制，延时消息存在单个节点磁盘中
③不支持ram类型的节点（数据得存磁盘里面）
④增加大量内存的占用（经测试发现，发送大量延时消息后，rabbitmq内存占用明显增高，比普通消息还要高很多那种。）
⑤安装插件需要重启

4 RabbitMQ消息可靠性传输

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bdFocFqv-1669868741623)(https://cdn.nlark.com/yuque/0/2022/jpeg/572917/1669283157343-d5709696-bd0f-4168-9839-0bd98dd4373b.jpeg)]

4.1 第一种情况

开启生产者确认机制

4.2 第二种情况

开启数据持久化，发送消息时携带模式，springboot默认是持久化的，这样发送到服务端立马就会被持久化到磁盘上。

message.getMessageProperties().setDeliveryMode(MessageDeliveryMode.PERSISTENT);

4.2.1 消息存储机制

1）非持久化的消息也可能存到磁盘中，在内存吃紧的时候会将消息存入磁盘；
2）小消息存入index大的存入msg_store,可以通过queue_index_embed_msgs_below；

4.2.2 队列结构以及消息状态

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZeIF8x75-1669868741626)(https://cdn.nlark.com/yuque/0/2022/jpeg/572917/1669285373081-8cd81e8b-0cb0-4619-9fd7-cd689e294b93.jpeg)]
消息状态：
:::info
alpha：消息内容(包括消息体、属性和headers)和消息索引都存在内存中（消耗内存最多，CPU消耗最
少）
beta：消息内容保存在磁盘中，消息索引都存在内存中（只需要一次IO操作就可以读取到消息）
gamma：消息内容保存在磁盘中，消息索引在磁盘和内存中都存在（只需要一次IO操作就可以读取到
消息）
delta：消息内容和消息索引都在磁盘中（消耗内存最小，但是会消耗更多的CPU和磁盘的IO操作）
:::
RabbitMQ在运行时会根据统计的消息传送速度定期计算一个当前内存中能保存的最大消息数量，如果alpha状态的消息数量大于此值时，就会引起消息状态转换，多余的消息可能会转到beta状态。
消息流转：

减少堆积方案
:::info
1、增加prefetch_count的值，设置消费者存储未确认的消息的最大值
2、消费者进行multiple ack，降低ack带来的开销
:::

4.3 第三种情况

开启消费消息确认机制。

5 幂等性保证方案

1）写数据库，先根据主键查一下，如果有了就update，没有insert；
2）写Redis，天然幂等直接set；
3）数据库中设置唯一键，重复插入数据会报错，不会导致数据库中出现脏数据；
4）记录消息消费日志，如果消息消费过就不再重复消费。

6 高可用方案

6.1 普通集群

6.1.1 普通集群架构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mCnrXKC3-1669868741632)(https://cdn.nlark.com/yuque/0/2022/jpeg/572917/1669609699629-1bcbf62f-81d4-4f6d-a542-a95f664a990c.jpeg)]
1）当创建队列时只会在单节点上创建队列进程并包含完整的队列信息（元数据，状态，内容）。这样只有宿主节点知道队列的完整信息，其他队列只知道队列的元数据信息。
2）交换机知识一个名称和绑定列表，没有自己独立的进程，并且交换机的元数据信息会在多个RabbitMQ及诶按上进行共享。
3）客户端与集群创建连接时，只需要连接集群中任意一个节点即可。

6.1.2 普通集群搭建

1）拉取镜像
docker pull rabbitmq:3.6.10-management
2）创建容器
:::info
docker run -di --network=rabbitmq-net --ip=172.20.0.10 --hostname=rabbitmq-node01 --name=rabbitmq_01 -p 15673:15672 -p 5673:5672 --privileged=true -e RABBITMQ_ERLANG_COOKIE=‘rabbitcookie’ rabbitmq:3.9-management /bin/bash

docker run -di --network=rabbitmq-net --ip=172.20.0.11 --hostname=rabbitmq-node02 --name=rabbitmq_02 -p 15674:15672 -p 5674:5672 --privileged=true -e RABBITMQ_ERLANG_COOKIE=‘rabbitcookie’ rabbitmq:3.9-management /bin/bash

docker run -di --network=rabbitmq-net --ip=172.20.0.12 --hostname=rabbitmq-node03 --name=rabbitmq_03 -p 15675:15672 -p 5675:5672 --privileged=true -e RABBITMQ_ERLANG_COOKIE=‘rabbitcookie’ rabbitmq:3.9-management /bin/bash
参数说明：Erlang Cookie值必须相同，也就是RABBITMQ_ERLANG_COOKIE参数的值必须相同。因为 RabbitMQ是用Erlang实现的，Erlang Cookie相当于不同节点之间相互通讯的秘钥，Erlang节点通过交换Erlang Cookie获得认证。

:::
3）配置hosts文件，让各个节点都能识别对方存在。再系统中编辑、/etc/hosts文件添加ip地址和节点名称映射信息。
进入容器
docker exec -it rabbitmq_01 /bin/bash
配置hosts
172.20.0.10 rabbitmq-node01
172.20.0.11 rabbitmq-node02
172.20.0.12 rabbitmq-node03
4）启动RabbitMQ并查看状态
:::info
rabbitmq-server -detached #启动
rabbitmqctl status #查看节点信息
rabbitmqctl cluster_status #查看集群节点状态
:::

注意：此时可以通过浏览器访问RabbitMQ的后端管理系统，但是RabbitMQ默认提供的guest用户不支持远程访问。因此需要创建用户，并对其授权
:::info
rabbitmqctl add_user admin admin # 添加用户，用户名为admin，密码为admin
rabbitmqctl list_users #查看rabbitmq的用户列表
rabbitmqctl set_user_tags admin administrator #给admin用户设置管理员权限
rabbitmqctl delete_user_admin #删除admin用户
rabbitmqctl stop_app #停止rabbitmq服务
rabbitmqctl stop #会将rabbitmq的服务和erlang虚拟机一同关闭
:::
5）同步cookie
集群中的Rabbitmq节点需要通过交换密钥令牌以获得相互认证，如果节点的密钥令牌不一致，那么在配置节点时就会报错。获取某一个节点上的/var/lib/rabbitmq/.erlang.cookie文件，然后将其复制到其他的节点上。我们以node01节点为基准，进行此操作。
:::info
docker cp rabbitmq_01:/var/lib/rabbitmq/.erlang.cookie .
docker cp .erlang.cookie rabbitmq_02:/var/lib/rabbitmq
docker cp .erlang.cookie rabbitmq_03:/var/lib/rabbitmq
:::
6）建立集群关系，将node02和node03都加入到集群中来
:::info

进入到rabbitmq-node02中

rabbitmq-server -detached #启动
rabbitmqctl stop_app # 关闭rabbitmq服务
rabbitmqctl reset # 进行重置
rabbitmqctl join_cluster rabbit@rabbitmq-node01 # rabbitmq-node01为节点1的主机名称
rabbitmqctl start_app # 启动rabbitmq节点

进入到rabbitmq-node03中

rabbitmq-server -detached #启动
rabbitmqctl stop_app # 关闭rabbitmq服务
rabbitmqctl reset # 清空节点的状态，并将其恢复都空白状态，当设置的节点时集群
中的一部分，该命令也会和集群中的磁盘节点进行通讯，告诉他们该节点正在离开集群。不然集群
会认为该节点处理故障，并期望其最终能够恢复过来
rabbitmqctl join_cluster rabbit@rabbitmq-node01 # rabbitmq-node01为节点1的主机名称
rabbitmqctl start_app # 启动rabbitmq节点
:::

6.1.3 节点类型

使用rabbitmqctl cluster_status命令查看集群状态是可以看到Disk Nodes（磁盘节点）这一项信息，这些就是集群中的磁盘节点。
节点分为两种：磁盘节点和内存节点。
内存节点将所有的队列，交换机，绑定关系、用户、权限和vhost的元数据定义都存储在内存中，而磁盘节点则将这些信息存储到磁盘中。单节点的集群中必然只有磁盘类型的节点，否则当重启Rabbitmq之后，所有关于系统配置信息都会丢失。不过在集群中，可以选择配置部分节点为内存节点，这样可以获得更高的性能。

6.1.3.1 节点类型变更

:::info
在配置节点加入集群时可以指定节点类型
rabbitmqctl join_cluster rabbit@rabbitmq-node01 --ram
加入后可以修改节点类型为disc或ram
rabbitmqctl change_cluster_node_type disc
例如将一个节点改为内存节点：
rabbitmqctl stop_app
rabbitmqctl change_cluster_node_type ram
rabbitmqctl start_app
:::

6.1.3.1 节点选择

Rabbitmq只要求在集群中至少有一个磁盘节点，其他所有的节点可以是内存节点。当节点加入或者离开集群时，它们必须将变更通知到至少一个磁盘节点。如果只有一个磁盘节点，而且不凑巧它刚好崩溃了，那么集群可以继续接收和发送消息。但是不能执行创建队列，交换机，绑定关系、用户已经更改权限、添加和删除集群节点操作了。也就是说,如果集群中唯一的磁盘节点崩溃了，集群仍然可以保持运行，但是直到将该节点恢复到集群前，你无法更改任何东西，所以在创建集群的时候应该保证至少有两个或者多个磁盘节点。当内存节点重启后，它会连接到预先配置的磁盘节点，下载当前集群元数据的副本。当在集群中添加内存节点的时候，确保告知所有的磁盘节点（内存节点唯一存储到磁盘中的元数据信息是磁盘节点的地址）。只要内存节点可以找到集群中至少一个磁盘节点，那么它就能在重启后重新加入集群中。

6.1.4 负载均衡

当前情况下客户端可以连接集群中任意一个节点，这就导致如果多个客户端连接同一节点导致这一节点负载过重而其他节点资源浪费，所以需要添加负载均衡。

6.1.4.1 架构

6.1.4.2 HAProxy实现负载均衡架构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Qd4VpVti-1669868741635)(https://cdn.nlark.com/yuque/0/2022/jpeg/572917/1669640349855-e3a6e346-61f5-4b92-b408-4cc1be4d5ef8.jpeg)]

6.1.4.3 搭建负载均衡架构

6.1.4.3.1 安装haproxy

1）拉取haproxy镜像
docker pull haproxy:1.7
2）创建一个HAProxy的配置文件haproxy.cfg

global
 #工作目录
 chroot /usr/local/etc/haproxy
 #日志文件，使用rsyslog服务中local5日志设备（/var/log/local5），等级info
 log 127.0.0.1 local5 info
 #守护进程运行
 daemon
defaults
	log 127.0.0.1 local0 err	#[err warning info debug]
	mode http					#默认的模式mode { tcp|http|health }，tcp是4层，http是7层，health只会返回OK
	retries 2					#两次连接失败就认为是服务器不可用
	option redispatch			#当serverId对应的服务器挂掉后，强制定向到其他健康的服务器
	option abortonclose			#当服务器负载很高的时候，自动结束掉当前队列处理比较久的链接
	option dontlognull			#日志中不记录负载均衡的心跳检测记录
	maxconn 4096				#默认的最大连接数
	timeout connect 50000ms		#连接超时
	timeout client 300000ms		#客户端超时
	timeout server 300000ms		#服务器超时
	#timeout check 2000			#=心跳检测超时
######## 监控界面配置 ################# 
listen admin_stats
	#监控界面的访问的IP和端口
	bind 0.0.0.0:8888
	#访问协议
	mode http
	#URI相对地址
	stats uri /dbs
	#统计报告格式
	stats realm Global\ statistics
	#登陆帐户信息
	stats auth admin:admin
# rabbitmq管理界面配置
listen proxy_rabbitmq_web
	#访问的IP和端口
	bind 0.0.0.0:5000
	#网络协议
	mode tcp
	#负载均衡算法（轮询算法）
	#轮询算法：roundrobin
	#权重算法：static-rr
	#最少连接算法：leastconn
	#请求源IP算法：source
	balance roundrobin
	# 这里是容器中的IP地址，由于配置的是轮询roundrobin，weight 权重其实没有生效
	server rabbitmq_01 172.20.0.10:15672 check weight 1 maxconn 2000
	server rabbitmq_02 172.20.0.11:15672 check weight 1 maxconn 2000
	server rabbitmq_03 172.20.0.12:15672 check weight 1 maxconn 2000
	# 使用keepalive检测死链
	option tcpka
# rabbitmq服务代理，负载均衡配置
listen proxy_rabbitmq
	#访问的IP和端口
	bind 0.0.0.0:5010
	#网络协议
	mode tcp
	#负载均衡算法（轮询算法）
	#轮询算法：roundrobin
	#权重算法：static-rr
	#最少连接算法：leastconn
	#请求源IP算法：source
	balance roundrobin
	# 这里是容器中的IP地址，由于配置的是轮询roundrobin，weight 权重其实没有生效
	server rabbitmq_01 172.20.0.10:5672 check weight 1 maxconn 2000
	server rabbitmq_02 172.20.0.11:5672 check weight 1 maxconn 2000
	server rabbitmq_03 172.20.0.12:5672 check weight 1 maxconn 2000
	# 使用keepalive检测死链
	option tcpka

3）创建haproxy容器
:::info
docker run -di --network=rabbitmq-net --ip=172.20.0.6 -p 4001:8888 -p 5001:5000 -p 5010:5010 -v /usr/local/haproxy/haproxy-01:/usr/local/etc/haproxy --name=haproxy_01 --privileged=true haproxy:1.7 /bin/bash
docker run -di --network=rabbitmq-net --ip=172.20.0.7 -p 4002:8888 -p 5002:5000 -p 5011:5010 -v /usr/local/haproxy/haproxy-02:/usr/local/etc/haproxy --name=haproxy_02 --privileged=true haproxy:1.7 /bin/bash
:::
4）进入容器启动HAProxy
:::info
docker exec -it haproxy_01 /bin/bash # 进入容器
haproxy -f /usr/local/etc/haproxy/haproxy.cfg # 启动容器
:::
5）通过浏览器就可以访问haproxy的后端管理界面了： http://192.168.23.131:4002/dbs,然后输入配置的用户名和密码就可以看到HAProxy的管理页面

6.1.4.3.2 HAProxy容器中安装keepalived

1）进入haprox_01服务
docker exec -it haproxy_01 /bin/bash
2）安装keepalived软件和其他软件
:::info
apt-get update # 更新软件列表,apt-get源不太稳定，建议多执行几次
apt-get install keepalived # 安装keepalived软件
apt-get install net-tools # 安装ifconfig命令
:::
3）创建一个keepalived.conf文件
vim /etc/keepalived/keepalived.conf，内容如下所示：

! Configuration File for keepalived
vrrp_instance VI_1 {   
	state MASTER												# 标示状态为MASTER 备份机为BACKUP
	interface eth0											# 定义虚拟网卡
	virtual_router_id 100								# 定义组vriid， 同一组中virtual_router_id必须相同
	priority 100												# MASTER权重要高于BACKUP 比如BACKUP为99
	advert_int 1												# MASTER 与 BACKUP 负载均衡器之间同步检查的时间间隔，单位是秒
	authentication {										# 定义组用户密码
		auth_type PASS
		auth_pass  123456
	}
    
	virtual_ipaddress {									#定义docker内ip地址，必须要在和haproxy同一个网段
		172.20.0.5
	}
}

4）启动keepalived
service keepalived start
5）查看eth0是否已经绑定了虚拟ip
ip add show eth0
6）配置haproxy_02容器中的keepalived

! Configuration File for keepalived
vrrp_instance VI_1 {
	state BACKUP									# 标示状态为MASTER 备份机为BACKUP
	interface eth0								# 定义虚拟网卡
	virtual_router_id 100					# 定义组vriid， 同一组中virtual_router_id必须相同
	priority 99										# MASTER权重要高于BACKUP 比如BACKUP为99
	advert_int 1									# MASTER 与 BACKUP 负载均衡器之间同步检查的时间间隔，单位是秒
	authentication {							# 定义组用户密码
		auth_type PASS
		auth_pass 123456
	}
	virtual_ipaddress {						#定义docker内ip地址，必须要在和haproxy同一个网段
		172.20.0.5
	}
}

6.1.4.3.3 宿主机中安装keepalived

1）安装keepalived
yum install -y keepalived
2）更改keepalived的配置文件的内容
/etc/keepalived/keepalived.conf # 清空原有配置文件的内容
vim /etc/keepalived/keepalived.conf # 编辑配置文件，配置文件中的内容如下所示

! Configuration File for keepalived
vrrp_instance VI_1 {
	state MASTER
	interface ens33					#这里是宿主机的网卡，可以通过ip a查看当前自己电脑上用的网卡名是哪个
	virtual_router_id 50
	priority 100
	advert_int 1
	authentication {
		auth_type PASS
		auth_pass 1111
	}
	virtual_ipaddress {			#可以不用指定虚拟ip
	 	 
	}
}
#虚拟服务器地址 IP 对外提供服务的端口
virtual_server 192.168.0.187 4000 {
	delay_loop 3		#健康检查时长 单位秒
	lb_algo rr			# 负载均衡算法rr|wrr|lc|wlc|lblc|sh|dh：LVS调度算法
	lb_kind NAT			# 负载均衡转发规则
	persistence_timeout 50 	# http服务会话时长 单位秒
	protocol TCP	 	 		# 健康检查用的是TCP还是UDP
	 
	#对应后端真实的docker服务的ip地址和端口号
	real_server 172.20.0.5 8888 {		#对应HAProxy的虚拟ip地址和后端管理系统端口
		weight 1
	}
 
}
#rabbitmq的web管理端的虚拟服务器
virtual_server 192.168.0.187 15670 {
	delay_loop 3											# 健康检查时长 单位秒
	lb_algo rr	 	 	 	 	 	 	 	 	 	   # 负载均衡算法rr|wrr|lc|wlc|lblc|sh|dh：LVS调度算法
	lb_kind NAT	 	 	 	 	 	 	 	 	 	  # 负载均衡转发规则
	persistence_timeout 50	 	 	 	 	 	 	   # http服务会话时长 单位秒
	protocol TCP	 	 	 	 	 	 	 	 	 	 # 健康检查用的是TCP还是UDP
	 # 对应后端真实的docker服务的ip地址和端口号
	real_server 172.20.0.5 5000 {	 	 	 	 	 # 对应HAProxy的虚拟ip地址和后端管理系统端口
	 	weight 1
	}
}
# rabbitmq的虚拟服务器
virtual_server 192.168.0.187 5670 {
	delay_loop 3
	lb_algo rr
	lb_kind NAT
	persistence_timeout 50
	protocol TCP
	 # 对应后端真实的docker服务的ip地址和端口号
	real_server 172.20.0.5 5010 {	 	 	 	 	 # 对应HAProxy的虚拟ip地址和后端rabbitmq的监听端口
	 	weight 1
	}
}

3）启动keepalived服务，关闭防火墙
systemctl start keepalived
systemctl status firewalld.service

6.1.5 集群监控

1）开启rabbitmq的tracing插件，查看消息投递过程
rabbitmq-plugins enable rabbitmq_tracing
2）API接口进行二次开发，地址：http://192.168.23.131:15672/api/的Web页面来获取更多的其他接口信息。

6.2 镜像集群

6.2.1 镜像集群架构与选举master

每一个配置镜像的队列都包含一个master和若干个slave，如果一个节点失效了能自动切换到镜像中另一个节点上以保证服务可用性。

6.2.1 工作模式

slave节点在正常情况下只备份，不直接对外提供服务，当有请求到slave节点时，slave会向master请求拿到数据再转发给客户端。
1）客户端连接主节点
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dPNiVxyd-1669868741641)(https://cdn.nlark.com/yuque/0/2022/jpeg/572917/1669801427977-6b96f7e1-f02a-4ccb-99da-1f731b23e489.jpeg)]
2）客户端连接从节点

6.2.2 配置

1）命令添加镜像策略
:::info
rabbitmqctl set_policy [-p ] [–priority ] [–apply-to ]
:::
指令详情

参数名	描述
-p	可选参数，针对指定vhost下的exchange或queue
–priority	可选参数，policy（策略）的优先级
–apply-to	可选参数，策略使用的对象类型，其值可为“queue”，“exchange”或“all”默认“all”
name	policy（策略）的名称
pattern	匹配模式（正则表达式）
definition	镜像定义，json格式，包括三部分（ha-mode,ha-params,ha-sync-mode）

definition参数详情

参数名称	描述
ha-mode	镜像队列模式，值可以是“all”,“exactly”或“nodes”：
all:表示在集群所有节点上镜像；
exactly：在指定个数的节点上镜像，节点个数由ha-params指定；
nodes：在指定节点上进行镜像，节点名称通过ha-params指定。
ha-params	ha-mode模式需要用到的参数：exactly模式下为数字表示节点数量，nodes下为节点列表，表示需要镜像的节点。
ha-sync-mode	镜像队列中消息的同步方式，其值为“automatic”或“manually”。

例如对列名称为hello开头的所有队列镜像，并且在集群的节点rabbit@10.18.195.57上进行镜像，对垒消息自动同步：
:::info
rabbitmqctl set_policy --apply-to queues hello-ha “^hello” ‘{“ha-mode”:“nodes”,“ha-params”:[“rabbit@10.18.195.57”],“ha-sync-mode”:“automatic”}’
:::
2）rabbitmq后台管理添加镜像策略
在这里插入图片描述