RabbitMQ实战笔记
1 MQ引言
1.1 中间件技术及架构的概述
1.2 什么是MQ
MQ
(Message Quene) : 翻译为消息队列
,通过典型的生产者
和消费者
模型,生产者不断向消息队列中生产消息,消费者不断的从队列中获取消息。因为消息的生产和消费都是异步的,而且只关心消息的发送和接收,没有业务逻辑的侵入,轻松的实现系统间解耦。别名为消息中间件
通过利用高效可靠的消息传递机制进行平台无关的数据交流,并基于数据通信来进行分布式系统的集成。
MQ(message queue),从字面意思上看,本质是个
队列
,FIFO先入先出
,只不过队列中存放的内容是message
而已,还是一种跨进程的通信机制,用于上下游传递消息。在互联网架构中,MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了MQ之后,消息发送上游只需要依赖MQ,不用依赖其他服务。
1.3 为什么要用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服务还能及时的得到异步处理成功的消息。
1.4 MQ的分类
当今市面上有很多主流的消息中间件,如老牌的
ActiveMQ
、RabbitMQ
,炙手可热的Kafka
,阿里巴巴自主开发RocketMQ
等。
- ActiveMQ
- ActiveMQ 是Apache出品,最流行的,能力强劲的开源消息总线。它是一个完全支持JMS规范的的消息中间件。丰富的API,多种集群架构模式让ActiveMQ在业界成为老牌的消息中间件,在中小型企业颇受欢迎!
- 优点:单机吞吐量万级,时效性ms级,可用性高,基于主从架构实现高可用性,消息可靠性较低的概率丢失数据
- 缺点:维护越来越少,高吞吐量场景较少使用
- Kafka
- Kafka是LinkedIn开源的分布式发布-订阅消息系统,目前归属于Apache顶级项目。
- Kafka主要特点是基于Pull的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输。0.8版本开始支持复制,不支持事务,对消息的重复、丢失、错误没有严格要求,
- 适合产生大量数据的互联网服务的数据收集业务。
- 大数据的杀手锏,谈到大数据领域内的消息传输,则绕不开Kafka,这款为大数据而生的消息中间件,以其百万级TPS的吞吐量名声大噪,迅速成为大数据领域的宠儿,在数据采集、传输存储的过程中发挥着举足轻重的作用。目前已经被LinkedIn,Uber,Twitter,Netflix等大公司所采纳。
- 优点:性能卓越,单机写入TPS约在百万条/秒,最大的优点,就是吞吐量高。时效性ms级可用性非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用,消费者采用Pull方式获取消息,消息有序,通过控制能够保证所有消息被消费且仅被消费一次;有优秀的第三方Kafka Web管理界面Kafka-Manager;在日志领域比较成熟,被多家公司和多个开源项目使用;功能支持:功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用。
- 缺点:Kafka单机超过64个队列/分区,Load会发生明显的飙高现象,队列越多,load越高,发送消息响应时间变长,使用短轮询方式,实时性取决于轮询间隔时间,消费失败不支持重试;支持消息顺序,但是一台代理宕机后,就会产生消息乱序,社区更新较慢;
- RocketMQ
- RocketMQ是阿里开源的消息中间件,它是纯Java开发,具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka,但并不是Kafka的一个Copy,它对消息的可靠传输及事务性做了优化,目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。
- 出自阿里巴巴的开源产品,用Java语言实现,在设计时参考了Kafka,并做出了自己的一些改进。被阿里巴巴广泛应用在订单,交易,充值,流计算,消息推送,日志流式处理binglog分发等场景。
- 优点:单机吞吐量十万级,可用性非常高,分布式架构,消息可以做到0丢失,MQ功能较为完善,还是分布式的,扩展性好,支持10亿级别的消息堆积,不会因为堆积导致性能下降,源码是java我们可以自己阅读源码,定制自己公司的MQ
- 缺点:支持的客户端语言不多,目前是java及c++,其中c++不成熟;社区活跃度一般,没有在MQ核心中去实现JMS等接口,有些系统要迁移需要修改大量代码
- RabbitMQ
- RabbitMQ是使用Erlang语言开发的开源消息队列系统,基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由(包括点对点和发布/订阅)、可靠性、安全。AMQP协议更多用在企业系统内对数据一致性、稳定性和可靠性要求很高的场景,对性能和吞吐量的要求还在其次。
- 2007年发布,是一个在AMQP(高级消息队列协议)基础上完成的,可复用的企业消息系统,是当前最主流的消息中间件之一。
- 优点:由于erlang语言的高并发特性,性能较好;吞吐量到万级,MQ功能比较完备,健壮、稳定、易用、跨平台、支持多种语言如: Python、Ruby、.NET、 Java、JMS、C、PHP、ActionScript、XMPP、STOMP等,支持AJAX文档齐全;开源提供的管理界面非常棒,用起来很好用,社区活跃度高; 更新频率相当高
- 缺点:商业版需要收费,学习成本较高。
RabbitMQ比Kafka可靠,Kafka更适合IO高吞吐的处理,一般应用在大数据日志处理或对实时性(少量延迟),可靠性(少量丢数据)要求稍低的场景使用,比如ELK日志收集。
1.5 MQ的选择
MQ | 介绍 |
---|---|
Kafka | Kafka主要特点是基于Pull的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输,适合产生大量数据的互联网服务的数据收集业务。大型公司建议可以选用,如果有日志采集功能,肯定是首选kafka了。 |
RocketMQ | 天生为金融互联网领域而生,对于可靠性要求很高的场景,尤其是电商里面的订单扣款,以及业务削峰,在大量交易涌入时,后端可能无法及时处理的情况。RoketMQ在稳定性上可能更值得信赖,这些业务场景在阿里双11已经经历了多次考验,如果你的业务有上述并发场景,建议可以选择RocketMQ。 |
RabbitMQ | 结合erlang语言本身的并发优势,性能好时效性微秒级,社区活跃度也比较高,管理界面用起来十分方便,如果你的数据量没有那么大,中小型公司优先选择功能比较完备的RabbitMO |
2 RabbitMQ 的引言
2.1 RabbitMQ
官网
: 官方教程
:
- 基于
AMQP
协议,erlang语言开发,是部署最广泛的开源消息中间件,是最受欢迎的开源消息中间件之一。- RabbitMQ 是一个消息中间件:它接受并转发消息。
- 你可以把它当做一个快递站点,当你要发送一个包裹时,你把你的包裹放到快递站,快递员最终会把你的快递送到收件人那里,按照这种逻辑 RabbitMQ 是 一个快递站,一个快递员帮你传递快件。
- RabbitMQ 与快递站的主要区别在于,它不处理快件而是接收, 存储和转发消息数据。
- AMQP 协议
AMQP
(advanced message queuing protocol)`在2003年时被提出,最早用于解决金融领不同平台之间的消息传递交互问题。顾名思义,AMQP是一种协议,更准确的说是一种binary wire-level protocol(链接协议)。这是其和JMS的本质差别,AMQP不从API层进行限定,而是直接定义网络交换的数据格式。这使得实现了AMQP的provider天然性就是跨平台的。以下是AMQP协议模型:
2.2 四大核心概念
概念 | 介绍 |
---|---|
生产者 | 产生数据发送消息的程序是生产者 |
交换机 | 交换机是RabbitMQ非常重要的一个部件,一方面它接收来自生产者的消息,另一方面它将消息推送到队列中。交换机必须确切知道如何处理它接收到的消息,是将这些消息推送到特定队列还是推送到多个队列,亦或者是把消息丢弃,这个得有交换机类型决定 |
队列 | 队列是RabbitMQ内部使用的一种数据结构,尽管消息流经RabbitMQ和应用程序但它们只能存储在队列中。队列仅受主机的内存和磁盘限制的约束,本质上是一个大的消息缓冲区。许多生产者可以将消息发送到一个队列,许多消费者可以尝试从一个队列接收数据。这就是我们使用队列的方式 |
消费者 | 消费与接收具有相似的含义。消费者大多时候是一个等待接收消息的程序。请注意生产者,消费者和消息中间件很多时候并不在同一机器上。同一个应用程序既可以是生产者又是可以是消费者。 |
2.3 名词解释
部分 | 功能 |
---|---|
Borker | 接受和分发消息的应用,RabbitMQ Server就是Message Broker |
Virtual host | 出于多租户和安全因素设计的,把AMQP 的基本组件划分到一个虚拟的分组中,类似于网络中的namespace.概念。当多个不同的用户使用同一个RabbitMQ server提供的服务时,可以划分出多个vhost,每个用户在自己的vhost创建exchange / queue 等 |
Connection | publisher / consumer和broker之间的TCP连接 |
Channel | 如果每一次访问 RabbitMQ 都建立一个Connection,在消息量大的时候建立TCPConnection的开销将是巨大的,效率也较低。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的分发依据 |
2.4 RabbitMQ的安装
2.2.1 下载
官网下载地址
:
2.2.2 下载安装包
2.2.3 安装步骤
# 1.将rabbitmq安装包上传到linux系统中,使用sftp上传,快捷键alt+p:
erlang-22.0.7-1.el7.x86_64.rpm
rabbitmq-server-3.7.18-1.el7.noarch.rpm
# 2.安装Erlang依赖包(两种方式)
rpm -ivh erlang-22.0.7-1.el7.x86_64.rpm
# 测试
erl -version
# 2.1 安装内存管理依赖包(可选)
rpm -ivh socat-1.7.3.2-2.el7.x86_64.rpm
# 3.安装RabbitMQ安装包(需要联网)
yum install -y rabbitmq-server-3.7.18-1.el7.noarch.rpm
注意:默认安装完成后配置文件模板在:/usr/share/doc/rabbitmq-server-3.7.18/rabbitmq.config.example目录中,需要将配置文件复制到/etc/rabbitmq/目录中,并修改名称为rabbitmq.config
# 4.复制配置文件
cp /usr/share/doc/rabbitmq-server-3.7.18/rabbitmq.config.example /etc/rabbitmq/rabbitmq.config
# 5.查看配置文件位置(默认该路径下没有配置文件,需要讲第4步的rabbitMQ模板配置文件复制一份)
ls /etc/rabbitmq/rabbitmq.config
# 6.修改配置文件(参见下图:)
vim /etc/rabbitmq/rabbitmq.config
将上图中配置文件中红色部分去掉
%%
,以及最后的,
逗号 修改为下图:意思是打开来宾账号
# 7.执行如下命令,启动rabbitmq中的插件管理
rabbitmq-plugins enable rabbitmq_management
出现如下说明:
Enabling plugins on node rabbit@localhost:
rabbitmq_management
The following plugins have been configured:
rabbitmq_management
rabbitmq_management_agent
rabbitmq_web_dispatch
Applying plugin configuration to rabbit@localhost...
The following plugins have been enabled:
rabbitmq_management
rabbitmq_management_agent
rabbitmq_web_dispatch
set 3 plugins.
Offline change; changes will take effect at broker restart.
# 8.启动RabbitMQ的服务
systemctl start rabbitmq-server 启动
systemctl restart rabbitmq-server 重启
systemctl stop rabbitmq-server 停止
chkconfig rabbitmq-server on # 添加开机启动RabbitMQ服务
# 9.查看服务状态(见下图:)
systemctl status rabbitmq-server
● rabbitmq-server.service - RabbitMQ broker
Loaded: loaded (/usr/lib/systemd/system/rabbitmq-server.service; disabled; vendor preset: disabled)
Active: active (running) since 三 2019-09-25 22:26:35 CST; 7s ago
Main PID: 2904 (beam.smp)
Status: "Initialized"
CGroup: /system.slice/rabbitmq-server.service
├─2904 /usr/lib64/erlang/erts-10.4.4/bin/beam.smp -W w -A 64 -MBas ageffcbf -MHas ageffcbf -
MBlmbcs...
├─3220 erl_child_setup 32768
├─3243 inet_gethost 4
└─3244 inet_gethost 4
.........
# 10.关闭防火墙服务
systemctl disable firewalld
Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.
systemctl stop firewalld
firewall-cmd --permanent --add-port=15672/tcp # 开启防火墙
firewall-cmd --reload # 重启生效
# 10.1 添加用户并且设置权限(可选)
# 创建账号
rabbitmqctl add_user admin 123
# 设置用户角色
rabitmqctl set_user_tags admin adminstrator
# 设置用户权限
rabbitmqctl set_permissions -p "/" admin ".*" ".*" ".*"
# 查看用户列表
rabbitmqctl list_users
# 11.访问web管理界面
http://10.15.0.8:15672/
http://192.168.224.129:15672/
# 12.登录管理界面
username: guest
password: guest
2.2.4 docker方式安装
官网:
docker run -id --name myrabbit -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=123456 -p 15672:15672 rabbitmq:3-management
3 RabiitMQ 配置
3.1RabbitMQ 管理命令行
# 1.服务启动相关
systemctl start rabbitmq-server 启动
systemctl restart rabbitmq-server 重启
systemctl stop rabbitmq-server 停止
systemctl status rabbitmq-server 查看状态
# 2.管理命令行 用来在不使用web管理界面情况下命令操作RabbitMQ
rabbitmqctl help 可以查看更多命令
# 3.插件管理命令行
rabbitmq-plugins enable|list|disable
3.2 web管理界面介绍
3.2.1 overview概览
connections:无论生产者还是消费者,都需要与RabbitMQ建立连接后才可以完成消息的生产和消费,在这里可以查看连接情况
channels:通道,建立连接后,会形成通道,消息的投递获取依赖通道。
Exchanges:交换机,用来实现消息的路由
Queues:队列,即消息队列,消息存放在队列中,等待消费,消费后被移除队列。
3.2.2 Admin用户和虚拟主机管理
- 添加用户
上面的Tags选项,其实是指定用户的角色,可选的有以下几个:
超级管理员(administrator)
可登陆管理控制台,可查看所有的信息,并且可以对用户,策略(policy)进行操作。监控者(monitoring)
可登陆管理控制台,同时可以查看rabbitmq节点的相关信息(进程数,内存使用情况,磁盘使用情况等)策略制定者(policymaker)
可登陆管理控制台, 同时可以对policy进行管理。但无法查看节点的相关信息(上图红框标识的部分)。普通管理者(management)
仅可登陆管理控制台,无法看到节点信息,也无法对策略进行管理。其他
无法登陆管理控制台,通常就是普通的生产者和消费者。
- 创建虚拟主机
虚拟主机:为了让各个用户可以互不干扰的工作,RabbitMQ添加了虚拟主机(Virtual Hosts)的概念。其实就是一个独立的访问路径,不同用户使用不同路径,各自有自己的队列、交换机,互相不会影响。
- 绑定虚拟主机和用户
创建好虚拟主机,我们还要给用户添加访问权限: 点击添加好的虚拟主机:
4 RabbitMQ的第一个程序
4.1 AMQP协议的回顾
4.2 RabbitMQ支持的消息模型
4.3 引入依赖
<dependency>
<groupId>com.rabbitmq</groupId>
<artifactId>amqp-client</artifactId>
<version>5.7.2</version>
</dependency>
4.4 第一种模型(直连)
在上图的模型中,有以下概念:
- P:生产者,也就是要发送消息的程序
- C:消费者:消息的接受者,会一直等待消息到来。
- queue:消息队列,图中红色部分。类似一个邮箱,可以缓存消息;生产者向其中投递消息,消费者从其中取出消息。
4.4.1 开发生产者
- 示例一
public class Provider {
//生产消息
public static void main(String[] args) throws IOException, TimeoutException {
//创建连接mq的连接工厂
ConnectionFactory connectionFactory = new ConnectionFactory();
//设置连接rabbitmq主机
connectionFactory.setHost("39.105.61.8");
//设置端口号
connectionFactory.setPort(5672);
//设置连接那个虚拟主机
connectionFactory.setVirtualHost("ems");
//设置访问虚拟主机的用户名和密码
connectionFactory.setUsername("ems");
connectionFactory.setPassword("123");
//获取连接对象
Connection connection = connectionFactory.newConnection();
//获取连接中的通道
Channel channel = connection.createChannel();
//通道绑定对应的消息队列
//参数1: 队列名称 如果队列不存在自动创建
//参数2: 用来定义队列特性是否要持久化 true 持久化队列 false 不持久化
//参数3: exclusive 是否独占队列 true 独占队列 false 不独占
//参数4: autoDelete: 是否在消费完成后自动删除队列 true 自动删除 false 不自动删除
//参数5: 额外附加参数
channel.queueDeclare("hello",true,false,false,null);
//发布消息
//参数1: 交换机名称 参数2:队列名称 参数3:传递消息额外设置 参数4:消息的具体内容
channel.basicPublish("","hello", MessageProperties.PERSISTENT_TEXT_PLAIN,"hello rabbitmq".getBytes(StandardCharsets.UTF_8));
//关闭通道
channel.close();
//关闭连接
connection.close();
}
}
- 示例二
/**
* 生产者-发送消息
*/
public class Producer {
private final static String QUEUE_NAME = "rabbitmq";
public static void main(String[] args) throws IOException, TimeoutException {
//创建一个连接工厂
ConnectionFactory connectionFactory = new ConnectionFactory();
connectionFactory.setHost("39.105.61.8");
connectionFactory.setPort(5672);
connectionFactory.setVirtualHost("ems");
connectionFactory.setUsername("ems");
connectionFactory.setPassword("123");
//channel 实现了自动 close 接口 自动关闭 不需要显示关闭
//创建连接
Connection connection = connectionFactory.newConnection();
//获取通道
Channel channel = connection.createChannel();
/**
* 生成一个队列
* 1.队列名称
* 2.队列里面的消息是否持久化 也就是是否用完就删除
* 3.该队列是否只供一个消费者进行消费 是否进行共享 true 可以多个消费者消费
* 4.是否自动删除 最后一个消费者端开连接以后 该队列是否自动删除 true 自动删除
* 5.其他参数
*/
channel.queueDeclare(QUEUE_NAME,false,false,false,null);
String message = "hello rabbitMQ";
/**
* 发送一个消息
* 1.发送到那个交换机
* 2.路由的 key 是哪个
* 3.其他的参数信息
* 4.发送消息的消息体
*/
channel.basicPublish("",QUEUE_NAME,null,message.getBytes(StandardCharsets.UTF_8));
System.out.println("消息发送完毕");
}
}
4.4.2 开发消费者
- 示例一
public class Customer {
public static void main(String[] args) throws IOException, TimeoutException {
//创建连接mq的连接工厂
ConnectionFactory connectionFactory = new ConnectionFactory();
//设置连接rabbitmq主机
connectionFactory.setHost("39.105.61.8");
//设置端口号
connectionFactory.setPort(5672);
//设置连接那个虚拟主机
connectionFactory.setVirtualHost("ems");
//设置访问虚拟主机的用户名和密码
connectionFactory.setUsername("ems");
connectionFactory.setPassword("123");
//获取连接对象
Connection connection = connectionFactory.newConnection();
//创建通道
Channel channel = connection.createChannel();
channel.queueDeclare("hello",true,false,false,null);
//消费消息
//参数1: 消费那个队列的消息 队列名称
//参数2: 开始消息的自动确认机制
//参数3: 消费时的回调接口
channel.basicConsume("hello",true,new DefaultConsumer(channel){
@Override //最后一个参数: 消息队列中取出的消息
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
System.out.println("======"+new String(body));
}
});
}
}
参数的说明: channel.queueDeclare(“hello”,true,false,false,null);
参数1
:用来声明通道对应的队列参数2
:用来指定是否持久化队列参数3
:用来指定是否独占队列参数4
:用来指定是否自动删除队列参数5
:对队列的额外配置
- 示例二
/**
* 消费者消费生产者发送的消息
*/
public class Consumer {
private final static String QUEUE_NAME = "rabbitmq";
public static void main(String[] args) throws IOException, TimeoutException {
//创建连接mq的连接工厂
ConnectionFactory connectionFactory = new ConnectionFactory();
//设置连接rabbitmq主机
connectionFactory.setHost("39.105.61.8");
//设置端口号
connectionFactory.setPort(5672);
//设置连接那个虚拟主机
connectionFactory.setVirtualHost("ems");
//设置访问虚拟主机的用户名和密码
connectionFactory.setUsername("ems");
connectionFactory.setPassword("123");
Connection connection = connectionFactory.newConnection();
Channel channel = connection.createChannel();
System.out.println("等待接收消息.........");
//推送的消息如何进行消费的接口回调
DeliverCallback deliverCallback = (consumerTag,deliver) ->{
String message = new String(deliver.getBody());
System.out.println(message);
};
//取消消费的一个回调接口 如在消费的时候队列被删除掉了
CancelCallback cancelCallback = (consumerTag) ->{
System.out.println("消息消费被中断");
};
/**
* 消费者消费消息 - 接受消息
* 1.消费哪个队列
* 2.消费成功之后是否要自动应答 true 代表自动应答 false 手动应答
* 3.消费者未成功消费的回调
* 4.消息被取消时的回调
*/
channel.basicConsume(QUEUE_NAME,true,deliverCallback,cancelCallback);
}
}
4.5 第二种模型(work quene)
Work queues
,也被称为(Task queues
),任务模型。当消息处理比较耗时的时候,可能生产消息的速度会远远大于消息的消费速度。长此以往,消息就会堆积越来越多,无法及时处理。此时就可以使用work 模型:让多个消费者绑定到一个队列,共同消费队列中的消息。队列中的消息一旦消费,就会消失,因此任务是不会被重复执行的。
工作队列(又称任务队列)的主要思想是避免立即执行资源密集型任务,而不得不等待它完成。相反我们安排任务在之后执行。我们把任务封装为消息并将其发送到队列。在后台运行的工作进程将弹出任务并最终执行作业。当有多个工作线程时,这些工作线程将一起处理这些任务。
角色:
- P:生产者:任务的发布者
- C1:消费者-1,领取任务并且完成任务,假设完成速度较慢
- C2:消费者-2:领取任务并完成任务,假设完成速度快
4.5.1 开发生产者
- 封装的工具类
public class RabbitMQUtils {
private static ConnectionFactory connectionFactory;
private static Properties properties;
static{
//重量级资源 类加载执行之执行一次
connectionFactory = new ConnectionFactory();
connectionFactory.setHost("39.105.61.8");
connectionFactory.setPort(5672);
connectionFactory.setVirtualHost("/");
connectionFactory.setUsername("guest");
connectionFactory.setPassword("guest");
}
//定义提供连接对象的方法
public static Connection getConnection() {
try {
return connectionFactory.newConnection();
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
//关闭通道和关闭连接工具方法
public static void closeConnectionAndChanel(Channel channel, Connection conn) {
try {
if(channel!=null) channel.close();
if(conn!=null) conn.close();
} catch (Exception e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
//System.out.println("RabbitMQUtils.getConnection() = " + RabbitMQUtils.getConnection());
}
}
/**
* 工作队列-生产者生成消息
*/
public class Provider {
public static void main(String[] args) throws IOException {
//工具类,获取连接对象
Connection connection = RabbitMQUtils.getConnection();
//获取通道对象
Channel channel = connection.createChannel();
//通过通道声明队列
channel.queueDeclare("work",true,false,false,null);
for (int i = 0; i <= 20; i++) {
//生成消息
channel.basicPublish("","work",null,(i + "_"+"hello work quene").getBytes(StandardCharsets.UTF_8));
}
//关闭资源
RabbitMQUtils.closeConnectionAndChanel(channel,connection);
}
}
4.5.2 开发消费者-1
/**
* 消费者1-消费消息
*/
public class Customer1 {
public static void main(String[] args) throws IOException {
//获取连接
Connection connection = RabbitMQUtils.getConnection();
Channel channel = connection.createChannel();
//每次只能消费一个消息
channel.basicQos(1);
channel.queueDeclare("work",true,false,false,null);
//参数1:队列名称 参数2:消息自动确认 true 消费者自动向rabbitmq确认消息消费 false 不会自动确认消息
channel.basicConsume("work",false,new DefaultConsumer(channel){
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("消费者-1: "+new String(body));
// 参数1:确认队列中那个具体消息 参数2:是否开启多个消息同时确实
channel.basicAck(envelope.getDeliveryTag(),false);
}
});
}
}
4.5.3 开发消费者-2
/**
* 消费者2-消费消息
*/
public class Customer2 {
public static void main(String[] args) throws IOException {
//获取连接
Connection connection = RabbitMQUtils.getConnection();
final Channel channel = connection.createChannel();
channel.basicQos(1);
channel.queueDeclare("work",true,false,false,null);
channel.basicConsume("work",false,new DefaultConsumer(channel){
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
System.out.println("消费者-2: "+new String(body));
//手动确认 参数1:手动确认消息标识 参数2:false 每次确认一个
channel.basicAck(envelope.getDeliveryTag(), false);
}
});
}
}
4.5.4 测试结果
总结:默认情况下,RabbitMQ将按顺序将每个消息发送给下一个使用者。平均而言,每个消费者都会收到相同数量的消息。这种分发消息的方式称为循环。
4.5.5 消息自动确认机制
Doing a task can take a few seconds. You may wonder what happens if one of the consumers starts a long task and dies with it only partly done. With our current code, once RabbitMQ delivers a message to the consumer it immediately marks it for deletion. In this case, if you kill a worker we will lose the message it was just processing. We’ll also lose all the messages that were dispatched to this particular worker but were not yet handled. 完成一项任务可能需要几秒钟的时间。你可能想知道,如果其中一个消费者开始了一项长期任务,但只完成了一部分就去世了,会发生什么。在我们当前的代码中,一旦RabbitMQ将消息传递给消费者,它就会立即将其标记为删除。在这种情况下,如果你杀死一名工人,我们将丢失它刚刚处理的消息。我们还将丢失发送给该特定工作程序但尚未处理的所有消息。 But we don’t want to lose any tasks. If a worker dies, we’d like the task to be delivered to another worker. 但我们不想失去任何任务。如果一名工人死亡,我们希望将任务交付给另一名工人。
channel.basicQos(1);//一次只接受一条未确认的消息
//参数2:关闭自动确认消息
channel.basicConsume("hello",false,new DefaultConsumer(channel){
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
System.out.println("消费者1: "+new String(body));
channel.basicAck(envelope.getDeliveryTag(),false);//手动确认消息
}
});
- 设置通道一次只能消费一个消息
- 关闭消息的自动确认,开启手动确认消息
4.5.6 轮训分发消息
在这个案例中我们会启动两个工作线程,一个消息发送线程,我们来看看他们两个工作线程是如何工作的。
- 抽取工具类
public class RabbitMqUtilsSGG {
//得到一个连接的channel
public static Channel getChannel() throws IOException, TimeoutException {
//创建一个连接工厂
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("39.105.61.8");
factory.setPort(5672);
factory.setVirtualHost("ems");
factory.setUsername("guest");
factory.setPassword("guest");
Connection connection = factory.newConnection();
Channel channel = connection.createChannel();
return channel;
}
}
- 启动两个工作线程来接受消息
/**
* 这是一个工作线程,相当于之前的消费者
*/
public class Worker01 {
private final static String QUEUE_NAME = "hello";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtilsSGG.getChannel();
//消息接受
DeliverCallback deliverCallback = (consumerTag,delivery) -> {
String receivedMessage = new String(delivery.getBody());
System.out.println("接受到消息:"+receivedMessage);
};
//消息被取消
CancelCallback cancelCallback = (consumerTag) -> {
System.out.println(consumerTag+"消费者取消消息接口回调逻辑");
};
System.out.println("C1 消费者启动等待消费...");
channel.basicConsume(QUEUE_NAME,true,deliverCallback,cancelCallback);
}
}
同时开启2个工作线程: 然后启动工作线程1:
修改输出信息,作为工作线程2:
- 启动一个发送消息线程
public class Task01 {
private final static String QUEUE_NAME = "hello";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtilsSGG.getChannel();
Scanner scanner = new Scanner(System.in);
while (scanner.hasNext()){
String message = scanner.next();
channel.basicPublish("",QUEUE_NAME,null,message.getBytes(StandardCharsets.UTF_8));
System.out.println("消息发送完毕:"+message);
}
}
}
- 结果展示
通过程序执行发现生产者总共发送 4 个消息,消费者 1 和消费者 2 分别分得两个消息,并且是按照有序的一个接收一次消息
4.5.7 消息应答
- 消费者完成一个任务可能需要一段时间,如果其中一个消费者处理一个长的任务并仅只完成了部分突然它挂掉了,会发生什么情况。RabbitMQ 一旦向消费者传递了一条消息,便立即将该消息标记为删除。在这种情况下,突然有个消费者挂掉了,我们将丢失正在处理的消息。以及后续发送给该消费这的消息,因为它无法接收到。
- 为了保证消息在发送过程中不丢失,引入消息应答机制,
消息应答就是:消费者在接收到消息并且处理该消息之后,告诉 rabbitmq 它已经处理了,rabbitmq 可以把该消息删除了
。
- 自动应答
消息发送后立即被认为已经传送成功,这种模式需要在
高吞吐量和数据传输安全性方面做权衡
,因为这种模式如果消息在接收到之前,消费者那边出现连接或者 channel 关闭,那么消息就丢失 了,当然另一方面这种模式消费者那边可以传递过载的消息,没有对传递的消息数量进行限制
,当然这样有可能使得消费者这边由于接收太多还来不及处理的消息,导致这些消息的积压,最终使 得内存耗尽,最终这些消费者线程被操作系统杀死,所以这种模式仅适用在消费者可以高效并以某种速率能够处理这些消息的情况下使用。
- 手动消息应答的方法
- Channel.basicAck(用于肯定确认) RabbitMQ 已知道该消息并且成功的处理消息,可以将其丢弃了
- Channel.basicNack(用于否定确认)
- Channel.basicReject(用于否定确认) 与 Channel.basicNack 相比少一个参数,不处理该消息了直接拒绝,可以将其丢弃了
Multiple 的解释:
手动应答的好处是可以批量应答并且减少网络拥堵
multiple的true和false是不同的意思:
- true 代表批量应答 channel 上未应答的消息 比如说 channel 上有传送 tag 的消息 5,6,7,8 当前 tag 是8 那么此时5-8 的这些还未应答的消息都会被确认收到消息应答
- false 同上面相比只会应答 tag=8 的消息 5,6,7 这三个消息依然不会被确认收到消息应答
4.5.8 消息自动重新入队
如果消费者由于某些原因失去连接(其通道已关闭,连接已关闭或 TCP 连接丢失),导致消息未发送 ACK 确认,RabbitMQ 将了解到消息未完全处理,并将对其重新排队。如果此时其他消费者可以处理,它将很快将其重新分发给另一个消费者。这样,即使某个消费者偶尔死亡,也可以确保不会丢失任何消息。
4.5.9 消息手动应答代码
默认消息采用的是自动应答,所以我们要想实现消息消费过程中不丢失,需要把自动应答改为手动应答
- 生产者
/**
* 消息在手动应答时是不丢失、放回队列中重新消费
*/
public class Task2 {
private final static String QUEUE_NAME = "hello";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtilsSGG.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(StandardCharsets.UTF_8));
System.out.println("生产者生成消息:"+message);
}
}
}
- 消费者1
/*
* 消费者1
* */
public class Worker03 {
private final static String QUEUE_NAME = "hello";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtilsSGG.getChannel();
System.out.println("C1等待接受消息处理时间较短");
DeliverCallback deliverCallback = (consumerTag,message) -> {
// 沉睡一秒
try {
Thread.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("接受到的消息是:"+new String(message.getBody()));
//进行手动应答
/*
* 参数1:消息的标记 tag
* 参数2:是否批量应答,false:不批量应答 true:批量
*/
channel.basicAck(message.getEnvelope().getDeliveryTag(),false);
};
//次用手动应答
boolean autoAck = false;
channel.basicConsume(QUEUE_NAME,autoAck,deliverCallback,(consumerTag) -> {
System.out.println(consumerTag+"消费者取消消费接口回调逻辑");
});
}
}
- 消费者2
/*
* 消费者2
* */
public class Worker04 {
private final static String QUEUE_NAME = "hello";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtilsSGG.getChannel();
System.out.println("C2等待接受消息处理时间较短");
DeliverCallback deliverCallback = (consumerTag,message) -> {
// 沉睡30秒
try {
Thread.sleep(30);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("接受到的消息是:"+new String(message.getBody()));
//进行手动应答
/*
* 参数1:消息的标记 tag
* 参数2:是否批量应答,false:不批量应答 true:批量
*/
channel.basicAck(message.getEnvelope().getDeliveryTag(),false);
};
//次用手动应答
boolean autoAck = false;
channel.basicConsume(QUEUE_NAME,autoAck,deliverCallback,(consumerTag) -> {
System.out.println(consumerTag+"消费者取消消费接口回调逻辑");
});
}
}
- 手动应答效果演示
正常情况下消息发送方发送两个消息 C1 和 C2 分别接收到消息并进行处理
在发送者发送消息 dd,发出消息之后的把 C2 消费者停掉,按理说该 C2 来处理该消息,但是由于它处理时间较长,在还未处理完,也就是说 C2 还没有执行 ack 代码的时候,C2 被停掉了, 此时会看到消息被 C1 接收到了,说明消息 dd 被重新入队,然后分配给能处理消息的 C1 处理了
![]()
![]()
4.5.10 RabbitMQ持久化
当 RabbitMQ 服务停掉以后,消息生产者发送过来的消息不丢失要如何保障?默认情况下 RabbitMQ 退出或由于某种原因崩溃时,它忽视队列和消息,除非告知它不要这样做。确保消息不会丢失需要做两件事:
我们需要将队列和消息都标记为持久化。
- 队列如何实现持久化
之前我们创建的队列都是非持久化的,rabbitmq 如果重启的化,该队列就会被删除掉,如果要队列实现持久化需要在声明队列的时候把 durable 参数设置为持久化
//让队列持久化
boolean durable = true;
//声明队列
channel.queueDeclare(TASK_QUEUE_NAME, durable, false, false, null);
注意:如果之前声明的队列不是持久化的,需要把原先队列先删除,或者重新创建一个持久化的队列,不然就会出现错误
以下为控制台中持久化与非持久化队列的 UI 显示区、
- 消息实现持久化
需要在消·息生产者·修改代码,MessageProperties.PERSISTENT_TEXT_PLAIN 添加这个属性。
//设置生产者发送消息为持久化消息(要求保存到磁盘上)
channel.basicPublish("",TASK_QUEUE_NAME, MessageProperties.PERSISTENT_TEXT_PLAIN
,message.getBytes(StandardCharsets.UTF_8));
System.out.println("生产者发出消息:"+message);
将消息标记为持久化并不能完全保证不会丢失消息。尽管它告诉 RabbitMQ 将消息保存到磁盘,但是这里依然存在当消息刚准备存储在磁盘的时候 但是还没有存储完,消息还在缓存的一个间隔点。此时并没 有真正写入磁盘。持久性保证并不强,但是对于我们的简单任务队列而言,这已经绰绰有余了。
/**
* 消息在手动应答时是不丢失、放回队列中重新消费
*/
public class Task2 {
private final static String QUEUE_NAME = "hello";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtilsSGG.getChannel();
//声明队列
//持久化 需要让Queue持久化
boolean durable = true;
channel.queueDeclare(QUEUE_NAME, durable,false,false,null);
Scanner scanner = new Scanner(System.in);
while (scanner.hasNext()){
String message = scanner.next();
//设置生产者发送消息为持久化(要求保存到磁盘上)
channel.basicPublish("",QUEUE_NAME, MessageProperties.PERSISTENT_TEXT_PLAIN,message.getBytes(StandardCharsets.UTF_8));
System.out.println("生产者生成消息:"+message);
}
}
}
4.5.11 不公平分发
- 在最开始的时候我们学习到 RabbitMQ 分发消息采用的轮训分发,但是在某种场景下这种策略并不是很好,比方说有两个消费者在处理任务,其中有个
消费者 1
处理任务的速度非常快,而另外一个消费者 2
处理速度却很慢,这个时候我们还是采用轮训分发的化就会到这处理速度快的这个消费者很大一部分时间处于空闲状态,而处理慢的那个消费者一直在干活,这种分配方式在这种情况下其实就不太好,但是 RabbitMQ 并不知道这种情况它依然很公平的进行分发。- 为了避免这种情况,在消费者中消费之前,我们可以设置参数
channel.basicQos(1);
// 设置不公平分发
int prefetchCount = 1;
channel.basicQos(prefetchCount);
/*
* 消费者2
* */
public class Worker04 {
private final static String QUEUE_NAME = "hello";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtilsSGG.getChannel();
System.out.println("C2等待接受消息处理时间较短");
DeliverCallback deliverCallback = (consumerTag,message) -> {
// 沉睡30秒
try {
Thread.sleep(30);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("接受到的消息是:"+new String(message.getBody()));
//进行手动应答
/*
* 参数1:消息的标记 tag
* 参数2:是否批量应答,false:不批量应答 true:批量
*/
channel.basicAck(message.getEnvelope().getDeliveryTag(),false);
};
// 设置不公平分发
int prefetchCount = 1;
channel.basicQos(prefetchCount);
//采用手动应答
boolean autoAck = false;
channel.basicConsume(QUEUE_NAME,autoAck,deliverCallback,(consumerTag) -> {
System.out.println(consumerTag+"消费者取消消费接口回调逻辑");
});
}
}
意思就是如果这个任务我还没有处理完或者我还没有应答你,你先别分配给我,我目前只能处理一个 任务,然后 rabbitmq 就会把该任务分配给没有那么忙的那个空闲消费者,当然如果所有的消费者都没有完 成手上任务,队列还在不停的添加新任务,队列有可能就会遇到队列被撑满的情况,这个时候就只能添加 新的 worker 或者改变其他存储任务的策略。
4.5.12 预取值分发
- 带权的消息分发
- 本身消息的发送就是异步发送的,所以在任何时候,channel 上肯定不止只有一个消息另外来自消费 者的手动确认本质上也是异步的。因此这里就存在一个未确认的消息缓冲区,因此希望开发人员能
限制此缓冲区的大小,以避免缓冲区里面无限制的未确认消息问题
。这个时候就可以通过使用 basic.qos 方法设 置“预取计数”值来完成的。- 该值定义通道上允许的未确认消息的最大数量。一旦数量达到配置的数量, RabbitMQ 将停止在通道上传递更多消息,除非至少有一个未处理的消息被确认,例如,假设在通道上有未确认的消息 5、6、7,8,并且通道的预取计数设置为 4,此时RabbitMQ 将不会在该通道上再传递任何消息,除非至少有一个未应答的消息被 ack。比方说 tag=6 这个消息刚刚被确认 ACK,RabbitMQ 将会感知 这个情况到并再发送一条消息。消息应答和 QoS 预取值对用户吞吐量有重大影响。
- 通常,增加预取将提高 向消费者传递消息的速度。
虽然自动应答传输消息速率是最佳的,但是,在这种情况下已传递但尚未处理的消息的数量也会增加,从而增加了消费者的 RAM 消耗
(随机存取存储器)应该小心使用具有无限预处理的自动确认模式或手动确认模式,消费者消费了大量的消息如果没有确认的话,会导致消费者连接节点的 内存消耗变大,所以找到合适的预取值是一个反复试验的过程,不同的负载该值取值也不同 100 到 300 范 围内的值通常可提供最佳的吞吐量,并且不会给消费者带来太大的风险。- 预取值为 1 是最保守的。当然这将使吞吐量变得很低,特别是消费者连接延迟很严重的情况下,特别是在消费者连接等待时间较长的环境 中。对于大多数应用来说,稍微高一点的值将是最佳的。
/*
* 消费者2
* */
public class Worker04 {
private final static String QUEUE_NAME = "hello";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtilsSGG.getChannel();
System.out.println("C2等待接受消息处理时间较短");
DeliverCallback deliverCallback = (consumerTag,message) -> {
// 沉睡30秒
try {
Thread.sleep(30);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("接受到的消息是:"+new String(message.getBody()));
//进行手动应答
/*
* 参数1:消息的标记 tag
* 参数2:是否批量应答,false:不批量应答 true:批量
*/
channel.basicAck(message.getEnvelope().getDeliveryTag(),false);
};
// 设置不公平分发
// int prefetchCount = 1;
//channel.basicQos(prefetchCount);
//预设值是5
int prefetchCount = 5;
channel.basicQos(5);
//采用手动应答
boolean autoAck = false;
channel.basicConsume(QUEUE_NAME,autoAck,deliverCallback,(consumerTag) -> {
System.out.println(consumerTag+"消费者取消消费接口回调逻辑");
});
}
}
4.6 发布确认
4.6.1 发布确认原理
- 生产者将信道设置成 confirm 模式,一旦信道进入 confirm 模式,所有在该信道上面发布的消息都将会被指派一个唯一的 ID(从 1 开始),一旦消息被投递到所有匹配的队列之后,broker 就会发送一个确认给生产者(包含消息的唯一 ID),这就使得生产者知道消息已经正确到达目的队列了,如果消息和队列是可持久化的,那么确认消息会在将消息写入磁盘之后发出,broker 回传给生产者的确认消息中 delivery-tag 域包含了确认消息的序列号,此外 broker 也可以设置basic.ack 的 multiple 域,表示到这个序列号之前的所有消息都已经得到了处理。
- confirm 模式最大的好处在于他是异步的,一旦发布一条消息,生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息,当消息最终得到确认之后,生产者应用便可以通过回调方法来处理该确认消息,如果RabbitMQ 因为自身内部错误导致消息丢失,就会发送一条 nack 消息, 生产者应用程序同样可以在回调方法中处理该 nack 消息。
4.6.2 发布确认的策略
开启发布确认的方法:
- 发布确认默认是没有开启的,如果要开启需要调用方法 confirmSelect,每当你要想使用发布确认,都需要在 channel 上调用该方法
//开启发布确认
Channel channel = connection.createChannel();
channel.confirmSelect();
- 单个确认发布
- 这是一种简单的确认方式,它是一种
同步确认发布
的方式,也就是发布一个消息之后只有它被确认发布,后续的消息才能继续发布,waitForConfirmsOrDie(long)
这个方法只有在消息被确认的时候才返回,如果在指定时间范围内这个消息没有被确认那么它将抛出异常。- 这种确认方式有一个最大的缺点就是:
发布速度特别的慢
,因为如果没有确认发布的消息就会阻塞所有后续消息的发布,这种方式最多提供每秒不超过数百条发布消息的吞吐量。当然对于某些应用程序来说这可能已经足够了。
/*
* 发布确认模式,
* 1、单个确认
* */
public class SingleTask3 {
// 批量发消息的个数
public static final int MESSAGE_COUNT = 1000;
public static void main(String[] args) throws Exception {
// 1、单个确认
// 发布1000个单独确认消息,耗时567ms
SingleTask3.publishMessageIndividually();
}
public static void publishMessageIndividually() throws IOException, TimeoutException, InterruptedException {
Channel channel = RabbitMqUtilsSGG.getChannel();
//队列声明
String queueName = UUID.randomUUID().toString();
channel.queueDeclare(queueName,true,false,false,null);
//开启发布确认
channel.confirmSelect();
//开始时间
long start = System.currentTimeMillis();
//批量发消息
for (int i = 0; i < MESSAGE_COUNT; i++) {
String message = i+"";
channel.basicPublish("",queueName,null,message.getBytes(StandardCharsets.UTF_8));
// 单个消息马上进行发布确认
boolean flag = channel.waitForConfirms();
if(flag){
System.out.println("消息发送成功!");
}
}
long end = System.currentTimeMillis();
System.out.println("发布"+MESSAGE_COUNT+"条单独确认消息,耗时为"+(end - start)+"ms");
}
}
- 批量确认发布
上面那种方式非常慢,与单个等待确认消息相比,先发布一批消息然后一起确认可以极大地提高吞吐量,当然这种方式的缺点就是:当发生故障导致发布出现问题时,不知道是哪个消息出 问题了,我们必须将整个批处理保存在内存中,以记录重要的信息而后重新发布消息。当然这种方案仍然是同步的,也一样阻塞消息的发布。
/*
* 发布确认模式,
* 2、批量确认
* */
public class MoreTask3 {
// 批量发消息的个数
public static final int MESSAGE_COUNT = 1000;
public static void main(String[] args) throws Exception {
//2、批量确认
// 发布1000个批量确认消息,耗时37ms
MoreTask3.publishMessageBatch();
}
private static void publishMessageBatch() throws IOException, TimeoutException, InterruptedException {
Channel channel = RabbitMqUtilsSGG.getChannel();
String queueName = UUID.randomUUID().toString();
channel.queueDeclare(queueName,false,false,false,null);
//开启发布确认
channel.confirmSelect();
//开始时间
long start = System.currentTimeMillis();
//批量确认消息大小
int batchSize = 1000;
//批量发送,批量确认
for (int i = 0; i < MESSAGE_COUNT; i++) {
String message = i + "";
channel.basicPublish("",queueName,null,message.getBytes(StandardCharsets.UTF_8));
//判断达到100条消息的时候,批量确认一次
if(i % batchSize == 0){
// 确认发布
channel.waitForConfirms();
}
}
//为了确保还有剩余没有确认消息 再次确认
if (batchSize > 0) {
channel.waitForConfirms();
}
//结束时间
long end = System.currentTimeMillis();
System.out.println("发布"+MESSAGE_COUNT+"条批量确认消息,耗时"+ (end - start) + "ms");
}
}
- 异步发布确认
异步确认虽然编程逻辑比上两个要复杂,但是性价比最高,无论是可靠性还是效率都没得说, 他是利用回调函数来达到消息可靠性传递的,这个中间件也是通过函数回调来保证是否投递成功, 下面就让我们来详细讲解异步确认是怎么实现的。
/**
*发布确认模式,
* 3、异步批量确认
*/
public class SyncTask3 {
// 批量发消息的个数
public static final int MESSAGE_COUNT = 1000;
public static void main(String[] args) throws Exception {
//3、异步批量确认
// 发布1000个异步确认消息,耗时36ms
SyncTask3.publicMessageAsync();
}
private static void publicMessageAsync() throws IOException, TimeoutException {
Channel channel = RabbitMqUtilsSGG.getChannel();
String queueName = UUID.randomUUID().toString();
channel.queueDeclare(queueName,false,false,false,null);
//开启发布确认
channel.confirmSelect();
//开始时间
long start = System.currentTimeMillis();
//消费确认成功回调函数
ConfirmCallback ackCallback = (deliveryTag,multiply) -> {
System.out.println("确认的消息:"+deliveryTag);
};
// 消息确认失败回调函数
/*
* 参数1:消息的标记
* 参数2:是否为批量确认
* */
ConfirmCallback nackCallback = (deliveryTag,multiply) -> {
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(StandardCharsets.UTF_8));
}
// 结束时间
long end = System.currentTimeMillis();
System.out.println("发布"+MESSAGE_COUNT+"条异步确认消息,耗时"+ (end - start) + "ms");
}
}
如何处理异步未确认消息? 最好的解决的解决方案就是把未确认的消息放到一个基于内存的能被发布线程访问的队列, 比如说用 ConcurrentLinkedQueue 这个队列在 confirm callbacks 与发布线程之间进行消息的传递。
public class SyncTask4 {
// 批量发消息的个数
public static final int MESSAGE_COUNT = 1000;
public static void main(String[] args) throws Exception {
//3、异步批量确认
// 发布1000个异步确认消息,耗时36ms
SyncTask4.publicMessageAsync();
}
private static void publicMessageAsync() throws IOException, TimeoutException {
Channel channel = RabbitMqUtilsSGG.getChannel();
String queueName = UUID.randomUUID().toString();
channel.queueDeclare(queueName,false,false,false,null);
//开启发布确认
channel.confirmSelect();
/*
* 线程安全有序的一个哈希表 适用于高并发的情况下
* 1、轻松地将序号与消息进行关联
* 2、轻松地批量删除,只要给到序号
* 3、支持高并发
* */
ConcurrentSkipListMap<Long,String> confirms = new ConcurrentSkipListMap<>();
// 消息确认成功回调函数
ConfirmCallback ackCallback = (deliveryTag,multiply) -> {
//删除到已经确认的消息,剩下的就是未确认的消息
if(multiply){
ConcurrentNavigableMap<Long, String> confiremed = confirms.headMap(deliveryTag);
confiremed.clear();
}else {
confirms.remove(deliveryTag);
}
System.out.println("确认的消息:"+deliveryTag);
};
// 消息确认失败回调函数
/*
* 参数1:消息的标记
* 参数2:是否为批量确认
* */
ConfirmCallback nackCallback = (deliveryTag,multiply) -> {
// 打印一下未确认的消息都有哪些
String message = confirms.get(deliveryTag);
System.out.println("未确认的消息是:" + message +"未确认的消息tag:" + deliveryTag);
};
// 准备消息的监听器,监听哪些消息成功,哪些消息失败
/*
* 参数1:监听哪些消息成功
* 参数2:监听哪些消息失败
* */
channel.addConfirmListener(ackCallback,nackCallback);
// 开始时间
long start = System.currentTimeMillis();
// 批量发送消息
for (int i = 0; i < MESSAGE_COUNT; i++) {
String message = "消息" + i;
channel.basicPublish("",queueName,null,message.getBytes(StandardCharsets.UTF_8));
// 此处记录下所有要发送的消息的总和
confirms.put(channel.getNextPublishSeqNo(),message);
}
// 结束时间
long end = System.currentTimeMillis();
System.out.println("发布"+MESSAGE_COUNT+"条异步确认消息,耗时"+ (end - start) + "ms");
}
}
三种发布确认速度对比
发布方式 | 特点 |
---|---|
单独发布消息 | 同步等待确认,简单,但吞吐量非常有限 |
批量发布消息 | 批量同步等待确认,简单,合理的吞吐量,一旦出现问题但很难推断出是那条消息出现了问题。 |
异步处理 | 最佳性能和资源使用,在出现错误的情况下可以很好地控制,但是实现起来稍微难些 |
4.7 第三种模型(fanout)
fanout 扇出 也称为广播
在广播模式下,消息发送流程是这样的:
- 可以有多个消费者
- 每个消费者有自己的queue(队列)
- 每个队列都要绑定到Exchange(交换机)
- 生产者发送的消息,只能发送到交换机,交换机来决定要发给哪个队列,生产者无法决定。
- 交换机把消息发送给绑定过的所有队列
- 队列的消费者都能拿到消息。实现一条消息被多个消费者消费
4.7.1 开发生产者
/**
* 分发广播-生产者
*/
public class Provider {
public static void main(String[] args) throws IOException {
//获取连接对象
Connection connection = RabbitMQUtils.getConnection();
Channel channel = connection.createChannel();
//将通道声明指定交换机 //参数1: 交换机名称 参数2: 交换机类型 fanout 广播类型
channel.exchangeDeclare("logs","fanout");
//发送消息
channel.basicPublish("logs","",null,"fanout type message".getBytes(StandardCharsets.UTF_8));
//释放资源
RabbitMQUtils.closeConnectionAndChanel(channel,connection);
}
}
4.7.2 开发消费者-1
/**
* 分发广播-消费者1
*/
public class Customer1 {
public static void main(String[] args) throws IOException {
//获取连接对象
Connection connection = RabbitMQUtils.getConnection();
Channel channel = connection.createChannel();
//通道绑定交换机
channel.exchangeDeclare("logs","fanout");
//临时队列
String queueName = channel.queueDeclare().getQueue();
//绑定交换机和队列
channel.queueBind(queueName,"logs","");
//消费消息
channel.basicConsume(queueName,true,new DefaultConsumer(channel){
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
System.out.println("消费者1: "+new String(body));
}
});
}
}
4.7.3 开发消费者-2
public class Customer2 {
public static void main(String[] args) throws IOException, IOException {
//获取连接对象
Connection connection = RabbitMQUtils.getConnection();
Channel channel = connection.createChannel();
//通道绑定交换机
channel.exchangeDeclare("logs","fanout");
//临时队列
String queueName = channel.queueDeclare().getQueue();
//绑定交换机和队列
channel.queueBind(queueName,"logs","");
//消费消息
channel.basicConsume(queueName,true,new DefaultConsumer(channel){
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
System.out.println("消费者2: "+new String(body));
}
});
}
}
4.7.4 开发消费者-3
public class Customer3 {
public static void main(String[] args) throws IOException, IOException {
//获取连接对象
Connection connection = RabbitMQUtils.getConnection();
Channel channel = connection.createChannel();
//通道绑定交换机
channel.exchangeDeclare("logs","fanout");
//临时队列
String queueName = channel.queueDeclare().getQueue();
//绑定交换机和队列
channel.queueBind(queueName,"logs","");
//消费消息
channel.basicConsume(queueName,true,new DefaultConsumer(channel){
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
System.out.println("消费者3: "+new String(body));
}
});
}
}
4.7.5 测试结果
4.7.5 交换机(Exchanges)
- RabbitMQ 消息传递模型的核心思想是:
生产者生产的消息从不会直接发送到队列
。实际上,通常生产者甚至都不知道这些消息传递传递到了哪些队列中。- 相反,生产者只能将消息发送到交换机(exchange),交换机工作的内容非常简单,一方面它接收来自生产者的消息,另一方面将它们推入队列。交换机必须确切知道如何处理收到的消息。是应该把这些消息放到特定队列还是说把他们放到许多队列中还是说应该丢弃它们。这就的由交换机的类型来决定。
- Exchanges 的类型
直接(direct), 主题(topic) ,标题(headers) , 扇出(fanout)
- 无名exchange:
在前面部分我们对 exchange 一无所知,但仍然能够将消息发送到队列。之前能实现的 原因是因为我们使用的是默认交换,我们通过空字符串(“”)进行标识。
channel.basiPublish("","hello",null,message.getBytes());
第一个参数是交换机的名称。空字符串表示默认或无名称交换机:消息能路由发送到队列中其实是由 routingKey(bindingkey)绑定 key 指定的,如果它存在的话
4.7.6 临时队列
- 之前的章节我们使用的是具有特定名称的队列(还记得 hello 和 ack_queue 吗?)。队列的名称我们来说至关重要,我们需要指定我们的消费者去消费哪个队列的消息。
- 每当我们连接到 Rabbit 时,我们都需要一个全新的空队列,为此我们可以创建一个
具有随机名称的队列
,或者能让服务器为我们选择一个随机队列名称那就更好了。其次一旦我们断开了消费者的连接,队列将被自动删除。
创建临时队列的方式如下:
String queueName = channel.queueDeclare().getQueue();
4.7.7 绑定 bindings
什么是 bingding 呢,binding 其实是 exchange 和 queue 之间的桥梁,它告诉我们 exchange 和那个队列进行了绑定关系。比如说下面这张图告诉我们的就是 X 与 Q1 和 Q2 进行了绑定
4.7.8 Fanout exchange
4.7.8.1 Fanout 介绍
Fanout 这种类型非常简单。正如从名称中猜到的那样,它是将接收到的所有消息广播到它知道的 所有队列中。系统中默认有些 exchange 类型
4.7.8.2 Fanout 实战
Logs 和临时队列的绑定关系如下图
- 消费者1
/**
* 分发广播-消费者1
*/
public class ReceiveLogs01 {
//交换机名称
public static final String EXCHANGE_NAME = "logs";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtilsSGG.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()));
};
channel.basicConsume(queueName,true,deliverCallback,consumerTag -> {});
}
}
- 消费者2
/**
* 分发广播-消费者2
*/
public class ReceiveLogs02 {
//交换机名称
public static final String EXCHANGE_NAME = "logs";
public static void main(String[] args) throws IOException, TimeoutException {
Channel channel = RabbitMqUtilsSGG.getChannel();
channel.exchangeDeclare(EXCHANGE_NAME, "fanout");
//声明一个队列,名称随机,当消费者断开与队列的连接时,队列自动删除
String queueName = channel.queueDeclare().getQueue();
//绑定交换机和队列
//把该临时队列绑定我们的 exchange 其中 routingkey(也称之为 binding key)为空字符串
channel.queueBind(queueName,EXCHANGE_NAME,"");
System.out.println("等待接受消息,把接受到的消息打印在屏幕上...");
DeliverCallback deliverCallback = (consumerTag,message) -> {
System.out.println("ReceiveLogs02控制台打印接受到的消息:" + new String(message.getBody()));
};
channel.basicConsume(queueName,true,deliverCallback,consumerTag -> {});
}
}
- 生产者
/*
* 发消息 交换机
* */
public class Emitlog {
// 交换机的名称
public static final String EXCHANGE_NAME = "logs";
public static void main(String[] args) throws Exception{
Channel channel = RabbitMqUtilsSGG.getChannel();
/**
* 声明一个 exchange
* 1.exchange 的名称
* 2.exchange 的类型
*/
channel.exchangeDeclare(EXCHANGE_NAME,"fanout");
Scanner scanner = new Scanner(System.in);
System.out.println("请输入信息");
while (scanner.hasNext()){
String message = scanner.next();
channel.basicPublish(EXCHANGE_NAME,"",null,message.getBytes(StandardCharsets.UTF_8));
System.out.println("生产者发出的消息:"+ message);
}
}
}
- 测试结果
4.8 第四种模型(Routing)
4.8.1 Routing之订阅模型-Direct(直连)
在Fanout模式中,一条消息,会被所有订阅的队列都消费。但是,在某些场景下,我们希望不同的消息被不同的队列消费。这时就要用到Direct类型的Exchange。
在Direct模型下:
- 队列与交换机的绑定,不能是任意绑定了,而是要指定一个
RoutingKey
(路由key)- 消息的发送方在 向 Exchange发送消息时,也必须指定消息的
RoutingKey
。- Exchange不再把消息交给每一个绑定的队列,而是根据消息的
Routing Key
进行判断,只有队列的Routingkey
与消息的Routing key
完全一致,才会接收到消息
图解:
- P:生产者,向Exchange发送消息,发送消息时,会指定一个routing key。
- X:Exchange(交换机),接收生产者的消息,然后把消息递交给 与routing key完全匹配的队列
- C1:消费者,其所在队列指定了需要routing key 为 error 的消息
- C2:消费者,其所在队列指定了需要routing key 为 info、error、warning 的消息
4.8.1.1 开发生产者
/**
* 订阅模式-直连-生产者
*/
public class Provider {
public static void main(String[] args) throws IOException {
//获取连接对象
Connection connection = RabbitMQUtils.getConnection();
//获取连接通道对象
Channel channel = connection.createChannel();
String exchangeName = "logs_direct";
//通过通道声明交换机 参数1:交换机名称 参数2:direct 路由模式
channel.exchangeDeclare(exchangeName,"direct");
//发送消息
String routingKey = "track";
channel.basicPublish(exchangeName,routingKey,null,("这是direct模型发布的基于route key: ["+routingKey+"] 发送的消息").getBytes(StandardCharsets.UTF_8));
//关闭资源
RabbitMQUtils.closeConnectionAndChanel(channel,connection);
}
}
4.8.1.2 开发消费者-1
/**
* 订阅模式-直连-消费者1
*/
public class Customer1 {
public static void main(String[] args) throws IOException {
Connection connection = RabbitMQUtils.getConnection();
Channel channel = connection.createChannel();
String exchangeName = "logs_direct";
//通道声明交换机以及交换的类型
channel.exchangeDeclare(exchangeName,"direct");
//创建一个临时文件
String queue = channel.queueDeclare().getQueue();
//基于routeKey绑定队列和交换机
channel.queueBind(queue,exchangeName,"error");
//获取消费的消息
channel.basicConsume(queue,true,new DefaultConsumer(channel){
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
System.out.println("消费者1: "+ new String(body));
}
});
}
}
4.8.1.3 开发消费者-2
/**
* 订阅模式-直连-消费者2
*/
public class Customer2 {
public static void main(String[] args) throws IOException, IOException {
Connection connection = RabbitMQUtils.getConnection();
Channel channel = connection.createChannel();
String exchangeName = "logs_direct";
//声明交换机 以及交换机类型 direct
channel.exchangeDeclare(exchangeName,"direct");
//创建一个临时队列
String queue = channel.queueDeclare().getQueue();
//临时队列和交换机绑定
channel.queueBind(queue,exchangeName,"info");
channel.queueBind(queue,exchangeName,"error");
channel.queueBind(queue,exchangeName,"warning");
//消费消息
channel.basicConsume(queue,true,new DefaultConsumer(channel){
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
System.out.println("消费者2: "+new String(body));
}
});
}
}
- 测试生产者发送Route key为error的消息时
- 测试生产者发送Route key为info的消息时
4.8.1.4 Direct exchange
- Direct 介绍
日志系统将所有消息广播给所有消费者,对此我们想做一些改变,例如我们希 望将日志消息写入磁盘的程序仅接收严重错误(errros),而不存储哪些警告(warning)或信息(info)日志 消息避免浪费磁盘空间。Fanout 这种交换类型并不能给我们带来很大的灵活性-它只能进行无意识的 广播,在这里我们将使用 direct 这种类型来进行替换,这种类型的工作方式是,消息只去到它绑定的 routingKey 队列中去。
- 在上面这张图中,我们可以看到 X 绑定了两个队列,绑定类型是 direct。队列Q1 绑定键为 orange, 队列 Q2 绑定键有两个:一个绑定键为 black,另一个绑定键为 green.
- 在这种绑定情况下,生产者发布消息到 exchange 上,绑定键为 orange 的消息会被发布到队列 Q1。绑定键为 blackgreen 和的消息会被发布到队列 Q2,其他消息类型的消息将被丢弃。
- 多重绑定
当然如果 exchange 的绑定类型是direct,
但是它绑定的多个队列的 key 如果都相同
,在这种情况下虽然绑定类型是 direct但是它表现的就和 fanout 有点类似了
,就跟广播差不多,如上图所示。
- Direct 实战
c2:绑定disk,routingKey为error c1:绑定console,routingKey为info、warning
暂无评论内容