RabbitMQ交换器Exchange介绍与实践
RabbitMQ系列文章
- RabbitMQ在Ubuntu上的环境搭建
- 深入了解RabbitMQ工作原理及简单使用
- RabbitMQ交换器Exchange介绍与实践
- RabbitMQ事务和Confirm发送方消息确认——深入解读
- 使用Docker部署RabbitMQ集群
- 你不知道的RabbitMQ集群架构全解
导读
有了Rabbit的基础知识之后(基础知识详见:深入解读RabbitMQ工作原理及简单使用),本章我们重点学习一下Rabbit里面的exchange(交换器)的知识。
交换器分类
RabbitMQ的Exchange(交换器)分为四类:
- direct(默认)
- headers
- fanout
- topic
其中headers交换器允许你匹配AMQP消息的header而非路由键,除此之外headers交换器和direct交换器完全一致,但性能却很差,几乎用不到,所以我们本文也不做讲解。
注意:fanout、topic交换器是没有历史数据的,也就是说对于中途创建的队列,获取不到之前的消息。
1、direct交换器
direct为默认的交换器类型,也非常的简单,如果路由键匹配的话,消息就投递到相应的队列,如图:
使用代码:channel.basicPublish("", QueueName, null, message)推送direct交换器消息到对于的队列,空字符为默认的direct交换器,用队列名称当做路由键。
direct交换器代码示例
发送端:
Connection conn = connectionFactoryUtil.GetRabbitConnection();
Channel channel = conn.createChannel();
// 声明队列【参数说明:参数一:队列名称,参数二:是否持久化;参数三:是否独占模式;参数四:消费者断开连接时是否删除队列;参数五:消息其他参数】
channel.queueDeclare(config.QueueName, false, false, false, null);
String message = String.format("当前时间:%s", new Date().getTime());
// 推送内容【参数说明:参数一:交换机名称;参数二:队列名称,参数三:消息的其他属性-路由的headers信息;参数四:消息主体】
channel.basicPublish("", config.QueueName, null, message.getBytes("UTF-8"));
接收端,持续接收消息:
Connection conn = connectionFactoryUtil.GetRabbitConnection();
Channel channel = conn.createChannel();
// 声明队列【参数说明:参数一:队列名称,参数二:是否持久化;参数三:是否独占模式;参数四:消费者断开连接时是否删除队列;参数五:消息其他参数】
channel.queueDeclare(config.QueueName, false, false, false, null);
Consumer defaultConsumer = new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties,
byte[] body) throws IOException {
String message = new String(body, "utf-8"); // 消息正文
System.out.println("收到消息 => " + message);
channel.basicAck(envelope.getDeliveryTag(), false); // 手动确认消息【参数说明:参数一:该消息的index;参数二:是否批量应答,true批量确认小于当前id的消息】
}
};
channel.basicConsume(config.QueueName, false, "", defaultConsumer);
接收端,获取单条消息
Connection conn = connectionFactoryUtil.GetRabbitConnection();
Channel channel = conn.createChannel();
channel.queueDeclare(config.QueueName, false, false, false, null);
GetResponse resp = channel.basicGet(config.QueueName, false);
String message = new String(resp.getBody(), "UTF-8");
channel.basicAck(resp.getEnvelope().getDeliveryTag(), false); // 消息确认
持续消息获取使用:basic.consume;单个消息获取使用:basic.get。
注意:不能使用for循环单个消息消费来替代持续消息消费,因为这样性能很低;
公平调度
当接收端订阅者有多个的时候,direct会轮询公平的分发给每个订阅者(订阅者消息确认正常),如图:
消息的发后既忘特性
发后既忘模式是指接受者不知道消息的来源,如果想要指定消息的发送者,需要包含在发送内容里面,这点就像我们在信件里面注明自己的姓名一样,只有这样才能知道发送者是谁。
消息确认
看了上面的代码我们可以知道,消息接收到之后必须使用channel.basicAck()方法手动确认(非自动确认删除模式下),那么问题来了。
消息收到未确认会怎么样?
如果应用程序接收了消息,因为bug忘记确认接收的话,消息在队列的状态会从“Ready”变为“Unacked”,如图:
如果消息收到却未确认,Rabbit将不会再给这个应用程序发送更多的消息了,这是因为Rabbit认为你没有准备好接收下一条消息。
此条消息会一直保持Unacked的状态,直到你确认了消息,或者断开与Rabbit的连接,Rabbit会自动把消息改完Ready状态,分发给其他订阅者。
当然你可以利用这一点,让你的程序延迟确认该消息,直到你的程序处理完相应的业务逻辑,这样可以有效的防治Rabbit给你过多的消息,导致程序崩溃。
消息确认Demo:
Connection conn = connectionFactoryUtil.GetRabbitConnection();
Channel channel = conn.createChannel();
channel.queueDeclare(config.QueueName, false, false, false, null);
GetResponse resp = channel.basicGet(config.QueueName, false);
String message = new String(resp.getBody(), "UTF-8");
channel.basicAck(resp.getEnvelope().getDeliveryTag(), false);
channel.basicAck(long deliveryTag, boolean multiple)为消息确认,参数1:消息的id;参数2:是否批量应答,true批量确认小于次id的消息。
总结:消费者消费的每条消息都必须确认。
消息拒绝
消息在确认之前,可以有两个选择:
选择1:断开与Rabbit的连接,这样Rabbit会重新把消息分派给另一个消费者;
选择2:拒绝Rabbit发送的消息使用channel.basicReject(long deliveryTag, boolean requeue),参数1:消息的id;参数2:处理消息的方式,如果是true,Rabbib会重新分配这个消息给其他订阅者,如果设置成false的话,Rabbit会把消息发送到一个特殊的“死信”队列,用来存放被拒绝而不重新放入队列的消息。
消息拒绝Demo:
Connection conn = connectionFactoryUtil.GetRabbitConnection();
Channel channel = conn.createChannel();
channel.queueDeclare(config.QueueName, false, false, false, null);
GetResponse resp = channel.basicGet(config.QueueName, false);
String message = new String(resp.getBody(), "UTF-8");
channel.basicReject(resp.getEnvelope().getDeliveryTag(), true); //消息拒绝
2、fanout交换器——发布/订阅模式
fanout有别于direct交换器,fanout是一种发布/订阅模式的交换器,当你发送一条消息的时候,交换器会把消息广播到所有附加到这个交换器的队列上。
比如用户上传了自己的头像,这个时候图片需要清除缓存,同时用户应该得到积分奖励,你可以把这两个队列绑定到图片上传的交换器上,这样当有第三个、第四个上传完图片需要处理的需求的时候,原来的代码可以不变,只需要添加一个订阅消息即可,这样发送方和消费者的代码完全解耦,并可以轻而易举的添加新功能了。
和direct交换器不同,我们在发送消息的时候新增channel.exchangeDeclare(ExchangeName, "fanout"),这行代码声明fanout交换器。
发送端:
final String ExchangeName = "fanoutec"; // 交换器名称
Connection conn = connectionFactoryUtil.GetRabbitConnection();
Channel channel = conn.createChannel();
channel.exchangeDeclare(ExchangeName, "fanout"); // 声明fanout交换器
String message = "时间:" + new Date().getTime();
channel.basicPublish(ExchangeName, "", null, message.getBytes("UTF-8"));
接受消息不同于direct,我们需要声明fanout路由器,并使用默认的队列绑定到fanout交换器上。
接收端:
Connection conn = connectionFactoryUtil.GetRabbitConnection();
Channel channel = conn.createChannel();
channel.exchangeDeclare(ExchangeName, "fanout"); // 声明fanout交换器
String queueName = channel.queueDeclare().getQueue(); // 声明队列
channel.queueBind(queueName, ExchangeName, "");
Consumer consumer = new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties,
byte[] body) throws IOException {
String message = new String(body, "UTF-8");
}
};
channel.basicConsume(queueName, true, consumer);
fanout和direct的区别最多的在接收端,fanout需要绑定队列到对应的交换器用于订阅消息。
其中channel.queueDeclare().getQueue()为随机队列,Rabbit会随机生成队列名称,一旦消费者断开连接,该队列会自动删除。
注意:对于fanout交换器来说routingKey(路由键)是无效的,这个参数是被忽略的。
3、topic交换器——匹配订阅模式
最后介绍的是topic交换器,topic交换器运行和fanout类似,但是可以更灵活的匹配自己想要订阅的信息,这个时候routingKey路由键就排上用场了,使用路由键进行消息(规则)匹配。
假设我们现在有一个日志系统,会把所有日志级别的日志发送到交换器,warning、log、error、fatal,但我们只想处理error以上的日志,要怎么处理?这就需要使用topic路由器了。
topic路由器的关键在于定义路由键,定义routingKey名称不能超过255字节,使用“.”作为分隔符,例如:com.mq.rabbit.error。
消费消息的时候routingKey可以使用下面字符匹配消息:
- "*"匹配一个分段(用“.”分割)的内容;
- "#"匹配0和多个字符;
例如发布了一个“com.mq.rabbit.error”的消息:
能匹配上的路由键:
- cn.mq.rabbit.*
- cn.mq.rabbit.#
- #.error
- cn.mq.#
- #
不能匹配上的路由键:
- cn.mq.*
- *.error
- *
所以如果想要订阅所有消息,可以使用“#”匹配。
注意:fanout、topic交换器是没有历史数据的,也就是说对于中途创建的队列,获取不到之前的消息。
发布端:
String routingKey = "com.mq.rabbit.error";
Connection conn = connectionFactoryUtil.GetRabbitConnection();
Channel channel = conn.createChannel();
channel.exchangeDeclare(ExchangeName, "topic"); // 声明topic交换器
String message = "时间:" + new Date().getTime();
channel.basicPublish(ExchangeName, routingKey, null, message.getBytes("UTF-8"));
接收端:
Connection conn = connectionFactoryUtil.GetRabbitConnection();
Channel channel = conn.createChannel();
channel.exchangeDeclare(ExchangeName, "topic"); // 声明topic交换器
String queueName = channel.queueDeclare().getQueue(); // 声明队列
String routingKey = "#.error";
channel.queueBind(queueName, ExchangeName, routingKey);
Consumer consumer = new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties,
byte[] body) throws IOException {
String message = new String(body, "UTF-8");
System.out.println(routingKey + "|接收消息 => " + message);
}
};
channel.basicConsume(queueName, true, consumer);
扩展部分—自定义线程池
如果需要更大的控制连接,用户可自己设置线程池,代码如下:
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
ExecutorService es = Executors.newFixedThreadPool(20);
Connection conn = factory.newConnection(es);
其实看过源码的同学可能知道,factory.newConnection本身默认也有线程池的机制,ConnectionFactory.class部分源码如下:
private ExecutorService sharedExecutor;
public Connection newConnection() throws IOException, TimeoutException {
return newConnection(this.sharedExecutor, Collections.singletonList(new Address(getHost(), getPort())));
}
public void setSharedExecutor(ExecutorService executor) {
this.sharedExecutor = executor;
}
其中this.sharedExecutor就是默认的线程池,可以通过setSharedExecutor()方法设置ConnectionFactory的线程池,如果不设置则为null。
用户如果自己设置了线程池,像本小节第一段代码写的那样,那么当连接关闭的时候,不会自动关闭用户自定义的线程池,所以用户必须自己手动关闭,通过调用shutdown()方法,否则可能会阻止JVM的终止。
官方的建议是只有在程序出现严重性能瓶颈的时候,才应该考虑使用此功能。
项目地址
RabbitMQ交换器Exchange介绍与实践的更多相关文章
-
RabbitMQ系列(三)RabbitMQ交换器Exchange介绍与实践
RabbitMQ交换器Exchange介绍与实践 RabbitMQ系列文章 RabbitMQ在Ubuntu上的环境搭建 深入了解RabbitMQ工作原理及简单使用 RabbitMQ交换器Exchang ...
-
Rabbitmq交换器Exchange和消息队列
通常我们谈到队列服务, 会有三个概念: 发消息者.队列.收消息者,RabbitMQ 在这个基本概念之上, 多做了一层抽象, 在发消息者和 队列之间, 加入了交换器 (Exchange). 这样发消息者 ...
-
RabbitMQ的交换器Exchange之direct(发布与订阅 完全匹配)
1.交换器.用来接收生产者发送的消息并将这些消息路由给服务器中的队列.三种常用的交换器类型,a.direct(发布与订阅 完全匹配).b.fanout(广播).c.topic(主题,规则匹配). 2. ...
-
RabbitMQ(2) 一般介绍
RabbitMQ 即一个消息队列,主要是用来实现应用程序的异步和解耦,同时也能起到消息缓冲,消息分发的作用. 消息中间件在互联网公司的使用中越来越多,刚才还看到新闻阿里将RocketMQ捐献给了apa ...
-
RabbitMQ的基础介绍
转自:http://blog.csdn.net/whycold/article/details/41119807 一.引言 你是否遇到过两个(多个)系统间需要通过定时任务来同步某些数据?你是否在为异构 ...
-
rabbitmq的简单介绍一
该博客的主要讲解了以下几种rabbitmq的用法1.实现简单的生产者发送消息给消费者2.实现序列持久化3.实现消息持久化4.实现消息公平分发5.实现广播6.实现组播7.实现细分组播 先来看下rabbi ...
-
python 消息队列-rabbitMQ 和 redis介绍使用
1.rabbitMQ 与ptyhon 进程queue 区别.进程queue 主要用户Python父子进程之间或者统一进程不同子进程.rabbit可以用户不同语言之前的相互交流,socket可以实现同样 ...
-
RabbitMQ 交换器、持久化
一. 交换器 RabbitMQ交换器(Exchange)分为四种 direct fanout topic headers direct 默认的交换器类型,消息的RoutingKey与队列的bindi ...
-
关于Axure RP软件的介绍——软件工程实践第二次个人作业
关于Axure RP软件的介绍——软件工程实践第二次个人作业 Axure RP是一个非常专业的快速原型设计的一个工具,客户提出需求,然后根据需求定义和规格.设计功能和界面的专家能够快速创建应用软件或W ...
随机推荐
-
kubernetes deployment升级和回滚
a.创建deployment pod kubectl run mynginx --image=docker.io/nginx: --record 准备svc文件 apiVersion: v1 kind ...
-
关于Android 8.0java.lang.SecurityException: Permission Denial错误的解决方法
背景 当我在Android 7.0及以下手机运行启动页,进行Activity跳转的时候,完美跳转到对应的目标Activity. 但当在Android 8.0及以上手机进行Activity跳转时,会爆如 ...
-
layui 富文本 图片上传 后端PHP接口
<!DOCTYPE html> <html> <head> <link rel="stylesheet" type="text/ ...
-
day26 第二阶段共享
第二阶段共享--网络编程 一.C/S架构 : 客户端(client)/服务端(sever)框架 B/S架构: 浏览器(brower)/服务端(sever)架构 软件CS架构: 服务端连接到浏览器,QQ ...
-
NFS服务的端口分配
常规的一些NFS服务设置我们已经了解了.那么对于端口问题,很多朋友并不是很清楚.这里我们就来详细介绍一下端口的分配.portmapper在NFS服务启动的时候给每一个NFS服务分配了一个动态的端口,如 ...
-
interceptor&filter
1.基于 filter基于filter接口中的doFilter回调函数: interceptor则基于Java本身的反射机制: 2.与servlet关系 filter是依赖于servlet容器的,没有 ...
-
spring autowired还需要在xml中申明bean ?
如果未自动扫描spring管理的类,则需要在xml中申明.如果自动扫描包下的类,则不需要 (如果配置了自动扫描,还是不行还需要进行手动在xml中声明,则就是工程建立的有问题,包的路径等问题)
-
bzoj4199: [Noi2015]品酒大会(后缀数组)
题目描述 一年一度的“幻影阁夏日品酒大会”隆重开幕了.大会包含品尝和趣味挑战 两个环节,分别向优胜者颁发“首席品酒家”和“首席猎手”两个奖项,吸引了众多品酒师参加. 在大会的晚餐上,调酒师 Rainb ...
-
转:CodeReview 如何做?
http://www.cnblogs.com/IT-Bear/archive/2012/07/04/2576367.html
-
pip 代理设置,坑爹的代理继续
Linux ubuntu 3.2.0-23-generic-pae #36-Ubuntu SMP Tue Apr 10 22:19:09 UTC 2012 i686 i686 i386 GNU/Lin ...