1、MQ的相关概念
1.1、什么是MQ
MQ,本质是队列,FIFO先进先出,只不过队列中存放的内容是message。还是一种跨进程的通信机制,用于上下游传递消息。在互联网架构中,MQ是一种常见的“逻辑解耦合物理解耦”的消息通信服务。使用了MQ之后,消息发送上游需要依赖MQ,不用依赖其他服务。
1.2、为什么要使用MQ
流量削峰
比如说,订单系统最多能处理一万次订单,这个处理能力应付正常时段的下单时绰绰有余,正常时段下单一秒以后就能返回结果,但是在高峰期,如果有两万次下单,操作系统是处理不了的,只能限制订单超过一万后不允许用户继续下单,使用消息队列做缓冲,我们可以取消这个限制,把一秒内下的订单分分散成一段时间来处理,这时有些用户可能在下单十几秒后才能收到下单成功的操作,但是比不能下单的体验要好。
修改前:
人→订单系统
修改后:
人→MQ消息队列【对访问人员进行排队】→订单系统
应用解耦
以电商应用为例,应用中有订单系统、库存系统、物流系统、支付系统。用户创建订单后,如果耦合调用库存、物流、支付系统,任何一个子系统出了故障,都会造成下单操作异常。当转变成基于消息队列的方式后,系统间调用的问题会减少很多,比如物流系统因为发生故障,需要几分钟来修复。在这个几分钟的时间里,物流系统要处理的内存会缓存在消息队列中,用户的下单操作可以正常完成。当物流系统恢复后,继续处理订单信息即可,在这段期间,用户感受不到物流系统的故障,提升系统的可用性。
修改前:
订单系统分别指向支付系统、库存系统、物流系统;
修改后:
订单系统→消息队列【对订单系统的数量进行排队】→分别指向支付系统、库存系统、物流系统;
异步处理
有些服务间到的调用是异步的,比如A调用B,B需要花费很长时间执行,但是A需要知道B什么时候可以执行完成,在以前,一般有两种方式,A过一段时间去调用B的查询api查询,或者A提供一个callback api,B执行完之后调用api通知A服务,这两种方式都不是很好。现在,使用消息总线,可以很方便解决这个问题,A调用B服务后,只需要监听B处理完成的消息,当B处理完成后,会发送一条消息给MQ,MQ会将此消息转发给A服务。这样A服务既不用循环调用B的查询api,也不用提供callback api。同样B服务也不会做这些操作,A服务还能及时得到异步处理成功的消息。
A调用B的api,B处理完成发送消息给MQ,通过MQ处理消息再传给A
1.3、MQ的分类
1.3.1、ActiveMQ
优点
单机吞吐量万级,时效性毫秒【ms】级,可用性高,基于主从架构实现高可用性,消息可靠性较低的概率丢失数据。【一般不丢失消息】
缺点
官方对ActiveMQ的维护越来越少,高吞吐量场景较少使用。
1.3.2、Kafka
大数据的杀手锏,谈到大数据领域内的消息传输,则绕不开Kafka,这款为大数据而生的消息中间件,以其百万级TPS的吞吐量闻名。在数据采集、传输、存储的过程中发挥很好的作用。
优点
性能卓越,单机写入TPS约在百万条/秒,最大的优点,就是吞吐量高。时效性毫秒级可用性非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用,消费者采用Pull方式获取消息,消息有序,通过控制能够保证所有消息被消费且仅被消费一次;有优秀的第三方kafka Web管理界面;在日志领域比较成熟,功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用。
缺点
kafka单机超过64个队列,Load会发生明显的飙高现象,队列越多,load越高,发送消息响应时间变长,使用短轮询方式,实时性取决于轮询间隔时间,消费失败不支持重试【消息可能丢失】,支持消息顺序,但是一台代理宕机后,就会产生消息乱序,社区更新较慢。
1.3.3、RocketMQ
用java实现,在设计的时候参考了kafka,并做出了自己的一些改进。在订单、交易、充值,流计算,消息推送,日志流式处理,binglog日志分发等场景。
优点
单机吞吐量十万级,可用性非常高,分布式架构,消息可以做到0丢失,MQ功能较为完善,扩展性好,支持10亿级别的消息堆积,不会因为堆积导致性能下降,然后可以参考源码来设计自己的MQ。
缺点
支持的客户端语言不多,社区活跃度一般,没有在MQ核心中去实现JMS等接口,有些系统要迁移需要修改大量代码
1.3.4、RabbitMQ
是一个AMQP(高级消息队列协议)基础上完成的,可复用的企业消息系统,是当前最主流的消息中间件之一。
优点
由于erlang语言的高并发特性,性能较好;吞吐量到万级,MQ功能比较完备,健壮、稳定,易用、跨平台、支持多种语言,如:Python、Java、PHP、C等等,支持AJAX文档齐全,好用,社区活跃度高,更新频率高。
缺点
学习成本高。。。
1.4、MQ的选择
RabbitMQ
结合erlang语言本身的并发优势,性能好时效性微秒级,社区活跃度也比较高,管理界面用起来十分方便,如果数据量没有那么大,可以优先选择它。
2、RabbitMQ
2.1、RabbitMQ概念
RabbitMQ是一个消息中间件:它接收并转发消息。可以把它当做一个快递站点,当要发送一个包裹时,把包裹放到快递站,快递员最终会把你的快递送到收件人那里,按照这种逻辑RabbitMQ是一个快递站。RabbitMQ与快递站的主要区别在于,它不处理快递,而是接收、 存储和转发消息数据。
2.2、四大核心概念
生产者
产生数据发送消息的程序是消费者。
交换机
交换机是RabbitMQ非常重要的一个部件,一方面它接收来自生产者的消息,另一方面它将消息推送到队列中。交换机是RabbitMQ非常重要的一个部件,一方面它接收来自生产者的消息,另一方面它将消息推送到队列中。
队列
队列是RabbitMQ内部使用的一种数据结构,尽管消息流经RabbitMQ和应用程序,但它们只能存储在队列中。队列仅受主机的内存和磁盘限制的约束,本质上是一个大的消息缓冲区。许多生产者可以将消息发送到一个队列,许多消费者可以尝试从一个队列接收数据。
消费者
消费者大多时候是一个等待接收消息的程序。生产者,消费者和消息中间件很多时候并不在同一机器上。同一个应用程序既可以是生产者又可以是消费者。
2.3、RabbitMQ核心部分
简单消息队列
Work queues
Publish/Subscribe【发布订阅模式】
Routing
Topics
Publisher Confirms
2.4、RabbitMQ工作原理
生产者→Connection【信道】→Broker【交换机→队列】→Connection【信道】→消费者
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 的分发依据。
3、Simple Queue【简单消息队列】
消费者【发送消息】→消息队列→生产者【接收消息】
示例图
创建空项目,在其创建模块,引入依赖
<dependencies>
<!-- rabbitmq依赖客户端 -->
<dependency>
<groupId>com.rabbitmq</groupId>
<artifactId>amqp-client</artifactId>
<version>5.7.3</version>
</dependency>
<!-- 操作文件流的一个依赖 -->
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.7</version>
</dependency>
</dependencies>
发送消息代码
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
/**
* 生产者:发送消息
*/
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("192.168.xxx.134");
// 用户名
factory.setUsername("guest");
// 密码
factory.setPassword("guest");
// 创建连接
Connection connection = factory.newConnection();
// 在连接里面创建信道
Channel channel = connection.createChannel();
/**
* 生成一个队列【参数说明】
* 1-队列名称
* 2-队列里面的消息是否持久化(磁盘) 默认情况消息存储在内存中
* 3-该队列是否只供一个消费者进行消费 是否进行消息共享,true表示独享,false表示可以共享
* 4-是否自动删除 最后一个消费者端开连接以后 该队列是否自动删除 true自动删除 false不自动删除
* 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("消息已发送");
}
}
接收消息代码
import com.rabbitmq.client.*;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
/**
* 消费者,接收消息
*/
public class Consumer {
// 队列名称
public static final String QUEUE_NAME = "hello";
// 接收消息
public static void main(String[] args) throws IOException, TimeoutException {
// 创建一个连接工厂
ConnectionFactory factory = new ConnectionFactory();
// 工厂ID 连接RabbitMQ的队列
factory.setHost("192.168.xxx.134");
// 用户名
factory.setUsername("guest");
// 密码
factory.setPassword("guest");
// 创建连接
Connection connection = factory.newConnection();
// 在连接中创建信道
Channel channel = connection.createChannel();
// 声明成功回调
DeliverCallback deliverCallback = (consumerTag, message) -> {
System.out.println(new String(message.getBody()));
};
// 声明失败回调
CancelCallback cancelCallback = consumerTag -> {
System.out.println("消息消费被中断");
};
/**
* 消费者消费消息
* 1-消费哪个队列
* 2-消费成功后是否要自动应答 true表示自动应答 false表示手动应答
* 3-消费者成功消费的回调
* 4-消费者取消消费的回调
*/
channel.basicConsume(QUEUE_NAME, true, deliverCallback, cancelCallback);
}
}
4、Work Queues【工作队列】
工作队列(又称任务队列)的主要思想是避免立即执行资源密集型任务,而不得不等待它完成。相反安排任务在之后执行。把任务封装为消息并将其发送到队列。在后台运行的工作进程将弹出任务并最终执行作业。当有多个工作线程时,这些工作线程将一起处理这些任务。
示例
原本:生产者【发送大量消息】→消息队列→消费者【接收消息】
处理:将消费者改成多个工作线程
现在:生产者【发送大量消息】→消息队列→多个工作线程【接收消息】
示例图
注意事项
1、一个消息只能被处理一次,不可以处理多次
2、各个工作线程之间是竞争关系
4.1、轮询分发消息
启动两个工作线程,一个消息发送线程,另一个消息接收线程。
4.1.1、抽取工具类
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
/**
* 此类为连接工厂创建信道的工具类
*/
public class RabbitMqUtils {
// 得到一个连接的信道【channel】
public static Channel getChannel() throws IOException, TimeoutException {
// 创建一个连接工厂
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("192.168.xxx.134");
factory.setUsername("guest");
factory.setPassword("guest");
// 通过连接工厂创建连接
Connection connection = factory.newConnection();
// 通过连接返回一个channel
return connection.createChannel();
}
}
4.1.2、创建消费者
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.CancelCallback;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.DeliverCallback;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
/**
* 这是一个工作线程(相当于之前的消费者)
*/
public class Worker01 {
// 队列名称
public static final String QUEUE_NAME = "hello";
// 接收消息
public static void main(String[] args) throws IOException, TimeoutException {
// 通过工具类获取信道
Channel channel = RabbitMqUtils.getChannel();
// 接收消息的成功回调
DeliverCallback deliverCallback = (consumerTag, message) -> {
System.out.println("接收到的消息:" + new String(message.getBody()));
};
// 接收消息的失败回调
CancelCallback cancelCallback = consumerTag -> {
System.out.println(consumerTag + "消息者取消消费接口回调逻辑");
};
System.out.println("C2等待接收消息......");
// 消息的接收
channel.basicConsume(QUEUE_NAME, true, deliverCallback, cancelCallback);
}
}
创建一个这样的类启动时,可以像微服务那样在配置中启动同一个微服务,只是微服务端口号是不一样的,而这里同样是将输出语句中的C1改成C2【通过Edit Configuration进行设置】。
这样就创建好了两个类似的消费者线程。
4.1.3、创建生产者
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.Channel;
import java.io.IOException;
import java.util.Scanner;
import java.util.concurrent.TimeoutException;
/**
* 生产者 发送大量的消息
*/
public class Task01 {
// 队列名称
public static final String QUEUE_NAME = "hello";
// 发送大量消息
public static void main(String[] args) throws IOException, TimeoutException {
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);
}
}
}
启动生产者,进行测试即可
4.2、消息应答
4.2.1、概念
消费者完成一个任务可能需要一段时间,如果其中一个消费者处理一个长的任务并仅只完成了部分,突然它挂掉了,会发生什么情况。RabbitMQ一旦向消费者传递了一条消息,便立即将该消息标记位删除。在这种情况下,突然有个消费者挂掉了,我们将丢失正在处理的消息以及后续发送给该消费者的消息,因为它无法接收到。
为了保证消息在发送过程中不丢失,RabbitMQ引入消息应答机制,消息应答就是:消费者在接收到消息并且处理该消息之后,告诉RabbitMQ它已经处理了,RabbitMQ可以把该消息删除了。
4.2.2、自动应答【不推荐使用】
消息发送后立即被认为已经传达成功,这种模式需要在高吞吐量和数据传输安全性方面做权衡,因为这种模式如果消息在接收到之前,消费者那边出现连接或者channel关闭,那么消息就丢失了;当然另一方面这种模式,消费者那边可以传递过载的消息,没有对传递的消息数量进行限制,当然这样有可能使得消费者这边由于接收太多还来不及处理的消息,导致这些消息的积压,最终使得内存耗尽,最终这些消费者线程被操作系统杀死,所以这种模式仅适用在消费者可以高效并以某种速率能够处理这些消息的情况下使用。
4.2.3、消息应答的方法
-
Channel.basicAck(用于肯定确认)
-
RabbitMQ已知道该消息并且成功的处理消息,可以将其丢弃了
-
-
Channel.basicNack(用于否定确认)
-
Channel.basicReject(用于否定确认)
-
与Channel.basicNack相比少一个参数【Multiple参数】
-
不处理该消息了直接拒绝,可以将其丢弃了
-
4.2.4、Multiple的解释
手动应答的好处是可以批量应答并且减少网络拥堵
channel.basicAck(deliveryTag, true);
multiple的true和false代表不同意思【类似于计网的滑动窗口TCP确认机制】
-
true表示批量应答channel上未应答的消息,比如说channel上有传送tag的消息5,6,7,8,当前tag是8,那么此时5-8的这些还未应答的消息都会被确认收到消息应答。
-
false同上面相比,只会应答tag=8的消息,5,6,7这三个消息依然不会被确认收到消息应答。【推荐使用】
4.2.5、消息自动重新入队
如果消费者由于某些原因失去连接(其通道已关闭,连接已关闭或TCP连接丢失),导致消息未发送ACK确认,RabbitMQ将了解到消息未完全处理,并将对其重新排队。如果此时其他消费者可以处理,它将很快将其重新分发给另一个消费者。这样,即使某个消费者偶尔死亡,也可以确保不会丢失任何信息。
示例
首先,消息1交由C1来处理,消息2交由C2来处理;
接着,C1突然失去连接,消息1未完成ack确认;
然后,消息1重新入队,此时C1还是失去连接;
最后,消息1由C2进行处理。
4.2.6、消息手动应答代码
默认消息采用的是自动应答,所以要想实现消息消费过程中不丢失,需要把自动应答改为手动应答,消费者在上面的代码基础上增加下面代码,完整代码如下。
生产者
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.Channel;
import java.io.IOException;
import java.util.Scanner;
import java.util.concurrent.TimeoutException;
/**
* 消息再手动应答时不丢失,放回队列中重新消费
*/
public class task2 {
// 队列名称
public static final String TASK_QUEUE_NAME = "ack_queue";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtils.getChannel();
// 声明队列
channel.queueDeclare(TASK_QUEUE_NAME, false, false, false, null);
// 从控制台输入消息
Scanner scanner = new Scanner(System.in);
// 循环输出
while (scanner.hasNextLine()) {
String message = scanner.next();
channel.basicPublish("", TASK_QUEUE_NAME, null, message.getBytes("UTF-8"));
System.out.println("生产者发出消息:" + message);
}
}
}
消费者1和2
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.hashiqi.rabbitmq.utils.SleepUtils;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.DeliverCallback;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
/**
* 消息再手动应答时不允许丢失,放回队列中重新消费
*/
public class Worker03 {
// 队列名称
public static final String TASK_QUEUE_NAME = "ack_queue";
// 接收消息
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtils.getChannel();
System.out.println("C1等待接收消息处理时间较短...");
DeliverCallback deliverCallback = (consumerTag, message) -> {
// 沉睡1S
SleepUtils.sleep(1);
System.out.println("接收到的消息:" + new String(message.getBody(), "UTF-8"));
// 手动应答
/**
* 参数说明
* 1、消费的标记 tag
* 2、是否批量应答 false表示不批量应答信道中的消息 true表示批量应答
*/
channel.basicAck(message.getEnvelope().getDeliveryTag(), false);
};
// 采用手动应答
boolean autoAck = false;
channel.basicConsume(TASK_QUEUE_NAME, autoAck, deliverCallback, (consumerTag -> {
System.out.println(consumerTag + "消费者取消消费接口回调逻辑");
}));
}
}
复制一份上面的类,将里面的C1改成C2,睡眠时间由1秒改成30秒。
4.2.7、手动应答效果演示
正常情况下,消息发送方发送两个消息,C1和C2分别接收到消息并进行处理。
在发送者发送消息dd,发出消息之后把C2消费者停掉,按理说该C2来处理该消息,但是由于它处理时间较长,在还未处理完,也就是说C2还没有执行ack代码的时候,C2被停掉了,此时会看到消息被C1接收到了,说明消息dd被重新入队,然后分配给能处理消息的C1处理了。
4.3、RabbitMQ持久化
4.3.1、概念
刚刚已经看到了如何处理任务不丢失的情况,但是如何保障当RabbitMQ服务停掉以后消息生产者发送过来的消息不丢失。默认情况下,RabbitMQ退出或由于某种原因奔溃时,它忽视队列和消息,除非告知它不要这样做。确保消息不会丢失需要做两件事:需要将队列和消息都标记为持久化。
4.3.2、队列实现持久化
之前创建的队列都是非持久化的,rabbitMQ如果重启的话,该队列就会被删除掉,如果要队列实现持久化,需要在声明队列的时候把durable参数设置为持久化。
// 让消息队列持久化
boolean durable = true;
channel.queueDeclare(ACK_QUEUE_NAME, durable, flase, false, null);
但是需要注意的就是如果之前声明的队列不是持久化的,需要把原先队列先剔除,或者重新创建一个持久化的队列,否则出现错误。
Caused by: com.rabbitmq.client.ShutdownSignalException: channel error; protocol method: #method<channel.close>(reply-code=406, reply-text=PRECONDITION_FAILED - inequivalent arg 'durable' for queue 'ack_queue' in vhost '/': received 'true' but current is 'false', class-id=50, method-id=10)
当处理后重启rabbitMQ队列也依然存在。
4.3.3、消息实现持久化
要想让消息实现持久化需要在消息生产者修改代码,MessageProperties.PERSISTENT_TEXT_PLAIN添加这个属性。
修改前
channel.basicPublish("", TASK_QUEUE_NAME, null, message.getBytes("UTF-8"));
修改后
//当durable为true的时候
channel.basicPublish("", TASK_QUEUE_NAME, null, MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes("UTF-8"));
将消息标记为持久化并不能完全保证不会丢失消息。尽管它告诉RabbitMQ将消息保存到磁盘,但是这里依然存在当消息刚准备存储在磁盘的时候,但是还没有存储完,消息还在缓存的一个间隔点。此时并没有真正写入磁盘。持久性保证并不强,但是对于简单任务队列而言,这已经是绰绰有余。当然还有更强力的持久化策略,比如发布确认。
队列和消息实现持久化【总】
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.MessageProperties;
import java.io.IOException;
import java.util.Scanner;
import java.util.concurrent.TimeoutException;
/**
* 消息再手动应答时不丢失,放回队列中重新消费
*/
public class task2 {
// 队列名称
public static final String TASK_QUEUE_NAME = "ack_queue";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtils.getChannel();
// 声明队列
// 需要消息队列持久化
boolean durable = true;
channel.queueDeclare(TASK_QUEUE_NAME, durable, false, false, null);
// 从控制台输入消息
Scanner scanner = new Scanner(System.in);
// 循环输出
while (scanner.hasNextLine()) {
String message = scanner.next();
// 设置生产者发送消息为持久化消息,要求保存到磁盘上,否则保存到内存上
channel.basicPublish("", TASK_QUEUE_NAME, MessageProperties.TEXT_PLAIN, message.getBytes("UTF-8"));
System.out.println("生产者发出消息:" + message);
}
}
}
4.3.4、不公平分发
最开始的时候RabbitMQ分发消息采用的是轮询分发,但是在某种场景下这种策略并不是很好,比方说有两个消费者在处理任务,其中有个消费者1处理任务的速度非常快,而另外一个消费者2处理速度却很慢,这个时候还是采用轮询分发的话就会使处理速度很快的这个消费者很大一部分时间处于空闲状态,而处理满的那个消费者一直在干活,这种分配方式在这种情况下不太好,但是RabbitMQ并不知道这种情况它依然很公平的进行分发。
为了面这种情况,可以设置参数channel.basicQos(1);
int prefetchCount = 1;
channel.basicQos(prefetchCount);
意思是如果这个任务我还没有处理完或还没有应答你,你先别分配给我,我目前只能处理一个任务,然后RabbitMQ就会把该任务分配给没有那么忙的那个空闲消费者,当如果所有的消费者都没有完成手上任务,队列还在不停添加新任务 ,队列有可能就会遇到队列被撑满的情况,这个时候只能添加新的worker或者改变其他存储任务的策略。
4.3.5、预取值【类似TCP的接收窗口】
RabbitMQ的预取值机制基于信道(Channel)级别,可以对每个消费者进行个性化的设置。当消费者连接到队列并准备接收消息时,它可以通过以下两种方式设置预取值:
-
预取值为0: 将预取值设置为0意味着消费者不进行预取操作,即每次只获取一条消息。这种情况下,消费者在处理完当前消息之前不会从队列中获取新的消息。
-
预取值大于0: 将预取值设置为大于0的数值,表示消费者可以一次性获取指定数量的消息。例如,设置预取值为10,表示消费者可以一次性获取10条消息进行处理。
当消费者从队列中获取消息时,RabbitMQ会将指定数量的消息推送给消费者,而不需要消费者主动请求。消费者会按照接收到的顺序逐条处理这些消息,直到消息处理完毕或缓存区满。当消费者处理完指定数量的消息之后,才会从队列中获取新的消息。
假设有一个任务队列,任务被放入RabbitMQ的”taskQueue“队列中,多个消费者需要从队列中获取任务进行处理。为了实现负载均衡,可以通过设置预取值来优化任务的分发。
5、发布确认
5.1、发布确认原理
生产者将信道设置成confirm模式,一旦信道进入confirm模式,所有在该信道上面发布的消息都将会被指派一个唯一的ID(从1开始),一旦消息被投递到所有匹配的队列之后,broker就会发送一个确认给生产者(包含消息的唯一ID),这就使得生产者知道消息已经正确到达目的队列了,如果消息和队列是可持久化的,那么确认消息会在将消息写入磁盘之后发出,broker回传给生产者的确认消息中delivery-tag域包含了确认消息的序列号,此外broker也可以设置basci.ack的multiple域,表示到这个序列号之前的所有消息都已经得到了处理。
confirm模式最大的好处在于它是异步的,一旦发布一条消息,生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息,当消息最终得到确认之后,生产者应用便可以通过回调方法来处理该确认消息,如果RabbitMQ因为自身内部错误导致消息丢失,就会发送一条nack消息,生产者应用程序同样可以在回调方法中处理该nack消息。
5.2、发布确认的策略时
5.2.1、开启发布确认的方法
发布确认默认是没有开启的,如果要开启需要调用方法confirmSelect,每当你想使用发布确认,都需要在channel上调用该方法。
Channel channel = connection.createChannel();
channel.confirmSelect();
5.2.2、单个确认发布
这是一种简单的确认方式,它是一种同步确认发布的方式,也就是发布一个消息之后只有它被确认发布,后续的消息才能继续发布,waitForConfirmsOrDie(long)这个方法只有在消息被确认的时候才返回,如果在指定时间范围内这个消息没有被确认那么它将抛出异常。
这种确认方式有一个最大的缺点就是:发布速度特别的慢,因为如果没有确认发布的消息就会阻塞所有后续消息的发布,这种方式最多提供每秒不超过数百条发布消息的吞吐量。当然,对于某些应用程序来说这可能已经足够了。
// 单个确认 【发布1000个单独确认消息,耗时:645ms】
public static void publishMessageIndividually() throws IOException, TimeoutException, InterruptedException {
Channel channel = RabbitMqUtils.getChannel();
// 队列的声明
String queueName = UUID.randomUUID().toString();
channel.queueDeclare(queueName, true, false, false, null);
// 开启发布确认
channel.confirmSelect();
// 开始时间
long begin = System.currentTimeMillis();
// 批量发消息
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 end = System.currentTimeMillis();
System.out.println("发布" + MESSAGE_COUNT + "个单独发布确认消息,耗时:" + (end - begin) + "ms");
}
5.2.3、批量确认发布
单个确认方式非常慢,与单个等待确认消息相比,先发布一批消息然后一起确认可以极大地提高吞吐量,当然这种方式的缺点就是:当发生故障导致发布出现问题时,不知道是哪个消息出现问题,必须将整个批处理保存在内存中,以记录重要的信息而后重新发布消息。当然这种方案仍然是同步的,也一样阻塞消息的发布。
// 批量确认 【发布1000个批量确认消息,耗时:114ms】
public static void publishMessageBatch() throws IOException, TimeoutException, InterruptedException {
Channel channel = RabbitMqUtils.getChannel();
// 声明队列
String queueName = UUID.randomUUID().toString();
channel.queueDeclare(queueName, true, false, false, null);
// 开启发布确认
channel.confirmSelect();
// 开始时间
long begin = System.currentTimeMillis();
// 批量确认消息的大小
int batchSize = 100;
// 未确认消息个数
// 批量发送消息及批量发布确认
for (int i = 1; i <= MESSAGE_COUNT; i++) {
String message = i + "";
channel.basicPublish("", queueName, null, message.getBytes());
// 判断达到100条消息的时候 批量确认一次
if (i % batchSize == 0) {
// 发布确认
channel.waitForConfirms();
}
}
// 结束时间
long end = System.currentTimeMillis();
System.out.println("发布" + MESSAGE_COUNT + "个批量发布确认消息,耗时:" + (end - begin) + "ms");
}
5.2.4、异步确认方式
异步确认虽然编程逻辑比上两个要复杂,但是性价比最高,无论是可靠性还是效率都很好,它是利用回调函数来达到消息可靠性传递的,这个中间件也是通过函数回调来保证是否投递成功。
// 异步发布确认 【发布1000个异步确认消息,耗时:36ms】
public static void publishMessageAsync() throws IOException, TimeoutException {
Channel channel = RabbitMqUtils.getChannel();
String queueName = UUID.randomUUID().toString();
// 队列声明
channel.queueDeclare(queueName, true, false, false, null);
// 开启发布确认
channel.confirmSelect();
// 开始时间
long begin = System.currentTimeMillis();
// 消息确认成功 回调函数
ConfirmCallback ackCallback = (deliveryTag, multiple) -> {
System.out.println("确认的消息:" + deliveryTag);
};
// 消息确认失败 回调函数
/**
* 参数解释
* 1-消息的标记
* 2-是否为批量确认
*/
ConfirmCallback nackCallback = (deliveryTag, multiple) -> {
System.out.println("未确认的消息:" + deliveryTag);
};
// 发消息前,准备消息的监听器,监听哪些消息成功了,哪些消息失败了,异步通知
/**
* 参数解释
* 1-监听哪些消息成功了
* 2-监听哪些消息失败了
*/
channel.addConfirmListener(ackCallback, nackCallback);
// 批量发送消息
for (int i = 0; i < MESSAGE_COUNT; i++) {
String message = "消息" + i;
channel.basicPublish("", queueName, null, message.getBytes());
}
// 结束时间
long end = System.currentTimeMillis();
System.out.println("发布" + MESSAGE_COUNT + "个异步确认消息,耗时:" + (end - begin) + "ms");
}
但是还未对未确认消息进行处理。
5.2.5、如何处理异步未确认消息
最好解决方案就是把未确认的消息放到一个基于内存的能被分发布线程访问的队列,比如说用ConcurrentLinkedQueue这个队列在confirm callbacks与发布线程之间进行消息的传递。
// 异步发布确认
public static void publishMessageAsync() throws IOException, TimeoutException {
Channel channel = RabbitMqUtils.getChannel();
String queueName = UUID.randomUUID().toString();
// 队列声明
channel.queueDeclare(queueName, true, false, false, null);
// 开启发布确认
channel.confirmSelect();
/**
* 线程安全有序的哈希表 适用于高并发情况下
* 1-轻松的将序号与消息进行关联
* 2-轻松的批量删除条目,只要给到序号
* 3-支持高并发(多线程)
*/
ConcurrentSkipListMap<Long, String> outstandingConfirms = new ConcurrentSkipListMap<>();
// 消息确认成功 回调函数
ConfirmCallback ackCallback = (deliveryTag, multiple) -> {
// 是否是批量,这里是单个异步确认,批量确认可能导致消息丢失
if (multiple) {
// 解决未确认消息的第二步:删除已确认的消息,剩下的就是未确认的消息
ConcurrentNavigableMap<Long, String> confirmed = outstandingConfirms.headMap(deliveryTag);
// 清除批量
confirmed.clear();
} else {
outstandingConfirms.remove(deliveryTag);
}
System.out.println("确认的消息:" + deliveryTag);
};
// 消息确认失败 回调函数
/**
* 参数解释
* 1-消息的标记
* 2-是否为批量确认
*/
ConfirmCallback nackCallback = (deliveryTag, multiple) -> {
// 解决未确认消息的第三步:打印未确认消息有哪些
String message = outstandingConfirms.get(deliveryTag);
System.out.println("未确认的消息是:" + message + ":::未确认消息的标记是" + deliveryTag);
};
// 发消息前,准备消息的监听器,监听哪些消息成功了,哪些消息失败了,异步通知
/**
* 参数解释
* 1-监听哪些消息成功了
* 2-监听哪些消息失败了
*/
channel.addConfirmListener(ackCallback, nackCallback);
// 开始时间
long begin = System.currentTimeMillis();
// 批量发送消息
for (int i = 0; i < MESSAGE_COUNT; i++) {
String message = "消息" + i;
channel.basicPublish("", queueName, null, message.getBytes());
// 解决未确认消息的第一步:此处记录下所有要发送的消息,即消息的总和
outstandingConfirms.put(channel.getNextPublishSeqNo(), message);
}
// 结束时间
long end = System.currentTimeMillis();
System.out.println("发布" + MESSAGE_COUNT + "个异步确认消息,耗时:" + (end - begin) + "ms");
}
5.2.6、三种发布确认速度对比
单独发布消息
同步等待确认,简单,但吞吐量非常有限。
批量发布消息
批量同步等待确认,简单,合理的吞吐量,一旦出现问题,很难推断出是哪条消息出现了问题。
异步处理消息
最佳性能和资源使用,在出现错误的情况下可以很好地控制,但是实现起来稍微难些。
6、Exchange【交换机】
在前面,创建了一个工作队列,假设的是工作队列背后,每个任务都恰好交付给一个消费者(工作进程)。在这一部分中,将做一些完全不同的事情,将消息传达给多个消费者。这种模式称为“发布/订阅”。
为了说明这种模式,将构建一个简单的日志系统。它将由两个程序组成:第一个程序将发出日志消息,第二个程序是消费者。这时候启动两个消费者,其中一个消费者接收到消息后把日志存储在磁盘,另外一个消费者接收到消息后把消息打印在屏幕上,事实上第一个程序发出的日志消息将广播给所有消费者。
示例
生产者→交换机【RoutingKey{条件},绑定binding】→多个队列【消息只能被消费一次】→消费者
6.1、交换机的概念
RabbitMQ消息传递模型的核心思想是:生产者生产的消息从不会直接发送到队列。实际上,通常生产者甚至都不知道这些消息传递到了哪个队列中。
相反,生产者只能将消息发送到交换机,交换机工作的内容非常简单,一方面它接收来自生产者的消息,另一方面将它们推入队列。交换机必须确切知道如何处理收到的消息,是应该把这些消息放到特定队列还是说把它们放到多个队列中还是应该丢弃它们,这就是由交换机的类型来决定。
6.2、交换机的类型
直接(direct)、主题(topic)、标题(headers)、扇出(fanout)
6.2.1、无名交换机
之前使用的都是默认交换机,通过空字符串进行标识。
6.2.2、临时队列
每当连接到Rabbit时,都需要一个全新的空队列,为此可以创建一个具有随机名称的队列,或者能让服务器提供一个随机队列名称就更好了,其次,一旦断开了消费者的链接,队列将自动被删除。
创建临时队列的方式
String queueName = channel.queueDeclare().getQueue();
通过此方法创建出来的队列名称是无规则的。
6.2.3、binding【绑定】
binding是交换机和队列之间的桥梁,它告诉交换机要和哪个队列进行绑定关系,如下所示
生产者→同一个交换机→binding队列Q1
生产者→同一个交换机→binding队列Q2
6.3、Fanout【扇出】
6.3.1、Fanout介绍
Fanout这种类型非常简单,它是将接收到的所有消息广播到它知道的所有队列中。系统有一些默认的交换机类型。
6.3.2、Fanout实例
两个消费者代码
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.DeliverCallback;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
/**
* 消息的接收
*/
public class ReceiveLogs01 {
// 交换机名称
public static final String EXCHANGE_NAME = "logs";
public static void main(String[] args) throws IOException, TimeoutException {
// 通过工具类创建信道
Channel channel = RabbitMqUtils.getChannel();
// 声明一个交换机
channel.exchangeDeclare(EXCHANGE_NAME, "fanout");
/**
* 生成一个临时队列,队列名称是随机的,当消费者与队列断开连接的时候,队列就自动删除
*/
String queueName = channel.queueDeclare().getQueue();
/**
* 绑定交换机与队列
*/
channel.queueBind(queueName, EXCHANGE_NAME, "");
System.out.println("等待接收消息,把接收到的消息打印在屏幕...");
// 接收消息
DeliverCallback deliverCallback = (consumerTag, message) -> {
System.out.println("ReceiveLogs01控制台打印接收到的消息是:" + new String(message.getBody(), "UTF-8"));
};
// 取消消息
channel.basicConsume(queueName, true, deliverCallback, (consumerTag) -> {
});
}
}
生产者代码
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.Channel;
import java.io.IOException;
import java.util.Scanner;
import java.util.concurrent.TimeoutException;
/**
* 发消息 给交换机
*/
public class EmitLog {
// 交换机名称
public static final String EXCHANGE_NAME = "logs";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtils.getChannel();
channel.exchangeDeclare(EXCHANGE_NAME, "fanout");
Scanner scanner = new Scanner(System.in);
while (scanner.hasNext()) {
String message = scanner.next();
channel.basicPublish(EXCHANGE_NAME, "", null, message.getBytes("UTF-8"));
System.out.println("生产者发出消息:" + message);
}
}
}
最后测试,一个发送,多个接收。
6.4、Direct Exchange【直接交换机】
6.4.1、介绍
Fanout中,日志系统将所有消息广播给所有消费者,对此想做一些改变,比如希望将日志消息写入磁盘的程序仅接收严重错误(erros),而不存储哪些警告(warning)或信息(info)日志消息避免消费磁盘空间。Fanout这种交换类型并不能带来很大灵活性,它只能进行无意识的广播,这里使用direct类型来进行替换,这种类型的工作方式是,消息只去到它绑定的routingKey队列中。
示例
交换机绑定了两个队列,绑定类型是direct。队列Q1绑定键为orange,队列Q2绑定建为black和green。
在这种绑定情况下,生产者发布消息到交换机上,绑定建为orange的消息会被发布到队列Q1。绑定键为black、green的消息会被发布到队列Q2,其它消息类型的消息将被丢弃。
6.4.2、多重绑定
如果交换机的绑定类型是direct,但是它绑定的多个队列的key如果都相同,在这种情况下虽然绑定类型是direct,但是它表现的就和fanout有点类似了。就跟广播差不多。
6.4.3、direct实例
枚举类
public enum BuiltInExchangeType {
DIRECT("direct"),
FANOUT("fanout"),
TOPIC("topic"),
HEADERS("headers");
private final String type;
BuiltInExchangeType(String type) {
this.type = type;
}
public String getType() {
return type;
}
}
消费者
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.BuiltinExchangeType;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.DeliverCallback;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
public class ReceiveLogsDirect01 {
// 交换机名称
public static final String EXCHANGE_NAME = "direct_logs";
// 队列名称
public static final String QUEUE_NAME = "console";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtils.getChannel();
// 声明一个交换机
channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.DIRECT);
// 声明一个队列
channel.queueDeclare(QUEUE_NAME, true, false, false, null);
// 将队列和交换机进行一个绑定,并确定routingKey的值
channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, "info");
// 接收消息
DeliverCallback deliverCallback = (consumerTag, message) -> {
System.out.println("ReceiveLogsDirect01接收到的消息是:" + new String(message.getBody(), "UTF-8"));
};
// 消费者取消消息时回调接口
channel.basicConsume(QUEUE_NAME, true, deliverCallback, (consumerTag) -> {});
}
}
生产者
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.Channel;
import java.io.IOException;
import java.util.Scanner;
import java.util.concurrent.TimeoutException;
/**
* 发送消息
*/
public class DirectLog {
// 交换机名称
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, "error", null, message.getBytes("UTF-8"));
System.out.println("生产者发出消息:" + message);
}
}
}
6.5、Topics
6.5.1、前两个类型的问题
在direct类型中,改进了日志记录系统,没有使用只能进行随意广播的fanout交换机,而是使用了direct交换机,从而才实现有选择性地接收日志。
尽管使用direct交换机改进了系统,但是它仍然存在局限性,比如说想要接收的日志类型有info.base和info.advantage,某个队列只想info.base的消息,那这个时候direct就办不到了,这个时候只能使用topic类型。
6.5.2、Topic的要求
发送到类型为topic交换机的消息的routing_key不能随意写,必须满足一定的要求,它必须是一个单词列表,以点号分隔开。这些单词可以是任意单词,比如说:”stock.usd.nyse“,“nyse.vmw”,在这个规则列表中,其中有两个替换符需要注意:
*【星号】可以代替一个单词
#【井号】可以替代零个或者多个单词
6.5.3、Topic匹配案例
Q1绑定的是 中间带有orange的三个单词的字符串(*.orange.*)
Q2绑定的是 最后一个单词是rabbit的3个单词(*.*.rabbit)
第一个单词是lazy的多个单词(lazy.#)
当一个队列绑定键是#,那么这个队列将接收所有数据,类似于fanout;
如果一个队列绑定键当中#和*出现,那么该队列绑定类型就是direct。
6.5.4、topic实例
消费者A
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.DeliverCallback;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
/**
* 消息接收者C1
*/
public class ReceiverLogsTopic01 {
// 交换机名称
public static final String EXCHANGE_NAME = "topic_logs";
// 队列名称
public static final String QUEUE_NAME = "Q1";
public static void main(String[] args) throws IOException, TimeoutException {
// 创建信道
Channel channel = RabbitMqUtils.getChannel();
// 声明交换机
channel.exchangeDeclare(EXCHANGE_NAME, "topic");
// 声明队列
channel.queueDeclare(QUEUE_NAME, false, false, false, null);
// 将交换机和队列进行绑定,并指明相应的topic类型
channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, "*.orange.*");
// 接收消息
DeliverCallback deliverCallback = (consumerTag, message) -> {
System.out.println("Q1接收到的消息是:" + new String(message.getBody(), "UTF-8"));
System.out.println("接收队列:" + QUEUE_NAME + "绑定键:" + message.getEnvelope().getRoutingKey());
};
System.out.println("Q1等待接收消息....");
channel.basicConsume(QUEUE_NAME, true, deliverCallback, (consumerTag) -> {});
}
}
消费者B
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.DeliverCallback;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
/**
* 消息接收者C1
*/
public class ReceiverLogsTopic02 {
// 交换机名称
public static final String EXCHANGE_NAME = "topic_logs";
// 队列名称
public static final String QUEUE_NAME = "Q2";
public static void main(String[] args) throws IOException, TimeoutException {
// 创建信道
Channel channel = RabbitMqUtils.getChannel();
// 声明交换机
channel.exchangeDeclare(EXCHANGE_NAME, "topic");
// 声明队列
channel.queueDeclare(QUEUE_NAME, false, false, false, null);
// 将交换机和队列进行绑定,并指明相应的topic类型
channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, "*.*.rabbit");
channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, "lazy.#");
// 接收消息
DeliverCallback deliverCallback = (consumerTag, message) -> {
System.out.println("Q2接收到的消息是:" + new String(message.getBody(), "UTF-8"));
System.out.println("接收队列:" + QUEUE_NAME + "绑定键:" + message.getEnvelope().getRoutingKey());
};
System.out.println("Q2等待接收消息....");
channel.basicConsume(QUEUE_NAME, true, deliverCallback, (consumerTag) -> {});
}
}
生产者
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.Channel;
import java.io.IOException;
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.TimeoutException;
/**
* 发送消息
*/
public class EmitLogTopic {
// 交换机的名称
public static final String EXCHANGE_NAME = "topic_logs";
public static void main(String[] args) throws IOException, TimeoutException {
// 创建信道
Channel channel = RabbitMqUtils.getChannel();
Map<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);
}
}
}
最后进行测试。
7、死信队列
7.1、死信的概念
死信,即无法被消费的消息,一般来说,生产者将消息投递到broker或者直接到queue里,消费者从queue取出消息进行消费,但某些时候由于特定的原因导致queue中的某些消息无法被消费,这样的消息如果没有后续处理,就变成了死信,有了死信即有了死信队列。
应用场景
(1)为了保证订单业务的消息数据不丢失,需要使用到RabbitMQ的死信队列机制,当消息消费发生异常时,将消息投入死信队列中。
(2)用户在商城下单成功并点击去支付后在指定时间未支付时自动失效。
7.2、死信的来源
-
消息TTL过期
-
队列达到最大长度(队列满了,无法再添加数据到mq中)
-
消息被拒绝(basic.reject或basic.nack)并且requeue=false
7.3、死信实例
7.3.1、代码架构图
7.3.2、消息TTL过期
生产者代码
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.AMQP;
import com.rabbitmq.client.Channel;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
/**
* 死信队列 实战 生产者
*/
public class Producer {
// 普通交换机的名称
public static final String NORMAL_EXCHANGE_NAME = "normal_exchange";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtils.getChannel();
// 死信消息 设置TTL时间 单位是ms
AMQP.BasicProperties properties = new AMQP.BasicProperties().builder().expiration("10000").build();
for (int i = 1; i < 11; i++) {
String message = "info" + i;
channel.basicPublish(NORMAL_EXCHANGE_NAME, "zhangsan", properties, message.getBytes());
}
}
}
消费者A代码
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.BuiltinExchangeType;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.DeliverCallback;
import java.io.IOException;
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.TimeoutException;
/**
* 死信队列 实战 消费者A
*/
public class Consumer01 {
// 普通交换机的名称
public static final String NORMAL_EXCHANGE_NAME = "normal_exchange";
// 死信交换机的名称
public static final String DEAD_EXCHANGE_NAME = "dead_exchange";
// 普通队列的名称
public static final String NORMAL_QUEUE_NAME = "normal_queue";
// 死信队列的名称
public static final String DEAD_QUEUE_NAME = "dead_queue";
public static void main(String[] args) throws IOException, TimeoutException {
// 获取信道
Channel channel = RabbitMqUtils.getChannel();
// 声明死信和普通交换机的类型为direct
channel.exchangeDeclare(NORMAL_EXCHANGE_NAME, BuiltinExchangeType.DIRECT);
channel.exchangeDeclare(DEAD_EXCHANGE_NAME, BuiltinExchangeType.DIRECT);
// 声明普通队列
Map<String, Object> arguments = new HashMap<>();
// 过期时间 单位毫秒【可以由生产者指定】
// arguments.put("x-message-ttl", 10000);
// 正常队列设置死信交换机
arguments.put("x-dead-letter-exchange", DEAD_EXCHANGE_NAME);
// 设置死信的RoutingKey
arguments.put("x-dead-letter-routing-key", "lisi");
channel.queueDeclare(NORMAL_QUEUE_NAME, false, false, false, arguments);
// 声明死信队列
channel.queueDeclare(DEAD_QUEUE_NAME, false, false, false, null);
// 将普通队列与普通交换机进行绑定并设置routingKey
channel.queueBind(NORMAL_QUEUE_NAME, NORMAL_EXCHANGE_NAME, "zhangsan");
// 将死信队列与死信交换机进行绑定并设置routingKey
channel.queueBind(DEAD_QUEUE_NAME, DEAD_EXCHANGE_NAME, "lisi");
System.out.println("consumerA等待接收消息...");
DeliverCallback deliverCallback = (consumerTag, message) -> {
System.out.println("consumerA接收的消息是:" + new String(message.getBody(), "UTF-8"));
};
// 接收消息
channel.basicConsume(NORMAL_QUEUE_NAME, true, deliverCallback, (consumerTag) -> {});
}
}
消费者B代码【负责处理死信队列】
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.DeliverCallback;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
/**
* 死信队列 实战 消费者B
*/
public class Consumer02 {
// 死信队列的名称
public static final String DEAD_QUEUE_NAME = "dead_queue";
public static void main(String[] args) throws IOException, TimeoutException {
// 获取信道
Channel channel = RabbitMqUtils.getChannel();
System.out.println("consumerB等待接收消息...");
DeliverCallback deliverCallback = (consumerTag, message) -> {
System.out.println("consumerB接收的消息是:" + new String(message.getBody(), "UTF-8"));
};
// 接收消息
channel.basicConsume(DEAD_QUEUE_NAME, true, deliverCallback, (consumerTag) -> {});
}
}
7.3.3、队列达到最大长度
生产者代码【去掉TTL属性】
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.Channel;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
/**
* 死信队列 实战 生产者
*/
public class Producer {
// 普通交换机的名称
public static final String NORMAL_EXCHANGE_NAME = "normal_exchange";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtils.getChannel();
for (int i = 1; i < 11; i++) {
String message = "info" + i;
channel.basicPublish(NORMAL_EXCHANGE_NAME, "zhangsan", null, message.getBytes());
}
}
}
消费者A修改以下代码【启动之后关闭该消费者 模拟其接收不到消息】
// 设置正常队列长度的限制
arguments.put("x-max-length", 6);
需要删除原先的队列,否则报错。
消费者B代码不懂【启动测试】
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.DeliverCallback;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
/**
* 死信队列 实战 消费者B
*/
public class Consumer02 {
// 死信队列的名称
public static final String DEAD_QUEUE_NAME = "dead_queue";
public static void main(String[] args) throws IOException, TimeoutException {
// 获取信道
Channel channel = RabbitMqUtils.getChannel();
System.out.println("consumerB等待接收消息...");
DeliverCallback deliverCallback = (consumerTag, message) -> {
System.out.println("consumerB接收的消息是:" + new String(message.getBody(), "UTF-8"));
};
// 接收消息
channel.basicConsume(DEAD_QUEUE_NAME, true, deliverCallback, (consumerTag) -> {});
}
}
7.3.4、消息被拒
生产者代码
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.Channel;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
/**
* 死信队列 实战 生产者
*/
public class Producer {
// 普通交换机的名称
public static final String NORMAL_EXCHANGE_NAME = "normal_exchange";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtils.getChannel();
for (int i = 1; i < 11; i++) {
String message = "info" + i;
channel.basicPublish(NORMAL_EXCHANGE_NAME, "zhangsan", null, message.getBytes());
}
}
}
消费者A【注释掉队列达到最大长度代码,将消费回调进行修改】
DeliverCallback deliverCallback = (consumerTag, message) -> {
String msg = new String(message.getBody(), "UTF-8");
if (msg.equals("info5")) {
System.out.println("此消息:" + msg + "被消费者A拒绝的");
// 是否将拒绝的消息放回普通队列,即成为死信
channel.basicReject(message.getEnvelope().getDeliveryTag(), false);
} else{
System.out.println("consumerA接收的消息是:" + new String(message.getBody(), "UTF-8"));
channel.basicAck(message.getEnvelope().getDeliveryTag(), false);
}
};
// 开启手动应答
channel.basicConsume(NORMAL_QUEUE_NAME, false, deliverCallback, (consumerTag) -> {});
消费者B
import com.hashiqi.rabbitmq.utils.RabbitMqUtils;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.DeliverCallback;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
/**
* 死信队列 实战 消费者B
*/
public class Consumer02 {
// 死信队列的名称
public static final String DEAD_QUEUE_NAME = "dead_queue";
public static void main(String[] args) throws IOException, TimeoutException {
// 获取信道
Channel channel = RabbitMqUtils.getChannel();
System.out.println("consumerB等待接收消息...");
DeliverCallback deliverCallback = (consumerTag, message) -> {
System.out.println("consumerB接收的消息是:" + new String(message.getBody(), "UTF-8"));
};
// 接收消息
channel.basicConsume(DEAD_QUEUE_NAME, true, deliverCallback, (consumerTag) -> {});
}
}
8、延迟队列【死信队列的其中一种】
8.1、延迟队列概念
延迟队列,队列内部是有序的,最重要的特性在于它的延迟属性,延迟队列中的元素是希望在指定时间到了以后或之前取出和处理,简单来说,延迟队列就是用来存放需要在指定时间被处理元素的队列。
8.2、延迟队列使用场景
-
订单在十分钟之内未支付则自动取消。
-
新创建的店铺,如果在十天内都没有上传过商品,则自动发送消息题型。
-
用户注册成功后,如果三天内没有登录则进行短信提醒。
-
用户发起退款,如果三天内没有得到处理则通知相关运营人员。
-
预定会议后,需要在预定的时间点的前十分钟通知各个与会议相关人员参加会议。
这些场景都有一个特点,需要在某个事件发生之后或者之前的指定时间点完成某一项任务。比如:发生订单生成事件,在十分钟之后检查该订单支付状态,然后将未支付的订单进行关闭;
看起来似乎使用定时任务,一直轮询数据,每秒查一次,取出需要被处理的数据,然后处理不就完了吗?
如果数据量较少,确实可以这样做,比如:对于“如果账单一周内未支付则进行自动结算”这样的需求,如果对于时间不是严格限制,而是宽松意义上的一周,那么每天晚上跑个定时任务检查一下所有未支付的账单,确实是一个可行的方案。
但是对于数据量较大,并且时效性较强的场景,比如:“订单十分钟内未支付则关闭”,短期内未支付的订单数据可能会很多,活动期间甚至会达到百万甚至千万级别,对这么庞大的数据量仍旧使用轮询的方式显然是不可取的,很可能在一秒内无法完成所有订单的检查,同时会给数据库带来很大压力,无法满足业务要求而且性能低下。
图例
8.3、RabbitMQ中的TTL
TTL是RabbitMQ中一个消息或者队列的属性,表明一条消息或者该队列中的所有消息的最大存活时间,