RabbitMQ
1. 消息队列
1.1 MQ的相关概念
1.1.1 什么是MQ
MQ(message queue)
,从字面意思上看,本质是个队列,FIFO
先入先出,只不过队列中存放的内容是message
而已,还是一种跨进程的通信机制,用于上下游传递消息。在互联网架构中,MQ
是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了MQ
之后,消息发送上游只需要依赖MQ
,不用依赖其他服务。
1.1.2 为什么要用MQ
流量消峰:举个例子,如果订单系统最多能处理一万次订单,这个处理能力应付正常时段的下单时绰绰有余,正常时段我们下单一秒后就能返回结果。但是在高峰期,如果有两万次下单操作系统是处理不了的,只能限制订单超过一万后不允许用户下单。使用消息队列做缓冲,我们可以取消这个限制,把一秒内下的订单分散成一段时间来处理,这时有些用户可能在下单十几秒后才能收到下单成功的操作,但是比不能下单的体验要好。
应用解耦:以电商应用为例,应用中有订单系统、库存系统、物流系统、支付系统。用户创建订单后,如果耦合调用库存系统、物流系统、支付系统,任何一个子系统出了故障,都会造成下单操作异常。当转变成基于消息队列的方式后,系统间调用的问题会减少很多,比如物流系统因为发生故障,需要几分钟来修复。在这几分钟的时间里,物流系统要处理的内存被缓存在消息队列中,用户的下单操作可以正常完成。当物流系统恢复后,继续处理订单信息即可,中单用户感受不到物流系统的故障,提升系统的可用性。
异步处理:有些服务间调用是异步的,例如A调用B,B需要花费很长时间执行,但是A需要知道B什么时候可以执行完,以前一般有两种方式,A过一段时间去调用B的查询api查询。或者A提供一个callback api,B执行完之后调用apii通知A服务。这两种方式都不是很优雅。使用消息总线,可以很方便解决这个问题 ,A调用B服务后,只需要监听B处理完成的消息,当B处理完成后,会发送一条消息给
MQ
,MQ
会将此消息转发给A服务。这样A服务既不用循环调用B的查询api,也不用提供callback api。同样B服务也不用做这些操作。A服务还能及时的得到异步处理成功的消息。
1.1.3 MQ的分类
ActiveMQ
优点:单机吞吐量万级,时效性毫秒级,可用性高,基于主从架构实现高可用性,消息丢失概率低
缺点:官方社区现在对ActiveMQ5.x维护越来越少,高吞吐量场景较少使用。
Kafka
大数据的杀手锏,谈到大数据领域内的消息传输,则绕不开Kafk,这款为大数据而生的消息中间件以其百万级TPS的吞吐量名声大噪,迅速成为大数据领域的宠儿,在数据采集、传输、存储的过程中发挥着举足轻重的作用。目前已经被
LinkedIn,Uber,Twitter,Netflix
等大公司所采纳。优点:性能卓越,单机写入TPS约在百万条/秒,最大的优点,就是吞吐量高。时效性毫秒级可用性目常高,
kfka
是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用,消费者采用Pull
方式获取消息,消息有序,通过控制能够保证所有消息被消费且仅被消费一次;有优秀的第三方Kafka Web
管理界面Kafka-Manager
;在日志领域比较成熟,被多家公司和多个开源项目使用;功能支持:功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用。缺点:
Kafka
单机超过64个队列/分区,Load
会发生明显的飙高(指CPU飙高)现象,队列越多,load
越高,发送消息响应时间变长,使用短轮询方式,实时性取决于轮询间隔时间,消费失败不支特重试;支特消息顺序,但是一台代理宕机后,就会产生消息乱序,社区更新较慢;RocketMQ
RocketMQ
出自阿里巴巴的开源产品,用Java语言实现,在设计时参考了Kafka
,并做出了自己的一些改进。被阿里巴巴广泛应用在订单,交易,充值,流计算,消息推送,日志流式处理,binglog.分发等场景。优点:单机吞吐量十万级,可用性非常高,分布式架构,消息可以做到0丢失,
MQ
功能较为完善,还是分布式的,扩展性好,支持10亿级别的消息堆积,不会因为堆积导致性能下降,源码是java我们可以自己阅读源码,定制自己公司的MQ
缺点:支持的客户端语言不多,目前是java及c++,其中c++不成熟;社区活跃度一般,没有在
MQ
核心中去实现JMS
等接口,有些系统要迁移需要修改大量代码RabbitMQ
2007年发布,是一个在
AMQP
(高级消息队列协议)基础上完成的,可复用的企业消息系统,是当前最主流的消息中间件之。优点:由于
erlang
语言的高并发特性,性能较好;吞吐量到万级,MQ
功能比较完备,健壮、稳定、易用、跨平台、支持多种语言如:Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP
等,支持AJAX文档齐全;开源提供的管理界面非常棒,用起来很好用,社区活跃度高;更新频率相当高 https://www.rabbitmq.com/news.html缺点:商业版需要收费,学习成本较高
1.1.4 MQ的选择
Kafka
Kafka
主要特点是基于Pull
的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输,适合产生大量数据的互联网服务的数据收集业务。大型公司建议可以选用,如果有日志采集功能,肯定是首选kafka
了。RocketMQ
天生为金融互联网领域而生,对于可靠性要求很高的场景,尤其是电商里面的订单扣款,以及业务削峰,在大量交易涌入时,后端可能无法及时处理的情况。
RoketMQ
在稳定性上可能更值得信赖,这些业务场景在阿里双11已经经历了多次考验,如果你的业务有上述并发场景,建议可以选择RocketMQ
RabbitMQ
结合
erlang
语言本身的并发优势,性能好时效性微秒级,社区活跃度也比较高,管理界面用起来十分方便,如果你的数据量没有那么大,中小型公司优先选择功能比较完备的RabbitMQ
。
1.2 RabbitMQ
1.2.1 RabbitMQ的概念
RabbitMQ
是一个消息中间件:它接受并转发消息。你可以把它当做一个快递站点,当你要发送一个包裹时,你把你的包裹放到快递站,快递员最终会把你的快递送到收件人那里,按照这种逻辑RabbitMQ
是一个快递站,一个快递员帮你传递快件。RabbitMQ
与快递站的主要区别在于,它不处理快件而是接收,存储和转发消息数据。
1.2.2 四大核心概念
生产者
产生数据发送消息的程序是生产者
交换机
交换机是
RabbitMQ
非常重要的一个部件,一方面它接收来自生产者的消息,另一方面它将消息推送到队列中。交换机必须确切知道如何处理它接收到的消息,是将这些消息推送到特定队列还是推送到多个队列,亦或者是把消息丢弃,这个得有交换机类型决定队列
队列是
RabbitMQ
内部使用的一种数据结构,尽管消息流经RabbitMQ
和应用程序,但它们只能存储在队列中。队列仅受主机的内存和磁盘限制的约束,本质上是一个大的消息缓冲区。许多生产者可以将消息发送到一个队列,许多消费者可以尝试从一个队列接收数据。这就是我们使用队列的方式消费者
消费与接收具有相以的含义。消费者大多时候是一个等待接收消息的程序。请注意生产者,消费者和消息中间件很多时候并不在同一机器上。同一个应用程序既可以是生产者又是可以是消费者。
1.2.3 RabbitMQ核心部分
- 简单模式(Simple Mode): 简单模式是最基本的消息传递模式,也称为点对点模式。在该模式下,消息的生产者将消息发送到一个队列中,然后消费者从该队列中接收并处理消息。每个消息只能被一个消费者接收。
- 工作队列模式(Work Queue Mode): 工作队列模式也称为任务队列模式。在该模式下,一个生产者将消息发送到一个工作队列中,多个消费者共享该队列,并竞争消费队列中的消息。每个消息只能被一个消费者接收,确保任务在多个工作者之间进行分配。
- 发布/订阅模式(Publish/Subscribe Mode): 发布/订阅模式通过使用交换机(Exchange)实现广播消息给多个消费者。在该模式下,生产者将消息发送到交换机,交换机会将消息广播给所有与之绑定的队列,然后每个消费者都可以从自己的队列中接收消息。
- 路由模式(Routing Mode): 路由模式通过使用直连交换机(Direct Exchange)实现消息的有选择性地路由到特定的队列。在该模式下,生产者将消息发送到交换机,并指定消息的路由键(Routing Key),交换机会根据路由键将消息路由到与之匹配的队列中。
- 主题模式(Topic Mode): 主题模式通过使用主题交换机(Topic Exchange)实现对消息的灵活路由。在该模式下,生产者将消息发送到交换机,并指定一个主题(Topic),交换机会根据主题进行模式匹配,将消息路由到与之匹配的队列中。
- 发布确认模式(Publish-Confirm Mode): 在发布确认模式中,生产者将消息发送到RabbitMQ服务器,并等待服务器发送确认消息。只有在收到确认消息后,生产者才能确定消息已经成功地被RabbitMQ服务器接收和持久化。如果消息发送失败或丢失,生产者可以进行相应的处理,例如重新发送消息或记录日志。
1.2.4 各个名词介绍
Broker:接收和分发消息的应用,RabbitMQ Server
就是Message Broker
Virtual host(虚拟主机):出于多租户和安全因素设计的,把AMQP
的基本组件划分到一个虚拟的分组中,类似于网络中的namespace
概念。当多个不同的用户使用同一个RabbitMQ server
提供的服务时,可以划分出多个vhost(虚拟主机)
,每个用户在自己的vhost
创建exchange/queue
等
Connection:publisher/consumer
和broker
之间的TCP
连接
Channel(信道):如果每一次访问RabbitMQ
都建立一个Connection
,在消息量大的时候建立TCP Connection
的开销将是巨大的,效率也较低。Channel
是在connection
内部建立的逻辑连接,如果应用程序支持多线程,通常每个thread
创建单独的channel
进行通讯,AMQP method
包含了channel id
帮助客户端和message broker
识别channel
,所以channel
之间是完全隔离的。Channel
作为轻量级的 Connection
极大减少了操作系统建立TCP connection
的开销
Exchange(交换机):message
到达broker
的第一站,根据分发规则,匹配查询表中的routing key
,分发消息到queue
中去。常用的类型有:direct(point-to-point),topic(publish-subscribe)and fanout(multicast)
Queue:消息最终被送到这里等待consumer
取走
Binding:exchange
和queue
之间的虚拟连接,binding
中可以包含routing key
,Binding
信息被保存到exchange
中的查询表中,用于message
的分发依据(根据Binding的routing key发送消息到指定的交换机中——即交换机的routing key要和Binding的routing key一致)
1.2.5 安装
首先说明,嫌麻烦的可以直接使用docker拉取镜像然后部署,如果你熟悉docker操作的话。
文件上传
下载者两个文件,之后上传到
/usr/local/software
目录下(如果没有software需要自己创建)安装文件(分别按照以下顺序安装)
rpm -ivh erlang-25.2.3-1.el8.x86_64.rpm yum install -y socat rpm -ivh rabbitmq-server-3.8.8-1.el7.noarch.rpm
常用命令(按照以下顺序执行)
添加开机启动
RabbitMQ
服务chkconfig rabbitmq-server on # 或者 systemctl enable rabbitmq-server #我喜欢用这个命令
启动服务
/sbin/service rabbitmq-server start #或者 systemctl start rabbitmq-server #我喜欢用这个命令
查看服务状态
/sbin/service rabbitmq-server status # 或者 systemctl status rabbitmq-server #我喜欢用这个命令
停止服务(选择执行)
/sbin/service rabbitmq-server stop # 或者 systemctl stop rabbitmq-server#我喜欢用这个命令
开启web管理插件
rabbitmq-plugins enable rabbitmq_management
重启服务
# 重启rabbitmq服务 systemctl restart rabbitmq-server
用默认账号密码(guest)访问地址
http:/你自己虚拟机的IP地址:15672/
出现权限问题rabbitmq
有一个默认的账号密码guest
,但该情况仅限于本机localhost进行访问,而此刻我的RabbitMQ
服务是在虚拟机上,我使用本机来访问,所以才出现下面的权限问题,需要添加一个远程登录的用户。添加远程用户
# 添加用户 rabbitmqctl add_user 用户名 密码 # 设置用户角色,分配操作权限 rabbitmqctl set_user_tags 用户名 角色 # 为用户添加资源权限(授予访问虚拟机根节点的所有权限) rabbitmqctl set_permissions -p / 用户名 ".*" ".*" ".*"
角色有四种:
administrator
:可以登录控制台、查看所有信息、并对rabbitmq进行管理monToring
:监控者;登录控制台,查看所有信息policymaker
:策略制定者;登录控制台指定策略managment
:普通管理员;登录控制
这里创建用户
mq
,密码mq
,设置administrator
角色,赋予所有权限(注意看我设置角色的时候写错了,应该写administrator)创建完成后,访问
虚拟机ip:15672
进行登录,然后便可进入到后台
PS:建议使用docker来做,以上步骤比较麻烦使用docker简单很多,命令如下:
docker run -d --name myRabbitMQ -e RABBITMQ_DEFAULT_USER=你的用户名 -e RABBITMQ_DEFAULT_PASS=你的密码 -p 15672:15672 -p 5672:5672 rabbitmq:3.8.14-management
2. Hello World
在本教程的这一部分中,我们将用Java
编写两个程序。发送单个消息的生产者和接收消息并打印出来的消费者。我们将介绍Java API中的一些细节。在下图中,“P”是我们的生产者,“C”是我们的消费者。中间的框是一个队列——RabbitMQ
代表使用者保留的消息缓冲区
2.1 创建一个空项目
2.2 添加依赖
<dependencies>
<!--rabbitmq 依赖客户端-->
<dependency>
<groupId>com.rabbitmq</groupId>
<artifactId>amqp-client</artifactId>
<version>5.8.0</version>
</dependency>
<!--操作文件流的一个依赖-->
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.6</version>
</dependency>
</dependencies>
<!--指定 jdk 编译版本-->
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>8</source>
<target>8</target>
</configuration>
</plugin>
</plugins>
</build>
版本根据需求选择
2.3 消息生产者
创建一个类作为生产者,最终生产消息到 RabbitMQ 的队列里
步骤:
- 创建 RabbitMQ 连接工厂
- 进行 RabbitMQ 工厂配置信息
- 创建 RabbitMQ 连接
- 创建 RabbitMQ 信道
- 生成一个队列发送一个消息到交换机,交换机发送到队列。”” 代表默认交换机
注意:后续可以在学学使用SpringBoot来整合MQ,使用SpringAMQP
public class Producer {
//对列名称
public static final String QUEUE_NAME="hello";
//发消息
public static void main(String[] args) throws IOException, TimeoutException {
//创建一个连接工厂
ConnectionFactory factory = new ConnectionFactory();
//工厂IP 连接RabbitMQ对列
factory.setHost("自己虚拟机ip");
//用户名
factory.setUsername("rabbitmq用户名");
//密码
factory.setPassword("rabbitmq密码");
//创建连接
Connection connection = factory.newConnection();
//获取信道
Channel channel = connection.createChannel();
/**
* 生产一个对列
* 1.对列名称
* 2.对列里面的消息是否持久化,默认情况下(false),消息存储在内存中,true:表示持久化(存储到磁盘上)
* 3.该队列是否只供一个消费者进行消费,是否进行消息共享,true可以多个消费者消费 false:只能一个消费者消费
* 4.是否自动删除,最后一个消费者端开链接以后,该队列是否自动删除,true表示自动删除
* 5.其他参数
*/
channel.queueDeclare(QUEUE_NAME,false,false,false,null);
//发消息
String message = "Hello,world";
/**
* 发送一个消息
* 1.发送到哪个交换机
* 2.路由的key值是哪个,本次是队列的名称
* 3.其他参数信息
* 4.发送消息的消息体
*/
channel.basicPublish("",QUEUE_NAME,null,message.getBytes());
System.out.println("消息发送完毕");
}
}
到rabbitMQ
控制台看结果
方法解释:
声明队列:
channel.queueDeclare(队列名/String, 持久化/boolean, 共享消费/boolean, 自动删除/boolean, 配置参数/Map);
配置参数现在是 null,后面死信队列延迟队列等会用到,如:
队列的优先级
队列里的消息如果没有被消费,何去何从?(死信队列)
Map<String, Object> params = new HashMap();
// 设置队列的最大优先级 最大可以设置到 255 官网推荐 1-10 如果设置太高比较吃内存和 CPU
params.put("x-max-priority", 10);
// 声明当前队列绑定的死信交换机
params.put("x-dead-letter-exchange", Y_DEAD_LETTER_EXCHANGE);
// 声明当前队列的死信路由 key
params.put("x-dead-letter-routing-key", "YD");
channel.queueDeclare(QUEUE_NAME, true, false, false, params);
发布消息:
channel.basicPublish(交换机名/String, 队列名/String, 配置参数/Map, 消息/String);
配置参数现在是 null,后面死信队列、延迟队列等会用到,如:
发布的消息优先级
发布的消息标识符 id
// 给消息赋予 优先级 ID 属性
AMQP.BasicProperties properties = new AMQP.BasicProperties().builder().priority(10).messageId("1")build();
channel.basicPublish("", QUEUE_NAME, properties, message.getBytes());
2.4 消息消费者
创建一个类作为消费者,消费 RabbitMQ 队列的消息
/**
* @author 念心卓
* @version 1.0
* @description: 消息消费者
* @date 2023/4/21 21:30
*/
public class Consumer {
//从哪个队列接收消息
public static final String QUEUE_NAME = "hello";
public static void main(String[] args) throws Exception{
//创建连接工厂
ConnectionFactory factory = new ConnectionFactory();
//工厂IP 连接RabbitMQ对列
factory.setHost("自己虚拟机ip");
//用户名
factory.setUsername("rabbitmq用户名");
//密码
factory.setPassword("rabbitmq密码");
//创建连接
Connection connection = factory.newConnection();
//创建信道
Channel channel = connection.createChannel();
//为了防止接收消息的队列不存在,应该再创建一个与发送消息同名的队列,作为一个兜底的选择
channel.queueDeclare(QUEUE_NAME,false,false,false,null);
/**
* 消费者消费消息参数:
* 1.消费哪个队列的消息
* 2.消费成功之后是否要自动应答true:代表自动应答false:代表手动应答
* 3.消费者未成功消费的回调
* 4.消费者取消消费的回调
*/
channel.basicConsume(QUEUE_NAME,true,
(consumerTag,message)-> System.out.println(new String(message.getBody())),//这里使用new 的方式把打印消息对象中的消息体
consumerTag-> System.out.println("消息消费被中断"));
}
}
结果:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Hello,world
值得一提的是,basicConsume
的参数中,第三个和第四个参数都是函数式接口,所以需要实现该接口的方法(使用lambda
表达式)
channel.basicConsume(队列名字/String, 是否自动签收/boolean, 消费时的回调/接口类, 无法消费的回调/接口类);
可以进去追溯源码,你就知道为什么这样写了。
3. Work Queues
Work Queues
是工作队列(又称任务队列)的主要思想是避免立即执行资源密集型任务,而不得不等待它完成。相反我们安排任务在之后执行。我们把任务封装为消息并将其发送到队列。在后台运行的工作进程将弹出任务并最终执行作业。当有多个工作线程时,这些工作线程将一起处理这些任务。
上面那段话其实不好理解,简单来说,就是有一个生产者疯狂的发消息,发送了很多消息,一个消费者处理不过来,导致消息越来越多,这时候就需要更多的消费者来进行消费,从而保证消息不会越堆越多
3.1 轮询发消息
轮询发消息其实是针对上图工作队列
来说的,也就是说上面多个消费者(工作线程)消费消息是互相竞争的关系,不允许消息被重复消费。
在这个案例中我们会启动两个消费者,一个消息发送线程,我们来看看他们两个消费者是如何工作的。
3.1.1 抽取工具类
由于我们每次都要创建连接工厂,信道等,有点麻烦,所以我们就先把公共的部分提取出来,做成工具类。
package rabbitmq.nxz.util;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
/**
* @author 念心卓
* @version 1.0
* @description: 抽取连接的公共方法
* @date 2023/4/22 16:57
*/
public class RabbitMQUtils {
/**
* 创建信道
* @return 创建信道
*/
public static Channel getChannel() throws Exception{
//创建连接工厂
ConnectionFactory factory = new ConnectionFactory();
//工厂IP 连接RabbitMQ对列
factory.setHost("自己虚拟机ip");
//用户名
factory.setUsername("rabbitmq用户名");
//密码
factory.setPassword("rabbitmq密码");
//创建连接
Connection connection = factory.newConnection();
//创建信道
return connection.createChannel();
}
}
3.1.2 启动两个消费者
package rabbitmq.nxz.to;
import com.rabbitmq.client.Channel;
import rabbitmq.nxz.util.RabbitMQUtils;
import java.util.Arrays;
/**
* @author 念心卓
* @version 1.0
* @description: 消费者1
* @date 2023/4/22 17:09
*/
public class Work01 {
public static final String QUEUE_NAME = "hello";
public static void main(String[] args) throws Exception {
//获取信道
Channel channel = RabbitMQUtils.getChannel();
//做一个兜底,防止要消费的队列不存在而报错
channel.queueDeclare(QUEUE_NAME,false,false,false,null);
System.out.println("消费者01启动");
//接受消息
channel.basicConsume(QUEUE_NAME,true,
((consumerTag, message) -> System.out.println("消费者01接收到消息:"+ new String(message.getBody()) +",执行的回调")),
consumerTag -> System.out.println("消费者01取消消费消息执行的回调"));
}
}
要启动多个消费者,可以选择把这个代码复制一份运行,我这里使用另外一种方法。
D:\dev_tools\Java\jdk\install\jdk-17.0.2\bin\java.exe "-javaagent:D:\dev_tools\Java\idea\install\IntelliJ IDEA 2022.3.3\lib\idea_rt.jar=56543:D:\dev_tools\Java\idea\install\IntelliJ IDEA 2022.3.3\bin" -Dfile.encoding=UTF-8 -classpath E:\dev_workspace\IDEAWorkSpace\Guigu-RabbitMQ\Guigu-RabbitMQ\rabbitmq-hello\target\classes;D:\dev_tools\Maven\repo\com\rabbitmq\amqp-client\5.8.0\amqp-client-5.8.0.jar;D:\dev_tools\Maven\repo\org\slf4j\slf4j-api\1.7.29\slf4j-api-1.7.29.jar;D:\dev_tools\Maven\repo\commons-io\commons-io\2.6\commons-io-2.6.jar rabbitmq.nxz.to.Work01
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
消费者01启动
3.1.3 创建一个生产者
package rabbitmq.nxz.two;
import com.rabbitmq.client.Channel;
import rabbitmq.nxz.util.RabbitMQUtils;
import java.util.Scanner;
/**
* @author 念心卓
* @version 1.0
* @description: 生产者01
* @date 2023/4/22 17:35
*/
public class Task01 {
public static final String QUEUE_NAME = "hello";
public static void main(String[] args) throws Exception{
Channel channel = RabbitMQUtils.getChannel();
//声明队列
channel.queueDeclare(QUEUE_NAME,false,false,false,null);
//发送消息
Scanner scanner = new Scanner(System.in);
while (scanner.hasNext()){
String message = scanner.next();
//发送消息
channel.basicPublish("",QUEUE_NAME,null,message.getBytes());
System.out.println(message+"消息发送完成");
}
}
}
启动生产者,输入
可以看见两个消费者是处于竞争关系。
3.2 消息应答
3.2.1 概念
消费者完成一个任务可能需要一段时间,如果其中一个消费者处理一个长的任务并仅只完成了部分突然它挂掉了,会发生什么情况。RabbitMQ
一旦向消费者传递了一条消息,便立即将该消息标记为删除。在这种情况下,突然有个消费者挂掉了,我们将丢失正在处理的消息。以及后续发送给该消费这的消息,因为它无法接收到。
为了保证消息在发送过程中不丢失,rabbitmq
引入消息应答机制,消息应答就是:消费者在接收到消息并且处理该消息之后,告诉rabbitmq
它已经处理了,rabbitmq
可以把该消息删除了。
3.2.2 自动应答
消息发送后立即被认为已经传送成功,这种模式需要在高吞吐量和数据传输安全性方面做权衡,因为这种模式如果消息在接收到之前,消费者那边出现连接或者channel关闭,那么消息就丢失了,当然另一方面这种模式消费者那边可以传递过载的消息,没有对传递的消息数量进行限制,当然这样有可能使得消费者这边由于接收太多还来不及处理的消息,导致这些消息的积压,最终使得内存耗尽,最终这些消费者线程被操作系统杀死,所以这种模式仅适用在消费者可以高效并以某种速率能够处理这些消息的情况下使用。
3.2.3 手动消息应答的方法
Channel.basicAck
(肯定确认应答):basicAck(long deliveryTag, boolean multiple);
第一个参数是消息的标记,第二个参数表示是否应用于多消息,
RabbitMQ
已知道该消息并且成功的处理消息,可以将其丢弃了Channel.basicReject
(否定确认应答)basicReject(long deliveryTag, boolean requeue);
第一个参数表示拒绝
deliveryTag
对应的消息,第二个参数表示是否requeue
:true 则重新入队列,false 则丢弃或者进入死信队列。该方法
reject
后,该消费者还是会消费到该条被reject
的消息。Channel.basicNack
(用于否定确认):示己拒绝处理该消息,可以将其丢弃了basicNack(long deliveryTag, boolean multiple, boolean requeue);
第一个参数表示拒绝
deliveryTag
对应的消息,第二个参数是表示是否应用于多消息,第三个参数表示是否requeue
,与basicReject
区别就是同时支持多个消息,可以拒绝签收该消费者先前接收未ack
的所有消息。拒绝签收后的消息也会被自己消费到。Channel.basicRecover
basicRecover(boolean requeue);
是否恢复消息到队列,参数是是否
requeue
,true 则重新入队列,并且尽可能的将之前recover
的消息投递给其他消费者消费,而不是自己再次消费。false 则消息会重新被投递给自己。
Multiple 的解释:
手动应答的好处是可以批量应答并且减少网络拥堵
true 代表批量应答 channel 上未应答的消息
比如说 channel 上有传送 tag 的消息 5,6,7,8 当前 tag 是 8 那么此时 5-8 的这些还未应答的消息都会被确认收到消息应答
false 同上面相比只会应答 tag=8 的消息 5,6,7 这三个消息依然不会被确认收到消息应答
3.2.4 消息重新入队
如果消费者由于某些原因失去连接(其通道已关闭,连接已关闭或 TCP 连接丢失),导致消息未发送 ACK
确认,RabbitMQ
将了解到消息未完全处理,并将对其重新排队。如果此时其他消费者可以处理,它将很快将其重新分发给另一个消费者。这样,即使某个消费者偶尔死亡,也可以确保不会丢失任何消息。
3.2.5 消息手动应答代码
默认消息采用的是自动应答,所以我们要想实现消息消费过程中不丢失,需要把自动应答改为手动应答
消费者启用两个线程,消费 1 一秒消费一个消息,消费者 2 十秒消费一个消息,然后在消费者 2 消费消息的时候,停止运行,这时正在消费的消息是否会重新进入队列,而后给消费者 1 消费呢?
因为要模拟复杂的业务场景,所以这里使用线程的休眠来代替复杂业务场景消耗的时间
创建休眠工具类
package rabbitmq.nxz.util; /** * @author 念心卓 * @version 1.0 * @description: 休眠工具类 * @date 2023/4/23 11:43 */ public class SleepUtils { public static void sleep(int second) { try { Thread.sleep(1000 * second); } catch (InterruptedException e) { throw new RuntimeException(e); } } }
创建一位生成者
package rabbitmq.nxz.three; import com.rabbitmq.client.Channel; import rabbitmq.nxz.util.RabbitMQUtils; import java.util.Queue; import java.util.Scanner; /** * @author 念心卓 * @version 1.0 * @description: 生产者 * @date 2023/4/23 11:45 */ public class Producer { public static final String QUEUE_NAME = "ackQueue"; public static void main(String[] args) throws Exception{ Channel channel = RabbitMQUtils.getChannel(); channel.queueDeclare(QUEUE_NAME,false,false,false,null); Scanner scanner = new Scanner(System.in); while (scanner.hasNext()){ String message = scanner.next(); //发送消息 channel.basicPublish("",QUEUE_NAME,null,message.getBytes()); System.out.println("生产者发出消息:"+ message); } } }
创建两个消费者
package rabbitmq.nxz.three; import com.rabbitmq.client.Channel; import rabbitmq.nxz.util.RabbitMQUtils; import rabbitmq.nxz.util.SleepUtils; /** * @author 念心卓 * @version 1.0 * @description: 消费者01 * @date 2023/4/23 11:49 */ public class Consumer01 { public static final String QUEUE_NAME = "ackQueue"; public static void main(String[] args) throws Exception{ Channel channel = RabbitMQUtils.getChannel(); //作为兜底,防止队列未创建时进行消费而报错 channel.queueDeclare(QUEUE_NAME,false,false,false,null); channel.basicConsume( QUEUE_NAME, false, //false表示手动应答 (consumerTag, message) -> { //沉睡1S SleepUtils.sleep(1); System.out.println("消费者01接受到的消息:"+new String(message.getBody(),"UTF-8")); //接收到消息之后手动应答 /** * 1.消息的标记Tag * 2.是否批量应答 false表示不批量应答信道中的消息(推荐使用false) */ channel.basicAck(message.getEnvelope().getDeliveryTag(),false); }, consumerTag -> System.out.println(consumerTag + "消费者取消消费接口回调逻辑")); } }
package rabbitmq.nxz.three; import com.rabbitmq.client.Channel; import rabbitmq.nxz.util.RabbitMQUtils; import rabbitmq.nxz.util.SleepUtils; /** * @author 念心卓 * @version 1.0 * @description: 消费者02 * @date 2023/4/23 11:55 */ public class Consumer02 { public static final String QUEUE_NAME = "ackQueue"; public static void main(String[] args) throws Exception{ Channel channel = RabbitMQUtils.getChannel(); //作为兜底,防止队列未创建时进行消费而报错 channel.queueDeclare(QUEUE_NAME,false,false,false,null); channel.basicConsume( QUEUE_NAME, false, //false表示手动应答 (consumerTag, message) -> { //沉睡1S SleepUtils.sleep(30); System.out.println("消费者02接受到的消息:"+new String(message.getBody(),"UTF-8")); //接收到消息之后手动应答 /** * 1.消息的标记Tag * 2.是否批量应答 false表示不批量应答信道中的消息(推荐使用false) */ channel.basicAck(message.getEnvelope().getDeliveryTag(),false); }, consumerTag -> System.out.println(consumerTag + "消费者取消消费接口回调逻辑")); } }
可以看见两个消费者只是休眠的时间不一样。一个是30S,一个是1S
执行结果
因为我先启动的是消费者02,所以导致第一条消息发送给消费者01,但是他要处理30S才能处理完毕。
所以根据生产者发送的消息,消费者消费的顺序如下:
消费者01 --》 AA(处理30S) 消费者02 --》 BB(处理1S) 消费者01 --》 本来该处理CC的,但是它在30S的执行过程中,我模拟出错,停止运行消费者01,看是否会导致消息重新入队和消息丢失 消费者02 --》 DD(处理1S) 由于前面的CC被重新入队,所以CC被发送给了02处理
可以看出,在手动应答的时候,只要
RabbitMQ
没有宕机,队列就不会消失,消息并不会被丢失,而是重新入队发送给了别的消费者;如果宕机了,那么队列也就消失了,消息就会丢失,所以我们后面会学习持久化操作。
3.3 RabbitMQ持久化
刚刚我们已经看到了如何处理任务不丢失的情况,但是如何保障当RabbitMQ
服务停掉以后消息生产者发送过来的消息不丢失。默认情况下RabbitMQ
退出或由于某种原因崩溃时,它忽视队列和消息,除非告知它不要这样做。确保消息不会丢失需要做两件事:我们需要将队列和消息都标记为持久化。
3.3.1 队列持久化
之前我们创建的队列都是非持久化的,RabbitMQ
如果重启的化,该队列就会被删除掉,如果要队列实现持久化需要在声明队列的时候把 durable
参数设置为true
,代表开启持久化
//声明队列
channel.queueDeclare(TASK_QUEUE_NAME,true,false,false,null);//第二个参数就是表示是否持久化队列
注意
如果之前声明的队列不是持久化的,需要把原先队列先删除,或者重新创建一个持久化的队列
不然就会出现如下错误:
所以要重启一次RabbitMQ
服务,再将队列持久化。
3.3.2 消息持久化
需要在消息生产者发布消息的时候,开启消息的持久化
在 basicPublish
方法的第二个参数添加这个属性: MessageProperties.PERSISTENT_TEXT_PLAIN
//发送消息
channel.basicPublish("",QUEUE_NAME, MessageProperties.PERSISTENT_TEXT_PLAIN,message.getBytes());
将消息标记为持久化并不能完全保证不会丢失消息。尽管它告诉 RabbitMQ
将消息保存到磁盘,但是这里依然存在当消息刚准备存储在磁盘的时候 但是还没有存储完,消息还在缓存的一个间隔点。此时并没有真正写入磁盘。持久性保证并不强,但是对于我们的简单任务队列而言,这已经绰绰有余了。
3.3.3 不公平分发
在最开始的时候我们学习到 RabbitMQ
分发消息采用的轮询分发,但是在某种场景下这种策略并不是很好,比方说有两个消费者在处理任务,其中有个消费者 1 处理任务的速度非常快,而另外一个消费者 2 处理速度却很慢,这个时候我们还是采用轮询分发的化就会到这处理速度快的这个消费者很大一部分时间处于空闲状态,而处理慢的那个消费者一直在干活,这种分配方式在这种情况下其实就不太好,但是 RabbitMQ
并不知道这种情况它依然很公平的进行分发。
为了避免这种情况,在消费者中消费消息之前,设置参数 channel.basicQos(1);
表示预分配给你1条,你要把这条消费完毕之后,才能够继续消费下一条,其实这里和预取值很像
package rabbitmq.nxz.three;
import com.rabbitmq.client.Channel;
import rabbitmq.nxz.util.RabbitMQUtils;
import rabbitmq.nxz.util.SleepUtils;
/**
* @author 念心卓
* @version 1.0
* @description: 消费者01
* @date 2023/4/23 11:49
*/
public class Consumer01 {
public static final String QUEUE_NAME = "ackQueue";
public static void main(String[] args) throws Exception{
Channel channel = RabbitMQUtils.getChannel();
//作为兜底,防止队列未创建时进行消费而报错
channel.queueDeclare(QUEUE_NAME,true,false,false,null);
//设置未不公平分发,要在消费消息之前设置才有效 这里我只设置了01,02也是如此
channel.basicQos(1);
channel.basicConsume(
QUEUE_NAME,
false,
(consumerTag, message) -> {
//沉睡1S
SleepUtils.sleep(1);
System.out.println("消费者01接受到的消息:"+new String(message.getBody(),"UTF-8"));
//接收到消息之后手动应答
/**
* 1.消息的标记Tag
* 2.是否批量应答 false表示不批量应答信道中的消息(推荐使用false)
*/
channel.basicAck(message.getEnvelope().getDeliveryTag(),false);
},
consumerTag -> System.out.println(consumerTag + "消费者取消消费接口回调逻辑"));
}
}
开启成功,会看到如下结果:
不公平分发思想:如果一个工作队列还没有处理完或者没有应答签收一个消息,则不拒绝 RabbitMQ
分配新的消息到该工作队列。此时 RabbitMQ
会优先分配给其他已经处理完消息或者空闲的工作队列。如果所有的消费者都没有完成手上任务,队列还在不停的添加新任务,队列有可能就会遇到队列被撑满的情况,这个时候就只能添加新的 消费者(工作队列)或者改变其他存储任务的策略。
效果演示:
3.3.4 预取值分发
带权的消息分发
默认消息的发送是异步发送的,所以在任何时候,channel
上不止只有一个消息来自消费者的手动确认,所以本质上是异步的。因此这里就存在一个未确认的消息缓冲区,因此希望开发人员能限制此缓冲区的大小,以避免缓冲区里面无限制的未确认消息问题。这个时候就可以通过使用 basicQos
方法设置「预取计数」值来完成的。
该值定义通道上允许的未确认消息的最大数量。一旦数量达到配置的数量, RabbitMQ
将停止在通道上传递更多消息,除非至少有一个未处理的消息被确认,例如,假设在通道上有未确认的消息 5、6、7,8,并且通道的预取计数设置为 4,此时 RabbitMQ
将不会在该通道上再传递任何消息,除非至少有一个未应答的消息被 ack
。比方说tag=6
这个消息刚刚被确认 ACK
,RabbitMQ
将会感知这个情况到并再发送一条消息。消息应答和 QoS
预取值对用户吞吐量有重大影响。
通常,增加预取将提高向消费者传递消息的速度。虽然自动应答传输消息速率是最佳的,但是,在这种情况下已传递但尚未处理的消息的数量也会增加,从而增加了消费者的 RAM 消耗(随机存取存储器)应该小心使用具有无限预处理的自动确认模式或手动确认模式,消费者消费了大量的消息如果没有确认的话,会导致消费者连接节点的内存消耗变大,所以找到合适的预取值是一个反复试验的过程,不同的负载该值取值也不同 ,100 到 300 范围内的值通常可提供最佳的吞吐量,并且不会给消费者带来太大的风险。
预取值为 1 是最保守的。当然这将使吞吐量变得很低,特别是消费者连接延迟很严重的情况下,特别是在消费者连接等待时间较长的环境 中。对于大多数应用来说,稍微高一点的值将是最佳的。
不公平分发和预取值分发都用到
basicQos
方法,如果取值为 1,代表不公平分发,取值不为1,代表预取值分发
4. 发布确认
生产者发布消息到 RabbitMQ
后,需要 RabbitMQ
返回「ACK(已收到)」给生产者,这样生产者才知道自己生产的消息成功发布出去。
4.1 发布确认原理
生产者将信道设置成 confirm
模式,一旦信道进入 confirm
模式,所有在该信道上面发布的消息都将会被指派一个唯一的 ID(从 1 开始),一旦消息被投递到所有匹配的队列之后,broker
就会发送一个确认给生产者(包含消息的唯一 ID),这就使得生产者知道消息已经正确到达目的队列了,如果消息和队列是可持久化的,那么确认消息会在将消息写入磁盘之后发出,broker
回传给生产者的确认消息中 delivery-tag
域包含了确认消息的序列号,此外 broker
也可以设置 basicAck
的 multiple
域,表示到这个序列号之前的所有消息都已经得到了处理。
confirm
模式最大的好处在于是异步的,一旦发布一条消息,生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息,当消息最终得到确认之后,生产者应用便可以通过回调方法来处理该确认消息,如果RabbitMQ
因为自身内部错误导致消息丢失,就会发送一条 nack
消息, 生产者应用程序同样可以在回调方法中处理该 nack
消息。
4.2 发布确认策略
4.2.1 开启发布确认方法
发布确认默认是没有开启的,如果要开启需要调用方法 confirmSelect
,每当你要想使用发布确认,都需要在 channel 上调用该方法
//开启发布确认
channel.confirmSelect();
4.2.2 单个确认发布
这是一种简单的确认方式,它是一种同步确认发布的方式,也就是发布一个消息之后只有它被确认发布,后续的消息才能继续发布,waitForConfirmsOrDie(long)
这个方法只有在消息被确认的时候才返回,如果在指定时间范围内这个消息没有被确认那么它将抛出异常。
这种确认方式有一个最大的缺点就是:发布速度特别的慢,因为如果没有确认发布的消息就会阻塞所有后续消息的发布,这种方式最多提供每秒不超过数百条发布消息的吞吐量。当然对于某些应用程序来说这可能已经足够了。
package rabbitmq.nxz.four;
import com.rabbitmq.client.Channel;
import rabbitmq.nxz.util.RabbitMQUtils;
import java.util.UUID;
/**
* @author 念心卓
* @version 1.0
* @description: 单个确认
* @date 2023/4/23 18:21
*/
public class ConfirmMessage01 {
//单个发消息的个数
public static final int MESSAGE_COUNT = 1000;
public static void main(String[] args){
try {
publishMessageIndividually();
} catch (Exception e) {
throw new RuntimeException(e);
}
}
public static void publishMessageIndividually() throws Exception {
Channel channel = RabbitMQUtils.getChannel();
String queueName = UUID.randomUUID().toString();
channel.queueDeclare(queueName, false, true, false, null);
long startTime = System.currentTimeMillis();
//开启发布确认功能
channel.confirmSelect();
for (int i = 0; i < MESSAGE_COUNT; i++) {
String message = i +"";
channel.basicPublish("",queueName,null,message.getBytes());
boolean flag = channel.waitForConfirms();
// if (flag){
// System.out.println("消息已确认");
// }
}
long endTime = System.currentTimeMillis();
System.out.println("发布"+MESSAGE_COUNT+"个单独确认消息,耗时:"+(endTime-startTime)+"ms");
}
}
结果:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
发布1000个单独确认消息,耗时:187ms
确认发布指的是成功发送到了队列,并不是消费者消费了消息。
4.2.3 批量确认发布
单个确认发布方式非常慢,与单个等待确认消息相比,先发布一批消息然后一起确认可以极大地提高吞吐量,当然这种方式的缺点就是:当发生故障导致发布出现问题时,不知道是哪个消息出问题了,我们必须将整个批处理保存在内存中,以记录重要的信息而后重新发布消息。当然这种方案仍然是同步的,也一样阻塞消息的发布。
package rabbitmq.nxz.four;
import com.rabbitmq.client.Channel;
import rabbitmq.nxz.util.RabbitMQUtils;
import java.util.UUID;
/**
* @author 念心卓
* @version 1.0
* @description: 批量确认
* @date 2023/4/23 18:21
*/
public class ConfirmMessage02 {
//单个发消息的个数
public static final int MESSAGE_COUNT = 1000;
public static void main(String[] args){
try {
publishMessageBatch();
} catch (Exception e) {
throw new RuntimeException(e);
}
}
public static void publishMessageBatch() throws Exception {
Channel channel = RabbitMQUtils.getChannel();
String queueName = UUID.randomUUID().toString();
channel.queueDeclare(queueName, false, true, false, null);
long startTime = System.currentTimeMillis();
//开启发布确认功能
channel.confirmSelect();
//每100条确认一次
int batchSize = 100;
for (int i = 0; i < MESSAGE_COUNT; i++) {
String message = i +"";
channel.basicPublish("",queueName,null,message.getBytes());
// if (flag){
// System.out.println("消息已确认");
// }
//判断达到100条消息的时候,批量确认一次
if((i+1)%batchSize==0){
//发布确认
channel.waitForConfirms();
}
}
long endTime = System.currentTimeMillis();
System.out.println("发布"+MESSAGE_COUNT+"个批量确认消息,耗时:"+(endTime-startTime)+"ms");
}
}
结果:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
发布1000个批量确认消息,耗时:52ms
4.2.4 异步确认发布(性价比最高)
异步确认虽然编程逻辑比上两个要复杂,但是性价比最高,无论是可靠性还是效率都很好,利用了回调函数来达到消息可靠性传递的,这个中间件也是通过函数回调来保证是否投递成功,下面详细讲解异步确认是怎么实现的。
package rabbitmq.nxz.four;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.ConfirmCallback;
import rabbitmq.nxz.util.RabbitMQUtils;
import java.util.Locale;
import java.util.UUID;
import java.util.concurrent.ConcurrentNavigableMap;
import java.util.concurrent.ConcurrentSkipListMap;
/**
* @author 念心卓
* @version 1.0
* @description: 异步确认
* @date 2023/4/23 18:21
*/
public class ConfirmMessage03 {
//单个发消息的个数
public static final int MESSAGE_COUNT = 1000;
public static void main(String[] args){
try {
publishMessageAsync();
} catch (Exception e) {
throw new RuntimeException(e);
}
}
public static void publishMessageAsync() throws Exception {
Channel channel = RabbitMQUtils.getChannel();
String queueName = UUID.randomUUID().toString();
channel.queueDeclare(queueName, false, true, false, null);
//开启发布确认功能
channel.confirmSelect();
/**
* 线程安全有序的一个哈希表,适用于高并发的情况
* 1. 轻松的将序号和消息进行关联
* 2. 轻松批量删除条目,只要给到序号
* 3. 支持并发访问
*/
ConcurrentSkipListMap<Long, String> outstandingConfirms = new ConcurrentSkipListMap<>();
long startTime = System.currentTimeMillis();
/**
* 确认收到消息的回调
* 1. 消息的序列号
* 2. 是否批量确认
* 2.1 true 确认小于等于当前序列号的消息
* 2.2 false 确认当前序列号的消息
*/
ConfirmCallback ackCallback = ((deliveryTag, multiple) -> {
if (multiple){
//返回的是小于等于当前序列号的消息
ConcurrentNavigableMap<Long, String> confirmed = outstandingConfirms.headMap(deliveryTag, true);
//清楚该部分未确认的消息
confirmed.clear();
}else {
//只清除当前序列号的消息
outstandingConfirms.remove(deliveryTag);
}
});
//未收到消息的回调
ConfirmCallback nackCallBack = (deliveryTag, multiple) -> {
String message = outstandingConfirms.get(deliveryTag);
System.out.println("发布的消息 " +message+ "未被确认,序列号" +deliveryTag);
};
/**
* 再发送消息之前,要添加一个异步确认的监听器
* 1. 确认收到消息的回调
* 2. 未收到消息的回调
*/
channel.addConfirmListener(ackCallback,nackCallBack);
for (int i = 0; i < MESSAGE_COUNT; i++) {
String message = i +"";
/**
* channel.getNextPublishSeqNo()获取下一个消息的序列号
*通过序列号与消息体进行一个关联
*全部都是未确认的消息体
*/
outstandingConfirms.put(channel.getNextPublishSeqNo(),message);
channel.basicPublish("",queueName,null,message.getBytes());
}
long endTime = System.currentTimeMillis();
System.out.println("发布"+MESSAGE_COUNT+"个异步确认消息,耗时:"+(endTime-startTime)+"ms");
}
}
结果:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
发布1000个异步确认消息,耗时:20ms
headMap
方法用于将已确认的消息存入新的 Map 缓存区里,然后清除该新缓存区的内容。因为 headMap
方法是浅拷贝,所以清除了缓存区,相当于清除了内容的地址,也就清除了队列的确认的消息。
4.2.5 以上 3 种发布确认速度对比
单独发布消息
同步等待确认,简单,但吞吐量非常有限。
批量发布消息
批量同步等待确认,简单,合理的吞吐量,一旦出现问题但很难推断出是那条消息出现了问题。
异步处理
最佳性能和资源使用,在出现错误的情况下可以很好地控制,但是实现起来稍微难些
5. 交换机
5.1 Exchange
5.1.1 Exchange 概念
RabbitMQ
消息传递模型的核心思想是: 生产者生产的消息从不会直接发送到队列。实际上,通常生产者甚至都不知道这些消息传递传递到了哪些队列中。
相反,**生产者只能将消息发送到交换机(exchange)**,交换机工作的内容非常简单,一方面它接收来自生产者的消息,另一方面将它们推入队列。交换机必须确切知道如何处理收到的消息。是应该把这些消息放到特定队列还是说把他们到许多队列中还是说应该丢弃它们。这就的由交换机的类型来决定。
5.1.2 Exchange 类型
直接(direct):处理路由键。需要将一个队列绑定到交换机上,要求该消息与一个特定的路由键完全匹配。这是一个完整的匹配。如果一个队列绑定到该交换机上要求路由键 abc ,则只有被标记为 abc 的消息才被转发,不会转发 abc.def,也不会转发 dog.ghi,只会转发 abc。
**主题(topic)**:将路由键和某模式进行匹配。此时队列需要绑定要一个模式上。符号
“#”
匹配一个或多个词,符号*
匹配不多不少一个词。因此abc.#
能够匹配到 abc.def.ghi,但是abc.*
只会匹配到 abc.def。**标题(headers)**:不处理路由键。而是根据发送的消息内容中的
headers
属性进行匹配。在绑定Queue
与Exchange
时指定一组键值对;当消息发送到RabbitMQ
时会取到该消息的headers
与Exchange
绑定时指定的键值对进行匹配;如果完全匹配则消息会路由到该队列,否则不会路由到该队列。headers
属性是一个键值对,可以是Hashtable
,键值对的值可以是任何类型。而fanout
,direct
,topic
的路由键都需要要字符串形式的。匹配规则 x-match 有下列两种类型:
x-match = all :表示所有的键值对都匹配才能接受到消息
x-match = any :表示只要有键值对匹配就能接受到消息
**扇出(fanout)**:不处理路由键。你只需要简单的将队列绑定到交换机上。一个发送到交换机的消息都会被转发到与该交换机绑定的所有队列上。很像子网广播,每台子网内的主机都获得了一份复制的消息。
Fanout
交换机转发消息是最快的。
5.1.3 默认exchange
通过空字符串("")
进行标识的交换机是默认交换
channel.basicPublish("",QUEUE_NAME,null,message.getBytes());
第一个参数是交换机的名称。空字符串 表示默认或无名称交换机:消息能路由发送到队列中其实是由routingKey(bindingkey)
绑定指定的 key
5.2 临时队列
之前的章节我们使用的是具有特定名称的队列(还记得 hello 和 ack_queue 吗?)。队列的名称我们来说至关重要,我们需要指定我们的消费者去消费哪个队列的消息。
每当我们连接到 RabbitMQ
时,我们都需要一个全新的空队列,为此我们可以创建一个具有随机名称的队列,或者能让服务器为我们选择一个随机队列名称那就更好了。其次一旦我们断开了消费者的连接,队列将被自动删除。
创建临时队列的方式如下:
String queueName = channel.queueDeclare().getQueue();
5.3 绑定bindings
什么是 bingding
呢,binding
其实是 exchange
和 queue
之间的桥梁,它告诉我们 exchange
和那个队列进行了绑定关系。比如说下面这张图告诉我们的就是 X 与 Q1 和 Q2 进行了绑定
5.4 Fanout
5.4.1 Fanout介绍
Faout
这种类型非常简单。正如从名称中猜到的那样,它是将接收到的所有消息广播到它知道的所有队列中。系统中默认有些exchange类型
5.4.2 Fanout实战
Logs 和临时队列的绑定关系如下图
注意
先启动两个消费者再启动生产者。
生产者生产消息后,如果没有对应的消费者接收,则该消息是遗弃的消息
生产者
package rabbitmq.nxz.five; import com.rabbitmq.client.BuiltinExchangeType; import com.rabbitmq.client.Channel; import rabbitmq.nxz.util.RabbitMQUtils; import java.nio.charset.StandardCharsets; import java.util.Scanner; /** * @author 念心卓 * @version 1.0 * @description: 生产者 * @date 2023/4/24 9:56 */ public class Producer { public static final String EXCHANGE_NAME = "logs"; public static void main(String[] args) throws Exception{ Channel channel = RabbitMQUtils.getChannel(); //声明一个交换机,并且指明类型 channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.FANOUT); //声明一个临时队列 String queueName = channel.queueDeclare().getQueue(); //绑定交换机和队列 channel.queueBind(queueName,EXCHANGE_NAME,""); //生产消息 Scanner scanner = new Scanner(System.in); while (scanner.hasNext()){ String message = scanner.next(); channel.basicPublish(EXCHANGE_NAME,"",null,message.getBytes(StandardCharsets.UTF_8)); System.out.println("生产者发出消息:"+message); } } }
消费者(消费者01和02的代码差不多)
package rabbitmq.nxz.five; import com.rabbitmq.client.BuiltinExchangeType; import com.rabbitmq.client.Channel; import rabbitmq.nxz.util.RabbitMQUtils; import java.nio.charset.StandardCharsets; /** * @author 念心卓 * @version 1.0 * @description: 消费者01 * @date 2023/4/24 9:48 */ public class Consumer01 { public static final String EXCHANGE_NAME = "logs"; public static void main(String[] args) throws Exception{ Channel channel = RabbitMQUtils.getChannel(); //申明交换机 channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.FANOUT); //声明一个临时队列;当消费者断开与队列的连接的时候 队列就自动删除 String queueName = channel.queueDeclare().getQueue(); //绑定交换机和队列 channel.queueBind(queueName,EXCHANGE_NAME,""); //消费 channel.basicConsume( queueName, true, (consumerTag, message) ->{ System.out.println("消费者01正在消费:"+new String(message.getBody(), StandardCharsets.UTF_8)); },consumerTag -> System.out.println("消费者01取消消费消息") ); } }
结果
可以看见消息被广播出去了,大家都能够收到。
一个发送,多个接受,发布/订阅模式
5.5 Direct
在上一节中,我们构建了一个简单的日志记录系统。我们能够向许多接收者广播日志消息。在本节我们将向其中添加一些特别的功能——让某个消费者订阅发布的部分消息。例如我们只把严重错误消息定向存储到日志文件(以节省磁盘空间),同时仍然能够在控制台上打印所有日志消息。
我们再次来回顾一下什么是 bindings,绑定是交换机和队列之间的桥梁关系。也可以这么理解: 队列只对它绑定的交换机的消息感兴趣。绑定用参数:routingKey 来表示也可称该参数为 binding key, 创建绑定我们用代码:channel.queueBind(queueName, EXCHANGE_NAME, “routingKey”);
绑定之后的意义由其交换类型决定。
5.5.1 Direct exchange
上一节中的我们的日志系统将所有消息广播给所有消费者,对此我们想做一些改变,例如我们希望将日志消息写入磁盘的程序仅接收严重错误(errros),而不存储哪些警告(warning)或信息(info)日志 消息避免浪费磁盘空间。Fanout
这种交换类型并不能给我们带来很大的灵活性-它只能进行无意识的广播,在这里我们将使用 direct
这种类型来进行替换,这种类型的工作方式是,消息只去到它绑定的 routingKey
队列中去。
也就是路由模式
在上面这张图中,我们可以看到 X 绑定了两个队列,绑定类型是 direct
。队列 Q1 绑定键为 orange, 队列 Q2 绑定键有两个:一个绑定键为 black,另一个绑定键为 green.
在这种绑定情况下,生产者发布消息到 exchange
上,绑定键为 orange 的消息会被发布到队列 Q1。绑定键为 blackgreen 和的消息会被发布到队列 Q2,其他消息类型的消息将被丢弃。
5.5.2 多重绑定
当然如果 exchange
的绑定类型是direct
,但是它绑定的多个队列的 key 如果都相同,在这种情况下虽然绑定类型是 direct
但是它表现的就和 fanout 有点类似了,就跟广播差不多,如上图所示。
5.5.3 实战
关系:
交换机:
C1 消费者:绑定 console 队列,routingKey 为 info、warning
C2 消费者:绑定 disk 队列,routingKey 为 error
当生产者生产消息到 direct_logs
交换机里,该交换机会检测消息的 routingKey 条件,然后分配到满足条件的队列里,最后由消费者从队列消费消息。
生产者
public class DirectLogs { //交换机名称 public static final String EXCHANGE_NAME = "direct_logs"; public static void main(String[] args) throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); Scanner scanner = new Scanner(System.in); while (scanner.hasNext()){ String message = scanner.next(); channel.basicPublish(EXCHANGE_NAME,"info",null,message.getBytes("UTF-8")); System.out.println("生产者发出消息:"+message); } } }
消费者01
public class ReceiveLogsDirect01 { public static final String EXCHANGE_NAME="direct_logs"; public static void main(String[] args) throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); //声明一个direct交换机 channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.DIRECT); //声明一个队列 channel.queueDeclare("console",false,false,false,null); channel.queueBind("console",EXCHANGE_NAME,"info"); channel.queueBind("console",EXCHANGE_NAME,"warning"); //接收消息 DeliverCallback deliverCallback = (consumerTag,message) -> { System.out.println("ReceiveLogsDirect01控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8")); }; //消费者取消消息时回调接口 channel.basicConsume("console",true,deliverCallback,consumerTag -> {}); } }
消费者02
/** * @author frx * @version 1.0 * @date 2022/7/24 21:50 */ public class ReceiveLogsDirect02 { public static final String EXCHANGE_NAME="direct_logs"; public static void main(String[] args) throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); //声明一个direct交换机 channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.DIRECT); //声明一个队列 channel.queueDeclare("disk",false,false,false,null); channel.queueBind("disk",EXCHANGE_NAME,"error"); //接收消息 DeliverCallback deliverCallback = (consumerTag,message) -> { System.out.println("ReceiveLogsDirect02控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8")); }; //消费者取消消息时回调接口 channel.basicConsume("disk",true,deliverCallback,consumerTag -> {}); } }
结果
5.6 Topics
5.6.1 Topic的介绍
在上一个小节中,我们改进了日志记录系统。我们没有使用只能进行随意广播的 fanout
交换机,而是使用了 direct
交换机,从而有能实现有选择性地接收日志。
尽管使用 direct
交换机改进了我们的系统,但是它仍然存在局限性——比方说我们想接收的日志类型有 info.base 和 info.advantage,某个队列只想 info.base 的消息,那这个时候direct
就办不到了。这个时候就只能使用 topic 类型
Topic 的要求
发送到类型是 topic
交换机的消息的routing_key
不能随意写,必须满足一定的要求,它必须是一个单词列表,以点号分隔开。这些单词可以是任意单词
比如说:”stock.usd.nyse”, “nyse.vmw”, “quick.orange.rabbit” 这种类型的。
当然这个单词列表最多不能超过 255 个字节。
在这个规则列表中,其中有两个替换符是大家需要注意的:
*
(星号)可以代替一个位置#
(井号)可以替代零个或多个位置
5.6.2 Topic匹配案例
- Q1–>绑定的是
- 中间带 orange 带 3 个单词的字符串
(*.orange.*)
- 中间带 orange 带 3 个单词的字符串
- Q2–>绑定的是
- 最后一个单词是 rabbit 的 3 个单词
(*.*.rabbit)
- 第一个单词是 lazy 的多个单词
(lazy.#)
- 最后一个单词是 rabbit 的 3 个单词
上图是一个队列绑定关系图,我们来看看他们之间数据接收情况是怎么样的
例子 | 说明 |
---|---|
quick.orange.rabbit | 被队列 Q1Q2 接收到 |
azy.orange.elephant | 被队列 Q1Q2 接收到 |
被队列 Q1Q2 接收到 | 被队列 Q1 接收到 |
lazy.brown.fox | 被队列 Q2 接收到 |
lazy.pink.rabbit | 被队列 Q2 接收到 |
quick.brown.fox | 不匹配任何绑定不会被任何队列接收到会被丢弃 |
quick.orange.male.rabbit | 是四个单词不匹配任何绑定会被丢弃 |
lazy.orange.male.rabbit | 是四个单词但匹配 Q2 |
笔记
当一个队列绑定键是 #,那么这个队列将接收所有数据,就有点像
fanout
了如果队列绑定键当中没有 # 和 * 出现,那么该队列绑定类型就是
direct
了
5.6.3 Topic实战
生产多个消息到交换机,交换机按照通配符分配消息到不同的队列中,队列由消费者进行消费
生产者
public class EmitLogTopic { //交换机的名称 public static final String EXCHANGE_NAME = "topic_logs"; public static void main(String[] args) throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); /** * Q1-->绑定的是 * 中间带 orange 带 3 个单词的字符串(*.orange.*) * Q2-->绑定的是 * 最后一个单词是 rabbit 的 3 个单词(*.*.rabbit) * 第一个单词是 lazy 的多个单词(lazy.#) */ HashMap<String, String> bindingKeyMap = new HashMap<>(); bindingKeyMap.put("quick.orange.rabbit", "被队列 Q1Q2 接收到"); bindingKeyMap.put("lazy.orange.elephant", "被队列 Q1Q2 接收到"); bindingKeyMap.put("quick.orange.fox", "被队列 Q1 接收到"); bindingKeyMap.put("lazy.brown.fox", "被队列 Q2 接收到"); bindingKeyMap.put("lazy.pink.rabbit", "虽然满足两个绑定但只被队列 Q2 接收一次"); bindingKeyMap.put("quick.brown.fox", "不匹配任何绑定不会被任何队列接收到会被丢弃"); bindingKeyMap.put("quick.orange.male.rabbit", "是四个单词不匹配任何绑定会被丢弃"); bindingKeyMap.put("lazy.orange.male.rabbit", "是四个单词但匹配 Q2"); for (Map.Entry<String,String> bindingKeyEntry : bindingKeyMap.entrySet()){ String routingKey = bindingKeyEntry.getKey(); String message = bindingKeyEntry.getValue(); channel.basicPublish(EXCHANGE_NAME,routingKey,null,message.getBytes("UTF-8")); System.out.println("生产者发出消息:"+message); } } }
消费者1
public class ReceiveLogsTopic01 { //交换机的名称 public static final String EXCHANGE_NAME = "topic_logs"; //接收消息 public static void main(String[] args) throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); //声明交换机 channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.TOPIC); //声明队列 String queueName = "Q1"; channel.queueDeclare(queueName,false,false,false,null); channel.queueBind(queueName,EXCHANGE_NAME,"*.orange.*"); System.out.println("等待接收消息..."); DeliverCallback deliverCallback = (consumerTag,message) -> { System.out.println(new String(message.getBody(),"UTF-8")); System.out.println("接收队列:"+queueName+" 绑定键:"+message.getEnvelope().getRoutingKey()); }; //接收消息 channel.basicConsume(queueName,true,deliverCallback,consumerTag ->{}); } }
消费者2
public class ReceiveLogsTopic02 { //交换机的名称 public static final String EXCHANGE_NAME = "topic_logs"; //接收消息 public static void main(String[] args) throws IOException, TimeoutException { Channel channel = RabbitMQUtils.getChannel(); //声明交换机 channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.TOPIC); //声明队列 String queueName = "Q2"; channel.queueDeclare(queueName,false,false,false,null); channel.queueBind(queueName,EXCHANGE_NAME,"*.*.rabbit"); channel.queueBind(queueName,EXCHANGE_NAME,"lazy.#"); System.out.println("等待接收消息..."); DeliverCallback deliverCallback = (consumerTag,message) -> { System.out.println(new String(message.getBody(),"UTF-8")); System.out.println("接收队列:"+queueName+" 绑定键:"+message.getEnvelope().getRoutingKey()); }; //接收消息 channel.basicConsume(queueName,true,deliverCallback,consumerTag ->{}); } }
结果
6. 死信队列
6.1 死信的概念
先从概念解释上搞清楚这个定义,死信,顾名思义就是无法被消费的消息,字面意思可以这样理解,一般来说,producer 将消息投递到 broker 或者直接到queue 里了,consumer 从 queue 取出消息进行消费,但某些时候由于特定的原因导致 queue 中的某些消息无法被消费,这样的消息如果没有后续的处理,就变成了死信,有死信自然就有了死信队列。
应用场景:为了保证订单业务的消息数据不丢失,需要使用到 RabbitMQ 的死信队列机制,当消息消费发生异常时,将消息投入死信队列中。还有比如说:用户在商城下单成功并点击去支付后在指定时间未支付时自动失效。
6.2 死信的来源
消息 TTL 过期
TTL是 Time To Live 的缩写, 也就是生存时间
队列达到最大长度
队列满了,无法再添加数据到 MQ 中
消息被拒绝
(basicReject 或 basicNack) 并且 requeue = false
6.3 死信实战
交换机类型是 direct
,两个消费者,一个生产者,两个队列:消息队列和死信队列
6.3.1 消息TTL过期
这里的消息的TTL可以选择在生产者或者普通队列这里设置,我这里选择的是在生产者处设置,在实际的开发中更为灵活
生产者
package rabbitmq.nxz.six; import com.rabbitmq.client.AMQP; import com.rabbitmq.client.BuiltinExchangeType; import com.rabbitmq.client.Channel; import rabbitmq.nxz.util.RabbitMQUtils; import java.util.HashMap; /** * @author 念心卓 * @version 1.0 * @description: 生产者 * @date 2023/4/24 12:16 */ public class Producer { //普通交换机的名称 public static final String NORMAL_EXCHANGE = "normal_exchange"; //死信交换机 public static final String DEAD_EXCHANGE = "dead_exchange"; //普通队列的名称 public static final String NORMAL_QUEUE = "normal_queue"; public static void main(String[] args) throws Exception{ //这里的生产者只和普通交换机打交道 Channel channel = RabbitMQUtils.getChannel(); channel.exchangeDeclare(NORMAL_EXCHANGE, BuiltinExchangeType.DIRECT); channel.exchangeDeclare(DEAD_EXCHANGE,BuiltinExchangeType.DIRECT); //声明普通队列,设置参数(这里面的键不能随便写,是固定的) HashMap<String, Object> arguments = new HashMap<>(); //将普通队列和死信队列产生关系 arguments.put("x-dead-letter-exchange",DEAD_EXCHANGE); //设置死信routingKey arguments.put("x-dead-letter-routing-key","lisi"); channel.queueDeclare(NORMAL_QUEUE,false,false,false,arguments); //绑定普通的交换机与队列 channel.queueBind(NORMAL_QUEUE,NORMAL_EXCHANGE,"zhangsan"); //设置TTL为10S,expiration中单位是ms AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder().expiration("10000").build(); //发送10条消息 for (int i = 1; i <11 ; i++) { String message = "info"+i; channel.basicPublish(NORMAL_EXCHANGE,"zhangsan",properties,message.getBytes()); } } }
消费者01(启动之后关闭该消费者 模拟其接收不到消息)
package rabbitmq.nxz.six; import com.rabbitmq.client.BuiltinExchangeType; import com.rabbitmq.client.Channel; import com.rabbitmq.client.DeliverCallback; import rabbitmq.nxz.util.RabbitMQUtils; import java.util.HashMap; import java.util.Objects; /** * @author 念心卓 * @version 1.0 * @description: 消费者01 * @date 2023/4/24 12:21 */ public class Consumer01 { //普通交换机的名称 public static final String NORMAL_EXCHANGE = "normal_exchange"; //死信交换机的名称 public static final String DEAD_EXCHANGE = "dead_exchange"; //普通队列的名称 public static final String NORMAL_QUEUE = "normal_queue"; //死信队列的名称 public static final String DEAD_QUEUE = "dead_queue"; public static void main(String[] args) throws Exception{ Channel channel = RabbitMQUtils.getChannel(); //声明交换机 channel.exchangeDeclare(NORMAL_EXCHANGE, BuiltinExchangeType.DIRECT); channel.exchangeDeclare(DEAD_EXCHANGE,BuiltinExchangeType.DIRECT); //声明普通队列 //声明普通队列,设置参数(这里面的键不能随便写,是固定的) HashMap<String, Object> arguments = new HashMap<>(); //将普通队列和死信队列产生关系 arguments.put("x-dead-letter-exchange",DEAD_EXCHANGE); //设置死信routingKey arguments.put("x-dead-letter-routing-key","lisi"); channel.queueDeclare(NORMAL_QUEUE,false,false,false,arguments); //绑定普通的交换机与队列 channel.queueBind(NORMAL_QUEUE,NORMAL_EXCHANGE,"zhangsan"); //声明死信队列 channel.queueDeclare(DEAD_QUEUE,false,false,false,null); //绑定死信的交换机与死信的队列 channel.queueBind(DEAD_QUEUE,DEAD_EXCHANGE,"lisi"); System.out.println("等待接收消息..."); channel.basicConsume( NORMAL_QUEUE, true, (consumerTag, message) -> System.out.println("Consumer01接受的消息是:"+new String(message.getBody(),"UTF-8")), consumerTag -> {}); } }
先启动消费者 1,然后停止该 1 的运行,则 1 将无法收到队列的消息,无法收到的消息 10 秒后进入死信队列。启动生产者 producer 生产消息,注意不要开启死信消费者。
生产者未发送消息
生产者发送了10条消息,此时正常消息队列有10条未消费消息
时间过去10秒,正常队列里面的消息由于没有被消费,消息进入死信队列
消费者 2
package rabbitmq.nxz.six; import com.rabbitmq.client.BuiltinExchangeType; import com.rabbitmq.client.Channel; import com.rabbitmq.client.DeliverCallback; import rabbitmq.nxz.util.RabbitMQUtils; /** * @author 念心卓 * @version 1.0 * @description: 消费者02 * @date 2023/4/24 12:21 */ public class Consumer02 { //死信队列的名称 public static final String DEAD_QUEUE = "dead_queue"; //死信交换机的名称 public static final String DEAD_EXCHANGE = "dead_exchange"; public static void main(String[] args) throws Exception{ Channel channel = RabbitMQUtils.getChannel(); channel.queueDeclare(DEAD_QUEUE,false,false,false,null); //绑定死信的交换机与死信的队列 channel.queueBind(DEAD_QUEUE,DEAD_EXCHANGE,"lisi"); System.out.println("等待接收死信消息..."); DeliverCallback deliverCallback = (consumerTag, message) ->{ System.out.println("Consumer02接受的消息是:"+new String(message.getBody(),"UTF-8")); }; channel.basicConsume(DEAD_QUEUE,true,deliverCallback,consumerTag -> {}); } }
等待接收死信消息... Consumer02接受的消息是:info1 Consumer02接受的消息是:info2 Consumer02接受的消息是:info3 Consumer02接受的消息是:info4 Consumer02接受的消息是:info5 Consumer02接受的消息是:info6 Consumer02接受的消息是:info7 Consumer02接受的消息是:info8 Consumer02接受的消息是:info9 Consumer02接受的消息是:info10
6.3.2 队列达到最大长度
消息生产者代码去掉 TTL 属性,
basicPublish
的第三个参数改为 nullpackage rabbitmq.nxz.six; import com.rabbitmq.client.AMQP; import com.rabbitmq.client.BuiltinExchangeType; import com.rabbitmq.client.Channel; import rabbitmq.nxz.util.RabbitMQUtils; import java.util.HashMap; /** * @author 念心卓 * @version 1.0 * @description: 生产者 * @date 2023/4/24 12:16 */ public class Producer { //普通交换机的名称 public static final String NORMAL_EXCHANGE = "normal_exchange"; //死信交换机 public static final String DEAD_EXCHANGE = "dead_exchange"; //普通队列的名称 public static final String NORMAL_QUEUE = "normal_queue"; public static void main(String[] args) throws Exception{ //这里的生产者只和普通交换机打交道 Channel channel = RabbitMQUtils.getChannel(); channel.exchangeDeclare(NORMAL_EXCHANGE, BuiltinExchangeType.DIRECT); channel.exchangeDeclare(DEAD_EXCHANGE,BuiltinExchangeType.DIRECT); //声明普通队列,设置参数(这里面的键不能随便写,是固定的) HashMap<String, Object> arguments = new HashMap<>(); //将普通队列和死信队列产生关系 arguments.put("x-dead-letter-exchange",DEAD_EXCHANGE); //设置死信routingKey arguments.put("x-dead-letter-routing-key","lisi"); channel.queueDeclare(NORMAL_QUEUE,false,false,false,arguments); //绑定普通的交换机与队列 channel.queueBind(NORMAL_QUEUE,NORMAL_EXCHANGE,"zhangsan"); //设置TTL为10S,expiration中单位是ms // AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder().expiration("10000").build(); //发送10条消息 for (int i = 1; i <11 ; i++) { String message = "info"+i; channel.basicPublish(NORMAL_EXCHANGE,"zhangsan",null,message.getBytes()); } } }
在消费者1加上以下代码(启动之后关闭该消费者 模拟其接收不到消息)
arguments.put("x-max-length",6);
注意
因为参数改变了,所以需要把原先队列删除
消费者2代码不变
启动消费者1,创建出队列,然后停止运行,启动生产者
可以看见当前普通队列最大只能容纳6条消息,其余的消息都在死信队列中
启动 消费者2
等待接收死信消息... Consumer02接受的消息是:info1 Consumer02接受的消息是:info2 Consumer02接受的消息是:info3 Consumer02接受的消息是:info4
6.3.3 消息被拒
- 消息生产者代码同上生产者一致
- 需求:消费者 1 拒收消息 “info5”,开启手动应答
消费者1
package rabbitmq.nxz.six; import com.rabbitmq.client.BuiltinExchangeType; import com.rabbitmq.client.Channel; import com.rabbitmq.client.DeliverCallback; import rabbitmq.nxz.util.RabbitMQUtils; import java.util.HashMap; import java.util.Objects; /** * @author 念心卓 * @version 1.0 * @description: 消费者01 * @date 2023/4/24 12:21 */ public class Consumer01 { //普通交换机的名称 public static final String NORMAL_EXCHANGE = "normal_exchange"; //死信交换机的名称 public static final String DEAD_EXCHANGE = "dead_exchange"; //普通队列的名称 public static final String NORMAL_QUEUE = "normal_queue"; //死信队列的名称 public static final String DEAD_QUEUE = "dead_queue"; public static void main(String[] args) throws Exception{ Channel channel = RabbitMQUtils.getChannel(); //声明交换机 channel.exchangeDeclare(NORMAL_EXCHANGE, BuiltinExchangeType.DIRECT); channel.exchangeDeclare(DEAD_EXCHANGE,BuiltinExchangeType.DIRECT); //声明普通队列 //声明普通队列,设置参数(这里面的键不能随便写,是固定的) HashMap<String, Object> arguments = new HashMap<>(); //将普通队列和死信队列产生关系 arguments.put("x-dead-letter-exchange",DEAD_EXCHANGE); //设置死信routingKey arguments.put("x-dead-letter-routing-key","lisi"); // arguments.put("x-max-length",6); channel.queueDeclare(NORMAL_QUEUE,false,false,false,arguments); //绑定普通的交换机与队列 channel.queueBind(NORMAL_QUEUE,NORMAL_EXCHANGE,"zhangsan"); //声明死信队列 channel.queueDeclare(DEAD_QUEUE,false,false,false,null); //绑定死信的交换机与死信的队列 channel.queueBind(DEAD_QUEUE,DEAD_EXCHANGE,"lisi"); System.out.println("等待接收消息..."); channel.basicConsume( NORMAL_QUEUE, false,//开启手动应答,也就是关闭手动应答 (consumerTag, message) -> { String msg = new String(message.getBody(), "UTF-8"); System.out.println("Consumer01接受的消息是:"+msg); if(msg.equals("info5")){ System.out.println("Consumer01接受的消息是:"+msg+": 此消息是被C1拒绝的"); //requeue 设置为 false 代表拒绝重新入队 该队列如果配置了死信交换机将发送到死信队列中 channel.basicReject(message.getEnvelope().getDeliveryTag(), false); }else { System.out.println("Consumer01接受的消息是:"+msg); channel.basicAck(message.getEnvelope().getDeliveryTag(), false); } }, consumerTag -> {}); } }
开启消费者1,创建出队列,然后停止运行,启动生产者
启动消费者 1 等待 10 秒之后,再启动消费者 2
等待接收死信消息... Consumer02接受的消息是:info5
7. 延迟队列
7.1 延迟队列的概念
延时队列,队列内部是有序的,最重要的特性就体现在它的延时属性上,延时队列中的元素是希望在指定时间到了以后或之前取出和处理,简单来说,延时队列就是用来存放需要在指定时间被处理的元素的队列。
7.2 延迟队列使用场景
- 订单在十分钟之内未支付则自动取消
- 新创建的店铺,如果在十天内都没有上传过商品,则自动发送消息提醒
- 用户注册成功后,如果三天内没有登陆则进行短信提醒
- 用户发起退款,如果三天内没有得到处理则通知相关运营人员
- 预定会议后,需要在预定的时间点前十分钟通知各个与会人员参加会议
这些场景都有一个特点,需要在某个事件发生之后或者之前的指定时间点完成某一项任务,如: 发生订单生成事件,在十分钟之后检查该订单支付状态,然后将未支付的订单进行关闭;那我们一直轮询数据,每秒查一次,取出需要被处理的数据,然后处理不就完事了吗?
如果数据量比较少,确实可以这样做,比如:对于「如果账单一周内未支付则进行自动结算」这样的需求, 如果对于时间不是严格限制,而是宽松意义上的一周,那么每天晚上跑个定时任务检查一下所有未支付的账单,确实也是一个可行的方案。但对于数据量比较大,并且时效性较强的场景,如:「订单十分钟内未支付则关闭」,短期内未支付的订单数据可能会有很多,活动期间甚至会达到百万甚至千万级别,对这么庞大的数据量仍旧使用轮询的方式显然是不可取的,很可能在一秒内无法完成所有订单的检查,同时会给数据库带来很大压力,无法满足业务要求而且性能低下。
7.3 TTL的两种设置
TTL 是什么呢?TTL 是 RabbitMQ
中一个消息或者队列的属性,表明一条消息或者该队列中的所有消息的最大存活时间,单位是毫秒。
换句话说,如果一条消息设置了 TTL 属性或者进入了设置 TTL 属性的队列,那么这条消息如果在 TTL 设置的时间内没有被消费,则会成为「死信」。如果同时配置了队列的 TTL 和消息的 TTL,那么较小的那个值将会被使用,有两种方式设置 TTL。
队列设置 TTL
在创建队列的时候设置队列的 x-message-ttl
属性
Map<String, Object> params = new HashMap<>();
params.put("x-message-ttl",5000);
return QueueBuilder.durable("QA").withArguments(args).build(); // QA 队列的最大存活时间位 5000 毫秒
消息设置 TTL
针对每条消息设置 TTL
rabbitTemplate.converAndSend("X","XC",message,correlationData -> {
correlationData.getMessageProperties().setExpiration("5000");
});
两个代码块来自下方的案例
两者区别
如果设置了队列的 TTL 属性,那么一旦消息过期,就会被队列丢弃(如果配置了死信队列被丢到死信队列中),而第二种方式,消息即使过期,也不一定会被马上丢弃,因为消息是否过期是在即将投递到消费者之前判定的,如果当前队列有严重的消息积压情况,则已过期的消息也许还能存活较长时间,具体看下方案例。
另外,还需要注意的一点是,如果不设置 TTL,表示消息永远不会过期,如果将 TTL 设置为 0,则表示除非此时可以直接投递该消息到消费者,否则该消息将会被丢弃
7.4 整合SpringBoot
前一小节我们介绍了死信队列,刚刚又介绍了 TTL,至此利用 RabbitMQ
实现延时队列的两大要素已经集齐,接下来只需要将它们进行融合,再加入一点点调味料,延时队列就可以新鲜出炉了。想想看,延时队列,不就是想要消息延迟多久被处理吗,TTL 则刚好能让消息在延迟多久之后成为死信,另一方面,成为死信的消息都会被投递到死信队列里,这样只需要消费者一直消费死信队列里的消息就完事了,因为里面的消息都是希望被立即处理的消息。
创建一个 Maven 工程或者 Spring Boot工程
添加依赖,这里的 Spring Boot 是2.5.4 版本
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> <!--RabbitMQ 依赖--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId> </dependency> <dependency> <groupId>com.alibaba.fastjson2</groupId> <artifactId>fastjson2</artifactId> <version>2.0.23</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> </dependency> <dependency> <groupId>io.springfox</groupId> <artifactId>springfox-swagger2</artifactId> <version>2.9.2</version> </dependency> <dependency> <groupId>io.springfox</groupId> <artifactId>springfox-swagger-ui</artifactId> <version>2.9.2</version> </dependency> </dependencies>
创建
application.yml
文件server: port: 8555 #可以自己决定 spring: rabbitmq: host: 自己的服务地址 #RabbitMQ服务地址,这里我填写的是我的虚拟机ip port: 5672 #这个端口才是RabbitMQ的服务端口,15672是他的web访问端口 username: RabbitMQ的账号 password: RabbitMQ密码
7.5 队列的TTL
7.5.1 代码的架构图
创建两个队列 QA 和 QB,两个队列的 TTL 分别设置为 10S 和 40S,然后再创建一个交换机 X 和死信交换机 Y,它们的类型都是 direct
,创建一个死信队列 QD,它们的绑定关系如下:
原先配置队列信息,写在了生产者和消费者代码中,现在可写在配置类中,生产者只发消息,消费者只接受消息
7.5.2 配置类代码
package com.nxz.rabbitmq.config;
import org.springframework.amqp.core.*;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import java.util.HashMap;
import java.util.Map;
/**
* @author 念心卓
* @version 1.0
* @description: TTL队列 配置文件类代码
* @date 2023/4/24 17:19
*/
@Configuration
public class TtlQueueConfig {
//普通交换机的名称
public static final String X_EXCHANGE="X";
//死信交换机的名称
public static final String Y_DEAD_LETTER_EXCHANGE="Y";
//普通队列的名称
public static final String QUEUE_A="QA";
public static final String QUEUE_B="QB";
//死信队列的名称
public static final String DEAD_LETTER_QUEUE="QD";
//先创建2个直接类型的交换机
//普通交换机
@Bean
public DirectExchange xExchange(){
return new DirectExchange(X_EXCHANGE);
}
//死信交换机
@Bean
public DirectExchange yExchange(){
return new DirectExchange(Y_DEAD_LETTER_EXCHANGE);
}
//创建3个队列,2个普通队列,1个死信队列
@Bean
public Queue qAQueue(){
Map<String,Object> arguments = new HashMap<>(3);
//设置死信交换机
arguments.put("x-dead-letter-exchange",Y_DEAD_LETTER_EXCHANGE);
//设置死信RoutingKey
arguments.put("x-dead-letter-routing-key","YD");
//设置TTL 10s 单位是ms
arguments.put("x-message-ttl",10000);
return QueueBuilder.durable(QUEUE_A).withArguments(arguments).build();
}
@Bean
public Queue qBQueue(){
Map<String,Object> arguments = new HashMap<>(3);
//设置死信交换机
arguments.put("x-dead-letter-exchange",Y_DEAD_LETTER_EXCHANGE);
//设置死信RoutingKey
arguments.put("x-dead-letter-routing-key","YD");
//设置TTL 10s 单位是ms
arguments.put("x-message-ttl",40000);
return QueueBuilder.durable(QUEUE_B).withArguments(arguments).build();
}
@Bean
public Queue qDQueue(){
return QueueBuilder.durable(DEAD_LETTER_QUEUE).build();
}
//绑定交换机
@Bean
public Binding queueQABindingX(Queue qAQueue,DirectExchange xExchange){
return BindingBuilder.bind(qAQueue).to(xExchange).with("XA");
}
@Bean
public Binding queueQBBindingX(Queue qBQueue,DirectExchange xExchange){
return BindingBuilder.bind(qBQueue).to(xExchange).with("XB");
}
@Bean
public Binding queueQDBindingX(Queue qDQueue,DirectExchange yExchange){
return BindingBuilder.bind(qDQueue).to(yExchange).with("YD");
}
}
7.5.3 生产者
Controller 层代码,获取消息,放到 RabbitMQ 里
package com.nxz.rabbitmq.controller;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import javax.annotation.Resource;
import java.time.LocalDateTime;
/**
* @author 念心卓
* @version 1.0
* @description: 生产者
* @date 2023/4/24 17:54
*/
@RestController
@Slf4j
@RequestMapping("/ttl")
public class Producer {
@Resource
private RabbitTemplate rabbitTemplate;
//开始发消息
@GetMapping("/sendMsg/{message}")
public void sendMsg(@PathVariable("message") String message){
log.info("当前时间:{},发送一条信息给两个TTL队列:{}", LocalDateTime.now(),message);
rabbitTemplate.convertAndSend("X","XA","消息来自ttl为10s的队列:"+message);
rabbitTemplate.convertAndSend("X","XB","消息来自ttl为40s的队列:"+message);
}
}
7.5.4 监听器
package com.nxz.rabbitmq.listener;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;
import java.time.LocalDateTime;
/**
* @author 念心卓
* @version 1.0
* @description: 消费者,监听生产者发送的代码
* @date 2023/4/24 18:04
*/
@Component
@Slf4j
public class DeadLetterQueueConsumer {
@RabbitListener(queues = "QD")
public void receiveD(String msg){
log.info("当前时间:{},收到死信队列的消息:{}", LocalDateTime.now(),msg);
}
}
发送一个请求:http://localhost:8888/ttl/sendMsg/producer
第一条消息在 10S 后变成了死信消息,然后被消费者消费掉,第二条消息在 40S 之后变成了死信消息, 然后被消费掉,这样一个延时队列就打造完成了。
不过,如果这样使用的话,岂不是每增加一个新的时间需求,就要新增一个队列,这里只有 10S 和 40S 两个时间选项,如果需要一个小时后处理,那么就需要增加 TTL 为一个小时的队列,如果是预定会议室然后提前通知这样的场景,岂不是要增加无数个队列才能满足需求?
7.6 延迟队列的优化
在这里新增了一个队列 QC,该队列不设置 TTL 时间,根据前端的请求确定 TTL 时间,绑定关系如下:
7.6.1 配置类代码
新增一个配置文件类,用于新增队列 QC,也可以放在上方的配置文件类里
//普通队列的名称
public static final String QUEUE_C = "QC";
@Bean
public Queue qCQueue(){
Map<String,Object> arguments = new HashMap<>(3);
//设置死信交换机
arguments.put("x-dead-letter-exchange",Y_DEAD_LETTER_EXCHANGE);
//设置死信RoutingKey
arguments.put("x-dead-letter-routing-key","YD");
return QueueBuilder.durable(QUEUE_C).withArguments(arguments).build();
}
//声明队列 QC 绑定 X 交换机
@Bean
public Binding queueCBindingX(Queue qCQueue, DirectExchange xExchange){
return BindingBuilder.bind(qCQueue).to(xExchange).with("XC");
}
7.6.2 生产者
Controller 新增方法
该方法接收的请求要带有 TTL 时间
//开始发消息 发TTL
@GetMapping("/sendExpirationMsg/{message}/{ttlTime}")
public void sendMsg(@PathVariable("message") String message,
@PathVariable("ttlTime") String ttlTime){
log.info("当前时间:{},发送一条时长是{}毫秒TTL信息给队列QC:{}",
LocalDateTime.now(),ttlTime,message);
rabbitTemplate.convertAndSend("X","XC",message,msg -> {
//发送消息的时候的延迟时长
msg.getMessageProperties().setExpiration(ttlTime);
return msg;
});
}
重启服务发送请求:
http://localhost:8888/ttl/sendExpirationMsg/你好1/20000
http://localhost:8888/ttl/sendExpirationMsg/你好2/2000
可以看出,以上结果其实是有问题的,当第一条消息发出过后,TTL是20S,第二条消息的TTL是2S,但是最后的结果却是等20S过了之后2S的消息才被死信队列消费,正常的应该是2S的先被消费。
因为 RabbitMQ
只会检查第一个消息是否过期,如果过期则丢到死信队列, 如果第一个消息的延时时长很长,而第二个消息的延时时长很短,第二个消息并不会优先得到执行。
7.7 Rabbitmq插件实现延迟队列
上文中提到的问题,确实是一个问题,如果不能实现在消息粒度上的 TTL,并使其在设置的 TTL 时间及时死亡,就无法设计成一个通用的延时队列。那如何解决呢,接下来我们就去解决该问题。
7.7.1 安装延时队列插件
可去官网下载找到 rabbitmq_delayed_message_exchange 插件,放置到 RabbitMQ
的插件目录。
因为官网也是跳转去该插件的 GitHub 地址进行下载:点击跳转
打开 Linux,用 Xftp
将插件放到 RabbitMQ
的安装目录下的 plgins 目录,
RabbitMQ
与其 plgins 目录默认分别位于
# RabbitMQ 安装目录
cd /usr/lib/rabbitmq/lib/rabbitmq_server-3.11.13
# RabbitMQ 的 plgins 所在目录
cd /usr/lib/rabbitmq/lib/rabbitmq_server-3.11.13/plugins
其中我的版本是 /rabbitmq_server-3.11.13
进入目录后执行下面命令让该插件生效,然后重启 RabbitMQ
# 安装
rabbitmq-plugins enable rabbitmq_delayed_message_exchange
# 重启服务
systemctl restart rabbitmq-server
[root@localhost plugins]# rabbitmq-plugins enable rabbitmq_delayed_message_exchange
Enabling plugins on node rabbit@localhost:
rabbitmq_delayed_message_exchange
The following plugins have been configured:
rabbitmq_delayed_message_exchange
rabbitmq_management
rabbitmq_management_agent
rabbitmq_web_dispatch
Applying plugin configuration to rabbit@localhost...
The following plugins have been enabled:
rabbitmq_delayed_message_exchange
started 1 plugins.
解释
安装命令不能出现插件版本和后缀,如
rabbitmq-plugins enable rabbitmq_delayed_message_exchange-3.8.0.ez
会报错必须是
rabbitmq-plugins enable rabbitmq_delayed_message_exchange
,后面不允许填入版本和文件后缀
打开 Web 界面,查看交换机的新增功能列表,如果多出了如图所示,代表成功添加插件
7.7.2 代码架构图
在这里新增了一个队列 delayed.queue,一个自定义交换机 delayed.exchange,绑定关系如下:
7.7.3 配置类代码
新增一个配置类 DelayedQueueConfig
,也可以放在原来的配置文件里,代码里使用了 CustomExchange
类,通过参数来自定义一个类型(direct、topic等)
在我们自定义的交换机中,这是一种新的交换类型,该类型消息支持延迟投递机制消息传递后并不会立即投递到目标队列中,而是存储在 mnesia(一个分布式数据系统)表中,当达到投递时间时,才投递到目标队列中。
package com.nxz.rabbitmq.config;
import org.springframework.amqp.core.Binding;
import org.springframework.amqp.core.BindingBuilder;
import org.springframework.amqp.core.CustomExchange;
import org.springframework.amqp.core.Queue;
import org.springframework.context.annotation.Bean;
import java.util.HashMap;
import java.util.Map;
/**
* @author 念心卓
* @version 1.0
* @description: 延迟队列(使用插件)
* @date 2023/4/24 21:48
*/
@Configuration
public class DelayedQueueConfig {
//交换机
public static final String DELAYED_EXCHANGE_NAME = "delayed.exchange";
//队列
public static final String DELAYED_QUEUE_NAME = "delayed.queue";
//routingKey
public static final String DELAYED_ROUTING_KEY = "delayed.routingkey";
@Bean
public CustomExchange delayedExchange(){
Map<String,Object> arguments = new HashMap<>();
//延迟的类型为直接类型
arguments.put("x-delayed-type","direct");
/**
* 1.交换机的名称
* 2.交换机的类型 x-delayed-message
* 3.是否需要持久化
* 4.是否需要自动删除
* 5.其他的参数
*/
return new CustomExchange(DELAYED_EXCHANGE_NAME,"x-delayed-message",
true,false,arguments);
}
@Bean
public Queue delayedQueue(){
return new Queue(DELAYED_QUEUE_NAME);
}
//绑定
@Bean
public Binding delayedQueueBindingDelayedExchange(Queue delayedQueue, CustomExchange delayedExchange){
return BindingBuilder.bind(delayedQueue).to(delayedExchange)
.with(DELAYED_ROUTING_KEY).noargs();
}
}
因为
"x-delayed-message"
类型的交换机是一个插件提供的自定义类型,它并不是标准的 AMQP 类型。因此,我们需要通过设置参数 “x-delayed-type” 来告诉 RabbitMQ 实际使用的是哪个标准类型的交换机,这里指明的是 “direct” 类型的交换机。因为延迟队列的消息需要根据 routing key 进行转发,而直接类型的交换机正好可以根据 routing key 直接将消息发送到与其绑定的队列。因此,在这里我们指定了 “direct” 类型的交换机来实现延迟队列的功能。
7.7.4 生产者
在 controller 里新增一个方法
//开始发消息,基于插件的 消息及 延迟的时间
@GetMapping("/sendDelayMsg/{message}/{delayTime}")
public void sendMsg(@PathVariable("message") String message,
@PathVariable("delayTime") Integer delayTime){
log.info("当前时间:{},发送一条时长是{}毫秒TTL信息给延迟队列delayed.queue:{}",
new Date().toString(),delayTime,message);
rabbitTemplate.convertAndSend(DelayedQueueConfig.DELAYED_EXCHANGE_NAME,
DelayedQueueConfig.DELAYED_ROUTING_KEY,message, msg -> {
//发送消息的时候的延迟时长 单位ms
msg.getMessageProperties().setDelay(delayTime);
return msg;
});
}
7.7.5 消费者代码
监听延迟队列,如果有消息进入该队列,则打印到控制台
package com.nxz.rabbitmq.listener;
import com.nxz.rabbitmq.config.DelayedQueueConfig;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;
import java.time.LocalDateTime;
/**
* @author 念心卓
* @version 1.0
* @description: TODO
* @date 2023/4/24 21:59
*/
@Component
@Slf4j
public class DelayQueueConsumer {
@RabbitListener(queues = DelayedQueueConfig.DELAYED_QUEUE_NAME)
public void receiveDelayQueue(String message){
log.info("当前时间:{},收到延时队列的消息:{}", LocalDateTime.now(), message);
}
}
发送请求:
http://localhost:8656/ttl/sendDelayMsg/你好1/20000
http://localhost:8656/ttl/sendDelayMsg/你好2/2000
7.8 总结
延时队列在需要延时处理的场景下非常有用,使用 RabbitMQ
来实现延时队列可以很好的利用 RabbitMQ
的特性,如:消息可靠发送、消息可靠投递、死信队列来保障消息至少被消费一次以及未被正确处理的消息不会被丢弃。另外,通过 RabbitMQ
集群的特性,可以很好的解决单点故障问题,不会因为单个节点挂掉导致延时队列不可用或者消息丢失。
当然,延时队列还有很多其它选择,比如利用 Java 的 DelayQueue,利用 Redis 的 zset,利用 Quartz 或者利用 kafka 的时间轮,这些方式各有特点,看需要适用的场景。
8. 发布确认高级
在生产环境中由于一些不明原因,导致 RabbitMQ
重启,在 RabbitMQ
重启期间生产者消息投递失败,导致消息丢失,需要手动处理和恢复。于是,我们开始思考,如何才能进行 RabbitMQ
的消息可靠投递呢?
简单的发布确认机制在第四节已经介绍,本内容将介绍整合了 SpringBoot 的发布确认机制。
8.1 介绍
首先发布消息后进行备份在缓存里,如果消息成功发布确认到交换机,则从缓存里删除该消息,如果没有成功发布,则设置一个定时任务,重新从缓存里获取消息发布到交换机,直到成功发布到交换机。
8.2 实战
一个交换机:confirm.exchange
,一个队列:confirm.queue
,一个消费者:confirm.consumer
其中交换机类型时 direct
,与队列关联的 routingKey 是 key1
代码架构图:
在配置文件当中需要添加:
server:
port: 8656
spring:
rabbitmq:
host:
port:
username:
password:
publisher-confirm-type: correlated
NONE
值是禁用发布确认模式,是默认值CORRELATED
值是发布消息成功到交换器后会触发回调方法SIMPLE
值经测试有两种效果,其一效果和 CORRELATED 值一样会触发回调方法,其二在发布消息成功后使用 rabbitTemplate 调用 waitForConfirms 或 waitForConfirmsOrDie 方法等待 broker 节点返回发送结果,根据返回结果来判定下一步的逻辑,要注意的点是 waitForConfirmsOrDie 方法如果返回 false 则会关闭 channel,则接下来无法发送消息到 broker;
8.2.1 配置类
package com.nxz.rabbitmq.config;
import org.springframework.amqp.core.*;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
/**
* @author 念心卓
* @version 1.0
* @description: TODO
* @date 2023/4/25 10:34
*/
@Configuration
public class ConfirmConfig {
//交换机
public static final String CONFIRM_EXCHANGE_NAME = "confirm_exchange";
//队列
public static final String CONFIRM_QUEUE_NAME = "confirm_queue";
//routingKey
public static final String CONFIRM_ROUTING_KEY = "key1";
@Bean
public Queue confirmQueue(){
return QueueBuilder.durable(CONFIRM_QUEUE_NAME).build();
}
@Bean
public DirectExchange confirmExchange(){
return new DirectExchange(CONFIRM_EXCHANGE_NAME);
}
@Bean
public Binding queueBindingExchange(Queue confirmQueue,DirectExchange confirmExchange){
return BindingBuilder.bind(confirmQueue).to(confirmExchange).with(CONFIRM_ROUTING_KEY);
}
}
8.2.2 生产者
也可以说是 Controller 层
package com.nxz.rabbitmq.controller;
import com.nxz.rabbitmq.config.ConfirmConfig;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.connection.CorrelationData;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import javax.annotation.Resource;
/**
* @author 念心卓
* @version 1.0
* @description: TODO
* @date 2023/4/25 10:39
*/
@Slf4j
@RestController
@RequestMapping("/confirm")
public class confirmProducer {
@Resource
private RabbitTemplate rabbitTemplate;
//开始发消息,测试确认
@GetMapping("/sendMessage/{message}")
public void sendMessage(@PathVariable("message") String message){
//指定消息 id 为 1
CorrelationData correlationData1 = new CorrelationData("1");
rabbitTemplate.convertAndSend(ConfirmConfig.CONFIRM_EXCHANGE_NAME,
ConfirmConfig.CONFIRM_ROUTING_KEY,message+"key1",correlationData1);
log.info("发送消息内容:{}",message+"key1");
//指定消息 id 为 2
CorrelationData correlationData2 = new CorrelationData("2");
String CONFIRM_ROUTING_KEY = "key2";
rabbitTemplate.convertAndSend(ConfirmConfig.CONFIRM_EXCHANGE_NAME,
CONFIRM_ROUTING_KEY,message+"key2",correlationData2);
log.info("发送消息内容:{}",message+"key2");
}
}
8.2.3 消费者
监听 confirm.queue
队列
package com.nxz.rabbitmq.listener;
import com.nxz.rabbitmq.config.ConfirmConfig;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;
/**
* @author 念心卓
* @version 1.0
* @description: TODO
* @date 2023/4/25 10:41
*/
@Slf4j
@Component
public class ConfirmListener {
@RabbitListener(queues = ConfirmConfig.CONFIRM_QUEUE_NAME)
public void receiveConfirmMessage(String message){
log.info("接受到的队列confirm.queue消息:{}",message);
}
}
8.2.4 消息生产者发布消息后的回调接口
只要生产者发布消息,交换机不管是否收到消息,都会调用该类的 confirm
方法
package com.nxz.rabbitmq.util;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.connection.CorrelationData;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.stereotype.Component;
import javax.annotation.PostConstruct;
import javax.annotation.Resource;
/**
* @author 念心卓
* @version 1.0
* @description: TODO
* @date 2023/4/25 10:43
*/
@Component
@Slf4j
public class MyCallBack implements RabbitTemplate.ConfirmCallback {
//注入
@Resource
private RabbitTemplate rabbitTemplate;
@PostConstruct
public void init(){
//注入
rabbitTemplate.setConfirmCallback(this);
}
/**
* 交换机不管是否收到消息的一个回调方法
* 1. 发消息 交换机接收到了 回调
* @param correlationData 保存回调信息的Id及相关信息
* @param ack 交换机收到消息 为true
* @param cause 未收到消息的原因
*
*/
@Override
public void confirm(CorrelationData correlationData, boolean ack, String cause) {
String id = correlationData!=null?correlationData.getId():"";
if(ack){
log.info("交换机已经收到了ID为:{}的消息",id);
}else {
log.info("交换机还未收到ID为:{}的消息,由于原因:{}",id,cause);
}
}
}
在上面的代码中,
MyCallBack
类实现了RabbitTemplate.ConfirmCallback
接口,并重写了其中的confirm
方法。这个confirm
方法是 RabbitMQ 中的一个回调方法,在生产者发送消息到 RabbitMQ 的交换机后,交换机会通过该回调方法告知生产者消息是否已经被成功处理。而在这个
MyCallBack
类中,我们注入了RabbitTemplate
对象,并在init
方法中将当前类实例设置为RabbitTemplate
对象的ConfirmCallback
。这样,在生产者发送消息时,就可以触发MyCallBack
中的confirm
方法,根据交换机是否已经收到消息,打印相应的日志信息。因此,为了能够监听交换机是否成功接收消息,我们需要在生产者代码中设置
ConfirmCallback
,并注入MyCallBack
实例。
打开浏览器访问地址:http://localhost:8656/confirm/sendMessage/大家好1
可以看到,发送了两条消息,第一条消息的 RoutingKey 为 “key1”,第二条消息的 RoutingKey 为 “key2”,两条消息都成功被交换机接收,也收到了交换机的确认回调,但消费者只收到了一条消息,因为第二条消息的 RoutingKey 与队列的 BindingKey 不一致,也没有其它队列能接收这个消息,所有第二条消息被直接丢弃了。
丢弃的消息交换机是不知道的,需要解决告诉生产者消息传送失败。
8.3 回退消息
获取回退的消息,首先在配置文件开启该功能,然后需要自定义类实现 RabbitTemplate.ReturnsCallback
接口,并且初始化时,使用该自定义类作为回退消息的处理类,同时开启 Mandatory
,设置为 true
在启动开启 Mandatory
,或者在代码里手动开启 Mandatory
参数,或者都开启😸
配置类文件开启:
# 新版
spring:
rabbitmq:
template:
mandatory: true
# 旧版
spring:
rabbitmq:
mandatory: true
代码中开启:
rabbitTemplate.setMandatory(true);
在仅开启了生产者确认机制的情况下,交换机接收到消息后,会直接给消息生产者发送确认消息,如果发现该消息不可路由,那么消息会被直接丢弃,此时生产者是不知道消息被丢弃这个事件的。
那么如何让无法被路由的消息帮我想办法处理一下?最起码通知我一声,我好自己处理啊。通过设置 mandatory
参数可以在当消息传递过程中不可达目的地时将消息返回给生产者。
8.3.1 修改配置文件
server:
port: 8656
spring:
rabbitmq:
host:
port:
username:
password:
publisher-confirm-type: correlated
template:
mandatory: true #加上这个
publisher-returns: true #加上这个
8.3.2 修改回调接口
实现 RabbitTemplate.ReturnsCallback
接口,并实现方法
package com.nxz.rabbitmq.util;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.ReturnedMessage;
import org.springframework.amqp.rabbit.connection.CorrelationData;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.stereotype.Component;
import javax.annotation.PostConstruct;
import javax.annotation.Resource;
/**
* @author 念心卓
* @version 1.0
* @description: TODO
* @date 2023/4/25 10:43
*/
@Component
@Slf4j
public class MyCallBack implements RabbitTemplate.ConfirmCallback,RabbitTemplate.ReturnsCallback {
//注入
@Resource
private RabbitTemplate rabbitTemplate;
@PostConstruct
public void init(){
//注入
rabbitTemplate.setConfirmCallback(this);
rabbitTemplate.setReturnsCallback(this);
}
/**
* 交换机不管是否收到消息的一个回调方法
* 1. 发消息 交换机接收到了 回调
* @param correlationData 保存回调信息的Id及相关信息
* @param ack 交换机收到消息 为true
* @param cause 未收到消息的原因
*
*/
@Override
public void confirm(CorrelationData correlationData, boolean ack, String cause) {
String id = correlationData!=null?correlationData.getId():"";
if(ack){
log.info("交换机已经收到了ID为:{}的消息",id);
}else {
log.info("交换机还未收到ID为:{}的消息,由于原因:{}",id,cause);
}
}
//可以在当消息传递过程中不可达目的地时将消息返回给生产者
//只有不可达目的地的时候 才进行回退
/**
* 当消息无法路由的时候的回调方法
* message 消息
* replyCode 编码
* replyText 退回原因
* exchange 从哪个交换机退回
* routingKey 通过哪个路由 key 退回
*/
@Override
public void returnedMessage(ReturnedMessage returned) {
log.error("消息{},被交换机{}退回,退回原因:{},路由key:{}",
new String(returned.getMessage().getBody()),returned.getExchange(),
returned.getReplyText(),returned.getRoutingKey());
}
}
打开浏览器访问地址:http://localhost:8656/confirm/sendMessage/大家好1
可以看见消息如果没有被正常接收,会被退还给生产者。
8.4 备份交换机
8.4.1 介绍
有了 mandatory
参数和回退消息,我们获得了对无法投递消息的感知能力,有机会在生产者的消息无法被投递时发现并处理。但有时候,我们并不知道该如何处理这些无法路由的消息,最多打个日志,然后触发报警,再来手动处理。而通过日志来处理这些无法路由的消息是很不优雅的做法,特别是当生产者所在的服务有多台机器的时候,手动复制日志会更加麻烦而且容易出错。而且设置 mandatory
参数会增加生产者的复杂性,需要添加处理这些被退回的消息的逻辑。如果既不想丢失消息,又不想增加生产者的复杂性,该怎么做呢?
前面在设置死信队列的文章中,我们提到,可以为队列设置死信交换机来存储那些处理失败的消息,可是这些不可路由消息根本没有机会进入到队列,因此无法使用死信队列来保存消息。 在 RabbitMQ
中,有一种备份交换机的机制存在,可以很好的应对这个问题。
什么是备份交换机呢?备份交换机可以理解为 RabbitMQ
中交换机的“备胎”,当我们为某一个交换机声明一个对应的备份交换机时,就是为它创建一个备胎,当交换机接收到一条不可路由消息时,将会把这条消息转发到备份交换机中,由备份交换机来进行转发和处理,通常备份交换机的类型为 Fanout
,这样就能把所有消息都投递到与其绑定的队列中,然后我们在备份交换机下绑定一个队列,这样所有那些原交换机无法被路由的消息,就会都进入这个队列了。当然,我们还可以建立一个报警队列,用独立的消费者来进行监测和报警。
8.4.2 实战
需要一个备份交换机 backup.exchange
,类型为 fanout
,该交换机发送消息到队列 backup.queue
和 warning.queue
8.4.3 修改高级确认发布配置类
在ConfirmConfig配置类中,新增如下内容:
//关于备份的
//交换机
public static final String BACKUP_EXCHANGE_NAME = "backup_exchange";
//队列
public static final String BACKUP_QUEUE_NAME = "backup_queue";
//报警队列
public static final String WARNING_QUEUE_NAME = "warning_queue
//备份交换机的创建
@Bean()
public FanoutExchange backupExchange(){
return new FanoutExchange(BACKUP_EXCHANGE_NAME);
}
//声明备份队列
@Bean()
public Queue backupQueue(){
return QueueBuilder.durable(BACKUP_QUEUE_NAME).build();
}
//声明报警队列
@Bean()
public Queue warningQueue(){
return QueueBuilder.durable(WARNING_QUEUE_NAME).build();
}
//绑定 备份队列绑定备份交换机
@Bean
public Binding backupQueueBindingBackupExchange(Queue backupQueue, FanoutExchange backupExchange){
return BindingBuilder.bind(backupQueue).to(backupExchange);
}
//绑定 报警队列绑定备份交换机
@Bean
public Binding warningQueueBindingBackupExchange(Queue warningQueue, FanoutExchange backupExchange){
return BindingBuilder.bind(warningQueue).to(backupExchange);
}
修改代码如下图:
@Bean
public DirectExchange confirmExchange(){
return ExchangeBuilder.directExchange(CONFIRM_EXCHANGE_NAME)
.durable(true).withArgument("alternate-exchange",BACKUP_EXCHANGE_NAME).build();
}
8.4.4 报警消费者
package com.nxz.rabbitmq.listener;
import com.nxz.rabbitmq.config.ConfirmConfig;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;
/**
* @author 念心卓
* @version 1.0
* @description: TODO
* @date 2023/4/25 11:25
*/
@Slf4j
@Component
public class WarningConsumer {
//接收报警信息
@RabbitListener(queues = ConfirmConfig.WARNING_QUEUE_NAME)
public void receiveWarningMsg(String message){
log.error("报警发现不可路由消息:{}",message);
}
}
由于之前写过 confirm.exchange
交换机,当更改配置了,需要删掉,不然会报错
打开浏览器访问地址:http://localhost:8656/confirm/sendMessage/大家好1
Mandatory
参数与备份交换机可以一起使用的时候,如果两者同时开启,消息究竟何去何从?谁优先级高,经过上面结果显示答案是备份交换机优先级高。
9. RabbitMQ其他知识点
9.1 幂等性
9.1.1 概念
用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点击而产生了副作用。举个最简单的例子,那就是支付,用户购买商品后支付,支付扣款成功,但是返回结果的时候网络异常,此时钱已经扣了,用户再次点击按钮,此时会进行第二次扣款,返回结果成功,用户查询余额发现多扣钱了,流水记录也变成了两条。在以前的单应用系统中,我们只需要把数据操作放入事务中即可,发生错误立即回滚,但是再响应客户端的时候也有可能出现网络中断或者异常等等。
可以理解为验证码,只能输入一次,再次重新输入会刷新验证码,原来的验证码失效。
9.1.2 消息重复消费
消费者在消费 MQ 中的消息时,MQ 已把消息发送给消费者,消费者在给 MQ 返回 ack 时网络中断, 故 MQ 未收到确认信息,该条消息会重新发给其他的消费者,或者在网络重连后再次发送给该消费者,但实际上该消费者已成功消费了该条消息,造成消费者消费了重复的消息。
9.1.3 解决思路
MQ 消费者的幂等性的解决一般使用全局 ID 或者写个唯一标识比如时间戳 或者 UUID 或者订单消费者消费 MQ 中的消息也可利用 MQ 的该 id 来判断,或者可按自己的规则生成一个全局唯一 id,每次消费消息时用该 id 先判断该消息是否已消费过。
9.1.4 消费端的幂等性保障
在海量订单生成的业务高峰期,生产端有可能就会重复发生了消息,这时候消费端就要实现幂等性,这就意味着我们的消息永远不会被消费多次,即使我们收到了一样的消息。
业界主流的幂等性有两种操作:
- 唯一 ID+ 指纹码机制,利用数据库主键去重
指纹码:我们的一些规则或者时间戳加别的服务给到的唯一信息码,它并不一定是我们系统生成的,基本都是由我们的业务规则拼接而来,但是一定要保证唯一性,然后就利用查询语句进行判断这个 id 是否存在数据库中,优势就是实现简单就一个拼接,然后查询判断是否重复;劣势就是在高并发时,如果是单个数据库就会有写入性能瓶颈当然也可以采用分库分表提升性能,但也不是我们最推荐的方式。
- Redis 的原子性
利用 redis 执行 setnx 命令,天然具有幂等性。从而实现不重复消费
9.2 优先级队列
9.2.1 使用场景
在我们系统中有一个订单催付的场景,我们的客户在天猫下的订单,淘宝会及时将订单推送给我们,如果在用户设定的时间内未付款那么就会给用户推送一条短信提醒,很简单的一个功能对吧。
但是,tmall 商家对我们来说,肯定是要分大客户和小客户的对吧,比如像苹果,小米这样大商家一年起码能给我们创造很大的利润,所以理应当然,他们的订单必须得到优先处理,而曾经我们的后端系统是使用 redis
来存放的定时轮询,大家都知道 redis
只能用 List
做一个简简单单的消息队列,并不能实现一个优先级的场景,所以订单量大了后采用 RabbitMQ
进行改造和优化,如果发现是大客户的订单给一个相对比较高的优先级, 否则就是默认优先级。
9.2.2 添加方法
web添加
声明队列的时候添加优先级
设置队列的最大优先级最大可以设置到 255 官网推荐 1-10 如果设置太高比较吃内存和 CPU
Map<String, Object> params = new HashMap(); // 优先级为 10 params.put("x-max-priority", 10); channel.queueDeclare("hello", true, false, false, params);
注意事项
队列实现优先级需要做的事情有如下:队列需要设置为优先级队列,消息需要设置消息的优先级,消费者需要等待消息已经全部发送到队列中才去消费,因为这样才有机会对消息进行排序
9.2.3 实战
生产者发送十个消息,如果消息为 info5
,则优先级是最高的,当消费者从队列获取消息的时候,优先获取 info5
消息
生产者代码
package rabbitmq.nxz.seven; import com.rabbitmq.client.AMQP; import com.rabbitmq.client.Channel; import rabbitmq.nxz.util.RabbitMQUtils; /** * @author 念心卓 * @version 1.0 * @description: 优先级 生产者 * @date 2023/4/25 11:57 */ public class PriorityProducer { private static final String QUEUE_NAME = "priority_queue"; public static void main(String[] args) throws Exception { Channel channel = RabbitMQUtils.getChannel(); //给消息赋予一个priority属性 AMQP.BasicProperties properties = new AMQP.BasicProperties().builder().priority(1).priority(10).build(); for (int i = 1; i < 11; i++) { String message = "info"+i; if(i==5){ channel.basicPublish("",QUEUE_NAME,properties,message.getBytes()); }else { channel.basicPublish("",QUEUE_NAME,null,message.getBytes()); } System.out.println("消息发送完成:"+message); } } }
消费者代码
package rabbitmq.nxz.seven; import com.rabbitmq.client.CancelCallback; import com.rabbitmq.client.Channel; import com.rabbitmq.client.DeliverCallback; import rabbitmq.nxz.util.RabbitMQUtils; import java.util.HashMap; import java.util.Map; /** * @author 念心卓 * @version 1.0 * @description: 优先级 消费者 * @date 2023/4/25 11:58 */ public class PriorityConsumer { private final static String QUEUE_NAME = "priority_queue"; public static void main(String[] args) throws Exception{ Channel channel = RabbitMQUtils.getChannel(); //设置队列的最大优先级 最大可以设置到255 官网推荐1-10 如果设置太高比较吃内存和CPU Map<String, Object> params = new HashMap<>(); params.put("x-max-priority",10); channel.queueDeclare(QUEUE_NAME,true,false,false,params); //推送消息如何进行消费的接口回调 DeliverCallback deliverCallback = (consumerTag, delivery) ->{ String message = new String(delivery.getBody()); System.out.println("消费的消息: "+message); }; //取消消费的一个回调接口 如在消费的时候队列被删除掉了 CancelCallback cancelCallback = (consumerTag) ->{ System.out.println("消息消费被中断"); }; channel.basicConsume(QUEUE_NAME,true,deliverCallback,cancelCallback); } }
结果
info 5 的优先级为 10,优先级最高。消费者消费信息效果如图:
9.3 惰性队列
9.3.1 使用场景
RabbitMQ
从 3.6.0 版本开始引入了惰性队列的概念。惰性队列会尽可能的将消息存入磁盘中,而在消费者消费到相应的消息时才会被加载到内存中,它的一个重要的设计目标是能够支持更长的队列,即支持更多的消息存储。当消费者由于各种各样的原因(比如消费者下线、宕机亦或者是由于维护而关闭等)而致使长时间内不能消费消息造成堆积时,惰性队列就很有必要了。
默认情况下,当生产者将消息发送到 RabbitMQ
的时候,队列中的消息会尽可能的存储在内存之中,这样可以更加快速的将消息发送给消费者。即使是持久化的消息,在被写入磁盘的同时也会在内存中驻留一份备份。当 RabbitMQ
需要释放内存的时候,会将内存中的消息换页至磁盘中,这个操作会耗费较长的时间,也会阻塞队列的操作,进而无法接收新的消息。虽然 RabbitMQ
的开发者们一直在升级相关的算法, 但是效果始终不太理想,尤其是在消息量特别大的时候。
9.3.2 两种模式
队列具备两种模式:default 和 lazy。默认的为 default 模式,在 3.6.0 之前的版本无需做任何变更。lazy 模式即为惰性队列的模式,可以通过调用 channel.queueDeclare
方法的时候在参数中设置,也可以通过 Policy 的方式设置,如果一个队列同时使用这两种方式设置的话,那么 Policy 的方式具备更高的优先级。如果要通过声明的方式改变已有队列的模式的话,那么只能先删除队列,然后再重新声明一个新的。
在队列声明的时候可以通过 x-queue-mode
参数来设置队列的模式,取值为 default 和 lazy。下面示例中演示了一个惰性队列的声明细节:
Map<String, Object> args = new HashMap<String, Object>();
args.put("x-queue-mode", "lazy");
channel.queueDeclare("myqueue", false, false, false, args);
也可以在 Web 页面添加队列时,选择 Lazy mode
在发送 1 百万条消息,每条消息大概占 1KB 的情况下,普通队列占用内存是 1.2GB,而惰性队列仅仅占用 1.5MB(这个是保存的消息的索引)。
10. RabbitMQ集群
10.1 clustering
10.1.1 使用集群的原因
最开始我们介绍了如何安装及运行RabbitMQ
服务,不过这些是单机版的,无法满足目前真实应用的要求。如果RabbitMQ
服务器遇到内存崩溃、机器掉电或者主板故障等情况,该怎么办?单台RabbitMQ
服务器可以满足每秒1000条消息的吞吐量,那么如果应用需要RabbitMQ
服务满足每秒10万条消息的吞吐量呢?购买昂贵的服务器来增强单机RabbitMQ
业务的性能显得捉襟见肘,搭建一个RabbitMQ
集群才是解决实际问题的关键
10.1.2 搭建步骤
如果是自己的电脑可以使用虚拟机来搭建
右键—>管理—>克隆
克隆出多台虚拟机来模拟集群
克隆出多台之后全部启动,并且使用管理员账户来修改每台虚拟机的名称
vi /etc/host
我这里克隆了3台,分别交node1、node2、node3
配置各个节点的host文件,让各个节点都能互相识别对方
#编辑hosts文件 vim /etc/hosts #加入以下内容 node1虚拟机的IP node1 node2虚拟机的IP node2 node3虚拟机的IP node3
确保各个节点的
cookie
文件使用的是同一个值在node1节点上操作
#操作过程中,会问你:你确定要连接嘛,输入yes,然后输入对应虚拟机的密码 scp /var/lib/rabbitmq/.erlang.cookie root@node2:/var/lib/rabbitmq/.erlang.cookie scp /var/lib/rabbitmq/.erlang.cookie root@node3:/var/lib/rabbitmq/.erlang.cookie
启动
RabbitMQ
服务,顺带启动Erlang
虚拟机和RbbitMQ
应用服务(在三台节点上分别执行以下命令)rabbitmq-server -detached
在节点2执行
rabbitmqctl stop_app (rabbitmqctl stop会将Erlang虚拟机关闭,rabbitmqctl stop_app只关闭RabbitMQ服务) rabbitmqctl reset rabbitmqctl join_cluster rabbit@node1 rabbitmqctl start_app(只启动应用服务)
在节点3执行
#(rabbitmqctl stop会将Erlang虚拟机关闭,rabbitmqctl stop_app只关闭RabbitMQ服务) rabbitmqctl stop_app rabbitmqctl reset rabbitmqctl join_cluster rabbit@node2 #(只启动应用服务) rabbitmqctl start_app
集群状态
rabbitmqctl cluster_status
需要重新设置用户
创建账号
rabbitmqctl add_user admin 123
设置用户角色
rabbitmqctl set_user_tags admin administrator
设置用户权限
rabbitmqctl set_permissions -p / admin ".*" ".*" ".*"
使用刚刚注册的用户登陆
解除集群节点(node2和node3机器分别执行)
#(node1机器上执行) rabbitmqctl stop_app rabbitmqctl reset rabbitmqctl start_app rabbitmqctl cluster_status rabbitmqctl forget_cluster._node rabbit@node2
10.1.3 未完待续
后面还有几个小节的内容,不过对于学习阶段的我展示用不上。