RabbitMQ
1.初识MQ
1.1.同步和异步通讯
微服务间通讯有同步和异步两种方式:
同步通讯:就像打电话,需要实时响应。
异步通讯:就像发邮件,不需要马上回复。
两种方式各有优劣,打电话可以立即得到响应,但是你却不能跟多个人同时通话。发送邮件可以同时与多个人收发邮件,但是往往响应会有延迟。
1.1.1.同步通讯
我们之前学习的Feign调用就属于同步方式,虽然调用可以实时得到结果,但存在下面的问题:
总结:
同步调用的优点:
- 时效性较强,可以立即得到结果
同步调用的问题:
- 耦合度高
- 场景:用户支付完了应该给用户发个短信通知一声,所以需要加上一个发短信的业务,在支付服务中修改代码,因为之前的代码都写好了现在要加上一个发送短信的业务,就需要不断地在支付服务中修改代码,导致代码的耦合段变高。每次有一个新的业务需求都需要修改支付服务的代码,非常麻烦,耦合读极高。
- 性能和吞吐能力下降
- 场景:用户调用支付服务耗时50毫秒,支付服务调用其它服务各耗时150ms,由于是同步执行,所以支付服务掉完订单服务才可以调用仓库服务,掉完仓库服务才可以调用短信服务,整个流程耗时达到了500ms,也就是说1秒钟只能处理2个请求,数以百万级的并发来了业务根本扛不住,性能和吞吐能力下降都下降了。
- 有额外的资源消耗
- 场景:支付服务在等待订单服务执行的过程时,什么也没有干但是它的cpu内存却一直占用着资源,订单服务执行完之后在调用仓储服务时,支付服务仍然是什么也没干确占用着系统资源,同理短信服务也是如此,在整个等待的过程中支付服务有大量的系统资源的浪费。一次请求就浪费这么多资源,那么成百上千的请求浪费的更多。
- 有级联失败问题
- 场景:假如仓储服务扛不住压力挂掉了,此时支付服务调不通仓储服务就卡在这里了,请求得不到释放随着时间的推移卡在这个地方的请求越来越多,支付服务资源被耗尽请求再来也进不去了,此时相当于支付服务也挂了,用户在调用支付服务也调不通了,挂掉的服务越来也多。
1.1.2.异步通讯
异步调用则可以避免上述问题:
整个过程中,支付服务完成事件发布以后就立即结束了自己的业务,可以去返回给用户了,它不需要等待订单服务、仓储服务、短信服务完成业务,因为它已经将事件通知进去了,由broker负责通知这3个服务,什么时候去做什么时候做完支付服务不去管,这种方式就是异步方式。
我们以购买商品为例,用户支付后需要调用订单服务完成订单状态修改,调用物流服务,从仓库分配响应的库存并准备发货。
在事件模式中,支付服务是事件发布者(publisher),在支付完成后只需要发布一个支付成功的事件(event),事件中带上订单id。
订单服务和物流服务是事件订阅者(Consumer),订阅支付成功的事件,监听到事件后完成自己业务即可。
为了解除事件发布者与订阅者之间的耦合,两者并不是直接通信,而是有一个中间人(Broker)。发布者发布事件到Broker,不关心谁来订阅事件。订阅者从Broker订阅事件,不关心谁发来的消息。
Broker 是一个像数据总线一样的东西,所有的服务要接收数据和发送数据都发到这个总线上,这个总线就像协议一样,让服务间的通讯变得标准和可控。
好处:
-
吞吐量提升:无需等待订阅者处理完成,响应更快速
- 以前:支付服务调用订单服务、仓储服务、短信服务,每个服务都有耗时,4个服务的总耗时为500ms
- 现在:用户调用支付服务50ms,支付服务向broker发布事件10ms,这个时候支付服务就可以立即结束告诉用户支付成功了。后续的订单服务、仓储服务、短信服务跟支付服务本身是没有关系的,由broker去通知完成,它们什么时候完成耗时多久跟支付服务没有关系,只要最终能够完成就可以了。此时总耗时为60ms,耗时缩短了,那我们的性能是不是就得到提升了,吞吐量得到提高了。
-
故障隔离:服务没有直接调用,不存在级联失败问题
- 现在仓储服务挂掉了和支付服务没有什么关系了,支付服务发完事件到broker就结束了,又不调用仓储服务,你挂掉了肯定和支付服务没有关系了,大不了重启一下仓储服务就可以了。不会出现因为仓储服务挂掉导致支付服务也挂掉的情况了。
- 现在仓储服务挂掉了和支付服务没有什么关系了,支付服务发完事件到broker就结束了,又不调用仓储服务,你挂掉了肯定和支付服务没有关系了,大不了重启一下仓储服务就可以了。不会出现因为仓储服务挂掉导致支付服务也挂掉的情况了。
-
调用间没有阻塞,不会造成无效的资源占用
- 既然没有了这种强依赖的关系,支付服务不用调用仓储服务了,那也不用等待仓储服务了,所以也没有资源浪费的情况了。
-
耦合度极低,每个服务都可以灵活插拔,可替换
- 以前:增加短信业务需要修改支付服务的代码,耦合度高。想要取消短信业务需要删除代码,耦合度高。
- 现在:支付服务不负责调用这些服务,而是只发一个事件到broker就可以了,支付服务根本不管你仓储的服务,短信服务什么时候调用、什么时候调完,根本和支付服务没有关系。一旦有新的业务出现只需要去订阅broker事件就行了。想要取消短信服务的功能,只需要让短信服务取消订阅事件,这样broker就通知不到短信服务了。无论是添加业务还是删除业务都无需修改代码,降低了耦合。
-
流量削峰:不管发布事件的流量波动多大,都由Broker接收,订阅者可以按照自己的速度去处理事件
- 场景:一个用户给支付服务发送请求,消息过来之后订单服务、仓储服务、短信服务可以非常快速的去完成处理,但是随着业务量的增加用户越来越多,比如说一瞬间来了3个请求,假设订单服务、仓储服务、短信服务每一时刻只能处理一个,此时就处理不了了。
- 解决:使用Broker来起一个缓冲的作用,在里面拦截所有的请求,然后你能拿几个就拿几个,比如说我先取一个,处理完了在来取一个,这样以来订单服务、仓储服务、短信服务处理业务的速度一直可以按照自己的能力来,能处理几个就处理几个,处理不了就不处理了。
- 这样一来压力都是由Broker来扛着,不管你是来多少请求,订单服务、仓储服务、短信服务每秒钟能够处理多少就处理多少,一个高的并发就变为低的并发,微服务就起到了保护的作用。(适用于秒杀业务的高并发场景下)
缺点:
-
架构复杂了,业务没有明显的流程线,不好管理
- 一旦引入异步通讯服务间的调用,不在像以前一样清晰明了了,发一个事件至于谁去处理你不知道,调用链的关系不清晰会导致将来一旦出了问题不好排查
-
需要依赖于Broker的可靠、安全、性能
- 整个异步通信都依赖于Broker去实现,如果Broker挂掉了整个微服务就完蛋了。
什么时候使用同步什么时候使用异步???
- 事实上呢我们大多数情况下都会去使用同步,因为大多数情况下我们对于并发并没有很高的要求,相反我们对时效性要求较高,因为我希望的是我去调用你我查询了一个信息,而这个信息我立马又要在下边的业务中用到。eg:我查询到了一个订单,之后去查询用户,立马要用到,所以必须使用同步调用。因为异步调用只是通知去干一件事,也不知道是什么时候干完的,没有办法等待它的结果,因此这种情况下建议使用同步。
- 如果说你不需要对方的结果你只是让他去干一件事,并且呢你对于吞吐量的要求 并发的要求较高,你还希望解除服务间的这种耦合关系,那么应该使用异步通信。
好在现在开源软件或云平台上 Broker 的软件是非常成熟的,比较常见的一种就是我们今天要学习的MQ技术。
1.2.技术对比:
MQ,中文是消息队列(MessageQueue),字面来看就是存放消息的队列。也就是事件驱动架构中的Broker。
比较常见的MQ实现:
- ActiveMQ
- RabbitMQ
- RocketMQ
- Kafka
几种常见MQ的对比:
RabbitMQ | ActiveMQ | RocketMQ | Kafka | |
---|---|---|---|---|
公司/社区 | Rabbit | Apache | 阿里 | Apache |
开发语言 | Erlang | Java | Java | Scala&Java |
协议支持 | AMQP,XMPP,SMTP,STOMP | OpenWire,STOMP,REST,XMPP,AMQP | 自定义协议 | 自定义协议 |
可用性 | 高 | 一般 | 高 | 高 |
单机吞吐量 | 一般 | 差 | 高 | 非常高 |
消息延迟 | 微秒级 | 毫秒级 | 毫秒级 | 毫秒以内 |
消息可靠性 | 高 | 一般 | 高 | 一般 |
追求可用性:Kafka、 RocketMQ 、RabbitMQ
追求可靠性:RabbitMQ、RocketMQ
追求吞吐能力:RocketMQ、Kafka
追求消息低延迟:RabbitMQ、Kafka
2.快速入门
2.1.安装RabbitMQ
RabbitMQ是基于Erlang语言开发的开源消息通信中间件,官网地址:https://www.rabbitmq.com/
安装RabbitMQ,参考课前资料:
MQ的基本结构:
RabbitMQ中的一些角色:
- publisher:生产者
- consumer:消费者
- exchange个:交换机,负责消息路由
- queue:队列,存储消息
- virtualHost:虚拟主机,隔离不同租户的exchange、queue、消息的隔离
- 2个不同的用户来操作同一个RabbitMQ可能会造成冲突,可以使用虚拟主机对不同的用户进行一个隔离,这样就可以避免冲突了。
- 一般情况下,每个用户对应一台虚拟主机(直接在RabbitMQ管理页面上添加虚拟主机)。
2.2.RabbitMQ消息模型
RabbitMQ官方提供了5个不同的Demo示例,对应了不同的消息模型:
直接使用队列,没有使用交换机:
- 基本消息队列(BasicQueue)
- 工作消息队列(WorkQueue)
使用了交换机:
- 发布订阅(Publish、Subscribe),又根据交换机类型不同分为三种:
- Fanout Exchange:广播
- Direct Exchange:路由
- Topic Exchange:主题
2.3.导入Demo工程
课前资料提供了一个Demo工程,mq-demo:
导入后可以看到结构如下:
包括三部分:
- mq-demo:父工程,管理项目依赖
- publisher:消息的发送者
- consumer:消息的消费者
2.4.入门案例(简单队列模型)
简单队列模式的模型图:
官方的HelloWorld是基于最基础的消息队列模型来实现的,只包括三个角色:
- publisher:消息发布者,将消息发送到队列queue
- queue:消息队列,负责接受并缓存消息
- consumer:订阅队列,处理队列中的消息
2.4.1.publisher实现
思路:
- 建立连接
- 创建Channel
- 声明队列
- 发送消息
- 关闭连接和channel
代码实现:
package cn.itcast.mq.helloworld;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
import org.junit.Test;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
public class PublisherTest {
@Test
public void testSendMessage() throws IOException, TimeoutException {
// 1.建立连接
ConnectionFactory factory = new ConnectionFactory();
// 1.1.设置连接参数,分别是:主机名、端口号、vhost虚拟主机、用户名、密码
factory.setHost("192.168.10.161");
factory.setPort(5672);
factory.setVirtualHost("/");
factory.setUsername("itcast");
factory.setPassword("123321");
// 1.2.建立连接
Connection connection = factory.newConnection();
// 2.创建通道Channel
Channel channel = connection.createChannel();
// 3.创建队列
String queueName = "simple.queue";
channel.queueDeclare(queueName, false, false, false, null);
// 4.发送消息(往队列中发送消息)
String message = "hello, rabbitmq!";
channel.basicPublish("", queueName, null, message.getBytes());//底层使用字节传输
System.out.println("发送消息成功:【" + message + "】");
// 5.关闭通道和连接
channel.close();
connection.close();
}
}
2.4.2.consumer实现
代码思路:
- 建立连接
- 创建Channel
- 声明队列
- 订阅消息
代码实现:
package cn.itcast.mq.helloworld;
import com.rabbitmq.client.*;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
public class ConsumerTest {
public static void main(String[] args) throws IOException, TimeoutException {
// 1.建立连接
ConnectionFactory factory = new ConnectionFactory();
// 1.1.设置连接参数,分别是:主机名、端口号、vhost虚拟主机、用户名、密码
factory.setHost("192.168.10.161");
factory.setPort(5672);
factory.setVirtualHost("/");
factory.setUsername("itcast");
factory.setPassword("123321");
// 1.2.建立连接
Connection connection = factory.newConnection();
// 2.创建通道Channel
Channel channel = connection.createChannel();
// 3.创建队列
//生产者不是已经创建过一次队列了,这里为什么又在消费者中创建一次队列??
//因为:生产者和消费者的启动顺序是不确定的,万一消费者先启动找不到队列,就会报错。为了避免
//这种情况的发生,生产者和消费者都要去创建队列。生产者创建完队列后此时在执行这个代码不会再创建
//新的队列,它只是个保险措施防止队列不存在。
String queueName = "simple.queue";
channel.queueDeclare(queueName, false, false, false, null);
// 4.订阅消息 回调机制
channel.basicConsume(queueName, true, new DefaultConsumer(channel){
//回调函数:handleDelivery
@Override
public void handleDelivery(String consumerTag, Envelope envelope,
AMQP.BasicProperties properties, byte[] body) throws IOException {
// 5.处理消息
String message = new String(body);
System.out.println("接收到消息:【" + message + "】");
}
});
//执行顺序:先执行“等待接收消息”,在执行“接收到消息”????
//原因:回调机制,上面第四步订阅消息仅仅是把,消费者处理的回调函数跟队列进行绑定,此时消息还没有过来呢,之后接着执行
// 以下业务逻辑,等rabbitmq把消息投递过来了我的回调函数才会执行,所以后输出”接收到消息“
System.out.println("等待接收消息。。。。");
}
}
2.5.总结
基本消息队列的消息发送流程:
-
建立connection
-
创建channel
-
利用channel声明队列
-
利用channel向队列发送消息
基本消息队列的消息接收流程:
-
建立connection
-
创建channel
-
利用channel声明队列
-
定义consumer的消费行为handleDelivery()
-
利用channel将消费者与队列绑定
3.SpringAMQP
SpringAMQP是基于RabbitMQ封装的一套模板,并且还利用SpringBoot对其实现了自动装配,使用起来非常方便。
SpringAmqp的官方地址:https://spring.io/projects/spring-amqp
SpringAMQP提供了三个功能:
- 自动声明队列、交换机及其绑定关系
- 基于注解的监听器模式,异步接收消息
- 封装了RabbitTemplate工具,用于发送消息
3.1.Basic Queue 简单队列模型
在父工程mq-demo中引入依赖
<!--AMQP依赖,包含RabbitMQ-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-amqp</artifactId>
</dependency>
3.1.1.消息发送
首先配置MQ地址,在publisher服务的application.yml中添加配置:
spring:
rabbitmq:
host: 192.168.10.161 # 主机名
port: 5672 # 端口
virtual-host: / # 虚拟主机
username: itcast # 用户名
password: 123321 # 密码
然后在publisher服务中编写测试类SpringAmqpTest,并利用RabbitTemplate实现消息发送:
package cn.itcast.mq.spring;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit4.SpringRunner;
@RunWith(SpringRunner.class)
@SpringBootTest
public class SpringAmqpTest {
@Autowired
private RabbitTemplate rabbitTemplate;
@Test
public void testSimpleQueue() {
// 队列名称(用的是入门案例中创建的队列)
String queueName = "simple.queue";
// 消息
String message = "hello, spring amqp!";
// 发送消息(向队列中发)
rabbitTemplate.convertAndSend(queueName, message);
}
}
3.1.2.消息接收
首先配置MQ地址,在consumer服务的application.yml中添加配置:
spring:
rabbitmq:
host: 192.168.10.161 # 主机名
port: 5672 # 端口
virtual-host: / # 虚拟主机
username: itcast # 用户名
password: 123321 # 密码
然后在consumer服务的cn.itcast.mq.listener
包中新建一个类SpringRabbitListener,代码如下:
package cn.itcast.mq.listener;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;
@Component//这个类需要让spring知道
public class SpringRabbitListener {
@RabbitListener(queues = "simple.queue")//需要知道监听到那个队列
public void listenSimpleQueueMessage(String msg) throws InterruptedException {//用什么类型传递的就用什么类型接收,spring会自动接收到消息
System.out.println("spring 消费者接收到消息:【" + msg + "】");
}
}
3.1.3.测试
启动consumer服务(运行主启动类),然后在publisher服务中运行测试代码(运行测试类),发送MQ消息
注意:消息一旦消费就会从队列删除,RabbitMQ没有消息回溯功能
3.2.WorkQueue
Work queues,也被称为(Task queues),任务模型。简单来说就是让多个消费者绑定到一个队列,共同消费队列中的消息。
当消息处理比较耗时的时候,可能生产消息的速度会远远大于消息的消费速度。长此以往,消息就会堆积越来越多,无法及时处理。
此时就可以使用work 模型,多个消费者共同处理消息处理,速度就能大大提高了。
3.2.1.消息发送
这次我们循环发送,模拟大量消息堆积现象。
在publisher服务中的SpringAmqpTest类中添加一个测试方法:
/**
* workQueue
* 向队列中不停发送消息,模拟消息堆积。
*/
@Test
public void testWorkQueue() throws InterruptedException {
// 队列名称
String queueName = "simple.queue";
// 消息
String message = "hello, message_";
for (int i = 0; i < 50; i++) {
// 发送消息
rabbitTemplate.convertAndSend(queueName, message + i);
//不要发这么快,让50条消息在1秒内发完。(20*50=1000ms)
Thread.sleep(20);
}
}
3.2.2.消息接收
要模拟多个消费者绑定同一个队列,我们在consumer服务的SpringRabbitListener中添加2个新的方法:
@RabbitListener(queues = "simple.queue")
public void listenWorkQueue1(String msg) throws InterruptedException {
//out:打印出来的是白色
System.out.println("消费者1接收到消息:【" + msg + "】" + LocalTime.now());
//为了演示每秒钟处理的速度,给它加个休眠时间。(1s=1000ms,每20ms处理一条消息1s内可以处理50条消息)
Thread.sleep(20);
}
@RabbitListener(queues = "simple.queue")
public void listenWorkQueue2(String msg) throws InterruptedException {
//err:打印出来的是红色,这样看起来比较容易区分
System.err.println("消费者2........接收到消息:【" + msg + "】" + LocalTime.now());
//同上,每秒钟可以处理5条消息,这样加起来每秒钟可以处理55条消息,超过发送方1秒内发送的50条消息。
Thread.sleep(200);
}
注意到这个消费者sleep了1000秒,模拟任务耗时。
3.2.3.测试
启动ConsumerApplication主启动类后,在执行publisher服务中刚刚编写的发送测试方法testWorkQueue。
可以看到消费者1很快完成了自己的25条消息。消费者2却在缓慢的处理自己的25条消息。
也就是说消息是平均分配给每个消费者,并没有考虑到消费者的处理能力。这样显然是有问题的。
原因:这是由rabbitmq的消息预取机制
导致的,当我们有大量的消息到达我们的队列时,队列会进行一个消息投递,consumer1和consumer2的通道提前会把消息拿过来,2个消费者轮流拿消息就造成了每人平均分配了25条消息,但是消费者1处理速度快消费者2处理速度慢,所以导致总时间超出了。
3.2.4.能者多劳
在spring中有一个简单的配置,可以解决这个问题。修改application.yml文件,设置preFetch这个值,可以控制预取消息的上限:
spring:
rabbitmq:
listener:
simple:
prefetch: 1 # 每次只能获取一条消息,处理完成才能获取下一个消息(一般是消费能力低就调低一些,消费能力高就调高一些)
#(默认是无限的,有多少拿多少,什么时候消费你别管先拿过来在说)
重启消费者的主启动类,可以看到消费者1能力比较强处理的消息比较多,消费者2能力比较差处理的消息比较少。
3.2.5.总结
Work模型的使用:
- 多个消费者绑定到一个队列,同一条消息只会被一个消费者处理
- 通过设置prefetch来控制消费者预取的消息数量
3.3.发布/订阅
问题:简单模式和工作模式发送的消息只能被一个消费者消费,因为一旦消费完就会从队列中删除,这样就无法满足课程开始提出的需求,当用户支付完成了需要通知订单服务、仓储服务、短信服务,让这3个服务各自去完成自己的业务,也就是说发送的这条用户支付成功的消息要被3个服务都接收到。
解决:发布、订阅模型,由交换机来决定将消息发送给几个队列,到底是发送给一个还是多个具体由交换机的类型来决定的。
发布订阅的模型如图:
可以看到,在订阅模型中,多了一个exchange角色,而且过程略有变化:
- Publisher:生产者,也就是要发送消息的程序,但是不再发送到队列中,而是发给X(交换机)
- Exchange:交换机,图中的X。一方面,接收生产者发送的消息。另一方面,知道如何处理消息,例如递交给某个特别队列、递交给所有队列、或是将消息丢弃。到底如何操作,取决于Exchange的类型。Exchange有以下3种类型:
- Fanout:广播,将消息交给所有绑定到交换机的队列
- Direct:定向,把消息交给符合指定routing key 的队列
- Topic:通配符,把消息交给符合routing pattern(路由模式) 的队列
- Consumer:消费者,与以前一样,订阅队列,没有变化
- Queue:消息队列也与以前一样,接收消息、缓存消息。
Exchange(交换机)只负责转发消息,不具备存储消息的能力,因此如果没有任何队列与Exchange绑定,或者没有符合路由规则的队列,那么消息会丢失!
3.4.Fanout
Fanout,英文翻译是扇出,我觉得在MQ中叫广播更合适。
Fanout Exchange 会将接收到的消息广播到每一个跟其绑定的queue
在广播模式下,消息发送流程是这样的:
- 1) 可以有多个队列
- 2) 每个队列都要绑定到Exchange(交换机)
- 3) 生产者发送的消息,只能发送到交换机,交换机来决定要发给哪个队列,生产者无法决定
- 4) 交换机把消息发送给绑定过的所有队列
- 5) 订阅队列的消费者都能拿到消息
我们的计划是这样的:
- 创建一个交换机 itcast.fanout,类型是Fanout
- 创建两个队列fanout.queue1和fanout.queue2,绑定到交换机itcast.fanout
3.4.1.基于bean声明队列和交换机
Spring提供了一个接口Exchange,来表示所有不同类型的交换机:
在consumer消费者中创建一个类,声明队列和交换机:
package cn.itcast.mq.config;
import org.springframework.amqp.core.Binding;
import org.springframework.amqp.core.BindingBuilder;
import org.springframework.amqp.core.FanoutExchange;
import org.springframework.amqp.core.Queue;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class FanoutConfig {
/**
* 声明交换机
* @return Fanout类型交换机
*/
@Bean
public FanoutExchange fanoutExchange(){
return new FanoutExchange("itcast.fanout");
}
/**
* 第1个队列
*/
@Bean
public Queue fanoutQueue1(){
return new Queue("fanout.queue1");
}
/**
* 绑定队列和交换机
*/
@Bean
public Binding bindingQueue1(Queue fanoutQueue1, FanoutExchange fanoutExchange){
return BindingBuilder.bind(fanoutQueue1).to(fanoutExchange);
}
/**
* 第2个队列
*/
@Bean
public Queue fanoutQueue2(){
return new Queue("fanout.queue2");
}
/**
* 绑定队列和交换机
*/
@Bean
public Binding bindingQueue2(Queue fanoutQueue2, FanoutExchange fanoutExchange){
return BindingBuilder.bind(fanoutQueue2).to(fanoutExchange);
}
}
3.4.2.消息发送
在publisher服务的SpringAmqpTest类中添加测试方法:
@Test
public void testFanoutExchange() {
// 交换机名称
String exchangeName = "itcast.fanout";
// 消息
String message = "hello, everyone!";
rabbitTemplate.convertAndSend(exchangeName, "", message);
}
3.4.3.消息接收
在consumer服务的SpringRabbitListener中添加两个方法,作为消费者:
@RabbitListener(queues = "fanout.queue1")
public void listenFanoutQueue1(String msg) {
System.out.println("消费者1接收到Fanout消息:【" + msg + "】");
}
@RabbitListener(queues = "fanout.queue2")
public void listenFanoutQueue2(String msg) {
System.out.println("消费者2接收到Fanout消息:【" + msg + "】");
}
运行消费者主启动类,启动生产者测试类。
3.4.4.总结
交换机的作用是什么?
- 接收publisher发送的消息
- 将消息按照规则路由到与之绑定的队列
- 不能缓存消息,路由失败,消息丢失
- FanoutExchange的会将消息路由到每个绑定的队列
声明队列、交换机、绑定关系的Bean是什么?
- Queue
- FanoutExchange
- Binding
3.5.Direct
在Fanout模式中,一条消息,会被所有订阅的队列都消费。但是,在某些场景下,我们希望不同的消息被不同的队列消费。这时就要用到Direct类型的Exchange。
在Direct模型下:
- 队列与交换机的绑定,不能是任意绑定了,而是要指定一个
RoutingKey
(路由key) - 消息的发送方在 向 Exchange发送消息时,也必须指定消息的
RoutingKey
。 - Exchange不再把消息交给每一个绑定的队列,而是根据消息的
Routing Key
进行判断,只有队列的Routingkey
与消息的Routing key
完全一致,才会接收到消息
案例需求如下:
-
利用@RabbitListener声明Exchange、Queue、RoutingKey
-
在consumer服务中,编写两个消费者方法,分别监听direct.queue1和direct.queue2
-
在publisher中编写测试方法,向itcast. direct发送消息
3.5.1.基于注解声明队列和交换机
基于@Bean的方式声明队列和交换机比较麻烦,Spring还提供了基于注解方式来声明。
在consumer消费者的SpringRabbitListener中添加两个消费者,同时基于注解来声明队列和交换机:
@RabbitListener(bindings = @QueueBinding(
value = @Queue(name = "direct.queue1"), //队列
exchange = @Exchange(name = "itcast.direct", type = ExchangeTypes.DIRECT), //交换机 交换机类型默认就是DIRECT定向类型
key = {"red", "blue"} //绑定key,一个队列和交换机进行绑定的时候可以声明多个key
))
public void listenDirectQueue1(String msg){
System.out.println("消费者接收到direct.queue1的消息:【" + msg + "】");
}
@RabbitListener(bindings = @QueueBinding(
value = @Queue(name = "direct.queue2"),
exchange = @Exchange(name = "itcast.direct", type = ExchangeTypes.DIRECT),
key = {"red", "yellow"}
))
public void listenDirectQueue2(String msg){
System.out.println("消费者接收到direct.queue2的消息:【" + msg + "】");
}
3.5.2.消息发送
在publisher服务的SpringAmqpTest类中添加测试方法:
@Test
public void testSendDirectExchange() {
// 交换机名称
String exchangeName = "itcast.direct";
// 消息
String message = "红色警报!日本乱排核废水,导致海洋生物变异,惊现哥斯拉!";
// 发送消息
rabbitTemplate.convertAndSend(exchangeName, "red", message);
}
绑定key为red时,2个消费者都接收到了消息
绑定key为blue时,消费者1接收到了消息
绑定key为yellow时,消费者2接收到了消息
3.5.3.总结
描述下Direct交换机与Fanout交换机的差异?
- Fanout交换机将消息路由给每一个与之绑定的队列
- Direct交换机根据RoutingKey判断路由给哪个队列
- 如果多个队列具有相同的RoutingKey,则与Fanout功能类似
基于@RabbitListener注解声明队列和交换机有哪些常见注解?
- @QueueBinding
- @Queue
- @Exchange
3.6.Topic
3.6.1.说明
Topic
类型的Exchange
与Direct
相比,都是可以根据RoutingKey
把消息路由到不同的队列。只不过Topic
类型Exchange
可以让队列在绑定Routing key
的时候使用通配符!
好处:有多个绑定key时,写起来更方便。
Routingkey
一般都是有一个或多个单词组成,多个单词之间以”.”分割,例如: item.insert
通配符规则:
#
:匹配一个或多个词
*
:匹配不多不少恰好1个词
举例:
item.#
:能够匹配item.spu.insert
或者 item.spu
item.*
:只能匹配item.spu
图示:
解释:
- Queue1:绑定的是
china.#
,因此凡是以china.
开头的routing key
都会被匹配到。包括china.news和china.weather - Queue2:绑定的是
#.news
,因此凡是以.news
结尾的routing key
都会被匹配。包括china.news和japan.news
案例需求:
实现思路如下:
-
并利用@RabbitListener声明Exchange、Queue、RoutingKey
-
在consumer服务中,编写两个消费者方法,分别监听topic.queue1和topic.queue2
-
在publisher中编写测试方法,向itcast. topic发送消息
3.6.2.消息发送
在publisher服务的SpringAmqpTest类中添加测试方法:
/**
* topicExchange
*/
@Test
public void testSendTopicExchange() {
// 交换机名称
String exchangeName = "itcast.topic";
// 消息
String message = "喜报!孙悟空大战哥斯拉,胜!";
// 发送消息
rabbitTemplate.convertAndSend(exchangeName, "china.news", message);
}
3.6.3.消息接收
在consumer服务的SpringRabbitListener中添加方法:
@RabbitListener(bindings = @QueueBinding(
value = @Queue(name = "topic.queue1"),
exchange = @Exchange(name = "itcast.topic", type = ExchangeTypes.TOPIC),
key = "china.#"
))
public void listenTopicQueue1(String msg){
System.out.println("消费者接收到topic.queue1的消息:【" + msg + "】");
}
@RabbitListener(bindings = @QueueBinding(
value = @Queue(name = "topic.queue2"),
exchange = @Exchange(name = "itcast.topic", type = ExchangeTypes.TOPIC),
key = "#.news"
))
public void listenTopicQueue2(String msg){
System.out.println("消费者接收到topic.queue2的消息:【" + msg + "】");
}
运行消费者主启动类,启动生产者测试类。
绑定关系为china.news
,2个消费者都符合绑定规则,所以都可以接收到消息。
3.6.4.总结
描述下Direct交换机与Topic交换机的差异?
- Topic交换机接收的消息RoutingKey必须是多个单词,以
**.**
分割 - Topic交换机与队列绑定时的bindingKey可以指定通配符
#
:代表0个或多个词*
:代表1个词
3.7.消息转换器
之前说过,Spring会把你发送的消息序列化为字节发送给MQ,接收消息的时候,还会把字节反序列化为Java对象。
只不过,默认情况下Spring采用的序列化方式是JDK序列化。众所周知,JDK序列化存在下列问题:
- 数据体积过大
- 有安全漏洞
- 可读性差
我们来测试一下。
说明:在SpringAMQP的发送方法中,接收消息的类型是Object,也就是说我们可以发送任意对象类型的消息,SpringAMQP会帮我们序列化为字节后发送。
我们在consumer中利用@Bean声明一个队列:
@Bean
public Queue objectQueue(){
return new Queue("object.queue");
}
3.7.1.测试默认转换器
我们修改消息发送的代码,发送一个Map对象:
@Test
public void testSendMap() throws InterruptedException {
// 准备消息
Map<String,Object> msg = new HashMap<>();
msg.put("name", "Jack");
msg.put("age", 21);
// 发送消息
rabbitTemplate.convertAndSend("object.queue",msg);
}
停止consumer服务
发送消息后查看控制台:
3.7.2.配置JSON转换器
显然,JDK序列化方式并不合适。我们希望消息体的体积更小、可读性更高,因此可以使用JSON方式来做序列化和反序列化。
在publisher和consumer两个服务中都引入依赖:直接在父工程引入即可
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-xml</artifactId>
<version>2.9.10</version>
</dependency>
配置消息转换器。
在启动类中添加一个Bean即可:主启动类也是一个配置类
@Bean
public MessageConverter jsonMessageConverter(){
return new Jackson2JsonMessageConverter();
}
删除掉队列中的消息,重新发送。
我们在consumer服务定义MessageConverter:
@Bean
public MessageConverter jsonMessageConverter(){
return new Jackson2JsonMessageConverter();
}
然后定义一个消费者,监听object.queue队列并消费消息:
@RabbitListener(queues = "object.queue")
public void listenObjectQueue(Map<String, Object> msg){
System.out.println("接收到object.queue的消息:【" + msg + "】");
}
运行生产者、消费者主启动类,启动生产者测试类,查看消费者控制台。
3.7.3.总结
SpringAMQP中消息的序列化和反序列化是怎么实现的?
- 利用MessageConverter实现的,默认是JDK的序列化
- 注意发送方与接收方必须使用相同的MessageConverter