MQ引言
1、什么是MQ
MQ(Message Quene)：翻译为 消息队列 ，通过典型的生产者和消费者模型，生产者不断向消息队列中生产消息，消费者不断的从队列中获取消息。因为消息的生产和消费都是异步的，而且只关心消息的发送和接收，没有业务逻辑的侵入，轻松的实现系统间解耦。别名为 消息中间件 通过利用高效可靠的消息传递机制进行平台无关的数据交流，并 基于数据通信来进行分布式系统的集成
2、MQ有哪些
当今市面上有很多主流的消息中间件
如老牌的ActiveMQ、RabbitNQ，炙手可热的Kafka，阿里巴巴自主开发的RocketMQ等
3、不同MQ特点
ActiveMQ
ActiveMQ是Apache出品，最流行的，能力强劲的开源消息总线。是一个完全支持JNS（Java Message Service）规范的的消息中间件。丰富的API，多种集群架构模式让ActiveMQ在业界成为老牌的消息中间件，在中小型企业颇受欢迎！
Kafka
Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache顶级项目。Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。8.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务
RocketMQ
RocketNQ是阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。
RabbitMQ
RabbitNQ是使用Erlang语言开发的开源消息队列系统，基于AMQP（Advanced Message Queuing Protocol）协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅)、可靠性、安全。AMQP协议更多用在企业系统内对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。
RabbitMQ比Kafka可靠，Kafka更适合IO高吞吐的处理
一般应用在大数据日志处理或对实时性(少量延迟)，可靠性〈少量丢数据）要求稍低的场景使用，比如ELK日志收集
RabbitMQ引言
1、RabbitMQ的架构与基础概念
基于AMQP协议，Erlang语言开发，是部署最广泛的开源消息中间件，也是最受欢迎的消息中间件之一
Producer：消息生产者，即生产方客户端，生产方客户端将消息发送
Consumer：消息消费者，即消费方客户端，接收MQ转发的消息
Queue：消息队列，存储消息的队列，消息到达队列并转发给指定的
Exchange：消息队列交换机，按一定的规则将消息路由转发到某个队列，对消息进行过滤
Routing Key：路由关键字，交换机根据这个关键字进行消息投递
Virtual Host：虚拟主机，一个broker里可以有多个Virtual Host，用作不同用户的权限分离
ConnectionFactory、Connection、Channel
ConnectionFactory、Connection、Channel都是 RabbitMQ 对外提供的 API 中最基本的对象
Connection 是RabbitMQ的 socket 链接，它封装了 socket 协议相关部分逻辑
ConnectionFactory为 Connection 的制造工厂
Channel是我们与 RabbitMQ 打交道的最重要的一个接口，我们大部分的业务操作是在 Channel 这个接口中完成的，包括定义Queue、定义Exchange、绑定Queue与Exchange、发布消息等
2、RabbitMQ生产消费消息流程
生产者发送消息流程：
- 生产者和Broker建立TCP连接。
- 生产者和Broker建立通道。
- 生产者通过通道消息发送给Broker，由Exchange将消息进行转发。
- Exchange将消息转发到指定的Queue（队列）
消费者接收消息流程：
- 消费者和Broker建立TCP连接
- 消费者和Broker建立通道
- 消费者监听指定的Queue（队列）
- 当有消息到达Queue时Broker默认将消息推送给消费者
- 消费者接收到消息
- ack回复
3、RabbitMQ的安装
普通安装（参照官网）：https://www.rabbitmq.com/download.html
基于Docker
[root@dinosaur ~]# docker pull rabbitmq:management
RabbitMQ配置
1、RabbitMQ管理命令行
# 服务启动相关
systemctl start|restart|stop|status rabbitmq-server
# 管理命令行 用来在不使用web管理界面情况下命令操作RabbitMQ
rabbitmqctl help 可以查看更多命令
# 插件管理命令行
rabbitmq-plugins enable|list|disable
2、web管理界面介绍
RabbitMQ的消息模型开发
1、AMQP协议的回顾
2、RabbitMQ支持的消息模型
3、引入依赖
<dependency>
<groupId>com.rabbitmq</groupId>
<artifactId>amqp-client</artifactId>
<version>5.7.2</version>
</dependency>
4、第一种模型（Hello World）
在上图的模型中，有以下概念：
- P：生产者，也就是要发送消息的程序
- C：消费者，消息的接收者，会一直等待消息到来
- queue：消息队列，图中红色部分。类似于一个邮箱，可以缓存消息；生产者向其中投递消息，消费者取消息
开发生产者
@Test
public void testSendMessage() throws Exception {
//创建连接MQ的连接工厂对象
ConnectionFactory factory = new ConnectionFactory();
//设置连接RabbitMQ主机
factory.setHost("47.104.171.69");
//设置端口号
factory.setPort(5672);
//设置连接那个虚拟主机
factory.setVirtualHost("/dinosaur");
//设置访问虚拟主机的用户名和密码
factory.setUsername("dinosaur");
factory.setPassword("dinosaur");
//获取连接对象
Connection connection = factory.newConnection();
//获取连接中的通道
Channel channel = connection.createChannel();
//通道绑定对应消息队列
//参数一:队列名称，不存在则自动创建
//参数二:用来定义队列特性是否需要持久化，即不会在磁盘中进行队列的保存，但消息会丢失，true为持久化
//参数三:是否独占队列，即只被当前连接所绑定，true为独占
//参数四:是否在消费完成后（消费者与队列彻底断开连接）自动删除队列，true为自动删除
//参数五:额外附加参数
channel.queueDeclare("hello",false,false,false,null);
//发布消息
//参数一:交换机名称
//参数二:队列名称
//参数三:传递消息额外设置 例：MessageProperties.PERSISTENT_TEXT_PLAIN 消息持久化
//参数四:消息具体内容
channel.basicPublish("","hello",null,"hello rabbitMQ".getBytes());
//关闭通道与连接
channel.close();
connection.close();
}
开发消费者
public static void main(String[] args) throws Exception {
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("47.104.171.69");
factory.setPort(5672);
factory.setVirtualHost("/dinosaur");
factory.setUsername("dinosaur");
factory.setPassword("dinosaur");
Connection connection = factory.newConnection();
Channel channel = connection.createChannel();
channel.queueDeclare("hello",false,false,false,null);
//消费消息
//参数一:消费哪个队列的信息
//参数二:开启消息的自动确认机制，消费者自动向rabbitmq确认消息消费了
//参数三:消费时的回调接口
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) = " + new String(body));
}
});
//不关闭通道与连接会一直异步消费消息
//channel.close();
//connection.close();
}
//new String(body) = hello rabbitMQ
封装连接工具类
public class ConnectionUtils {
public static ConnectionFactory factory;
static {
factory = new ConnectionFactory();
factory.setHost("47.102.171.69");
factory.setPort(5672);
factory.setVirtualHost("/dinosaur");
factory.setUsername("dinosaur");
factory.setPassword("dinosaur");
}
//定义提供连接对象的方法
public static Connection getConnection() {
try {
return factory.newConnection();
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
//提供释放通道与连接的方法
public static void closeConnectionAndChannel(Channel channel,Connection connection) {
try {
if (channel != null) channel.close();
if (connection != null) connection.close();
} catch (Exception e) {
e.printStackTrace();
}
}
}
5、第二种模型（Work Queue）
Work Queues，也被称为 Task Queues，任务模型。当消息处理比较耗时的时候，可能生产消息的速度会远远大于消息的消费速度。长此以往，消息就会堆积越来越多，无法及时处理。此时就可以使用work模型：让多个消费者绑定到一个队列，共同消费队列中的消息。队列中的消息一旦消费，就会消失，因此任务是不会被重复执行的
角色：
- P：生产者，任务的发布者
- C1：消费者1，领取任务并且完成任务，假设完成速度较慢
- C2：消费者2，领取任务并且完成任务，假设完成速度较快
开发生产者
public static void main(String[] args) throws Exception {
Connection connection = ConnectionUtils.getConnection();
Channel channel = connection.createChannel();
channel.queueDeclare("work", true, false, false, null);
for (int i = 0; i < 10; i++)
channel.basicPublish("","work",null,(i + "hello work queue").getBytes());
ConnectionUtils.closeConnectionAndChannel(channel,connection);
}
开发消费者
多个消费者之间代码相同
public class Consumer1 {
public static void main(String[] args) throws Exception {
Connection connection = ConnectionUtils.getConnection();
Channel channel = connection.createChannel();
channel.queueDeclare("work", true, false, false, null);
channel.basicConsume("work",true, new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
System.out.println("Consumer1 : " + new String(body));
}
});
}
}
测试结果
//消费者1控制台输出
Consumer1 : 0 hello work queue
Consumer1 : 2 hello work queue
Consumer1 : 4 hello work queue
Consumer1 : 6 hello work queue
Consumer1 : 8 hello work queue
//消费者2控制台输出
Consumer2 : 1 hello work queue
Consumer2 : 3 hello work queue
Consumer2 : 5 hello work queue
Consumer2 : 7 hello work queue
Consumer2 : 9 hello work queue
总结：默认情况下，RabbitMQ将按顺序将每个消息发送给下个消费者
平均而言，每一个消费者都会收到相同数量的消息，这种分发消息的方式称为循环
消息自动确认机制
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.
But we don’t want to lose any tasks. If a worker dies, we’d like the task to be delivered to another worker.
完成一项任务可能需要几秒钟。您可能想知道，如果其中一个使用者开始一项漫长的任务并仅部分完成而死掉，会发生什么情况。使用我们当前的代码，RabbitMQ一旦向消费者传递了一条消息，便立即将其标记为删除。在这种情况下，如果您杀死一个工人，我们将丢失正在处理的消息。我们还将丢失所有发送给该特定工作人员但尚未处理的消息
但是我们不想丢失任何任务。如果一个工人死亡，我们希望将任务交付给另一个工人
消息确认
- 为了保证数据不被丢失，RabbitMQ支持消息确认机制，为了保证数据能被正确处理而不仅仅是被Consumer收到，那么我们不能采用no-ack，而应该是在处理完数据之后发送ack
- 在处理完数据之后发送ack，就是告诉RabbitMQ数据已经被接收，处理完成，RabbitMQ可以安全的删除它了
- 如果Consumer退出了但是没有发送ack，那么RabbitMQ就会把这个Message发送到下一个Consumer，这样就保证在Consumer异常退出情况下数据也不会丢失
- RabbitMQ它没有用到超时机制，RabbitMQ仅仅通过Consumer的连接中断来确认该Message并没有正确处理，也就是说RabbitMQ给了Consumer足够长的时间做数据处理
- 如果忘记ack，那么当Consumer退出时，Mesage会重新分发，然后RabbitMQ会占用越来越多的内存
修改消费者
channel.basicQos(1); //一次只接受一条违背确认的消息
//参数2：关闭消息的自动确认机制
channel.basicConsume("work",true, new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws
IOException {
System.out.println("Consumer1 : " + new String(body));
//参数一:确认消息队列中那个消息 参数二:是否开启多个消息同时确认 ，确认后队列中才会删除消息
channel.basicAck(envelope.getDeliveryTag(),false);
}
});
6、第三种模型（Fanout）
fanout：扇出，也称为广播
在广播模式下，消息发送流程是这样的
- 可以有多个消费者
- 每个消费者有自己的queue（队列）
- 每个队列都要绑定到exchange（交换机）
- 生产者发送的消息，只能发送到交换机，交换机来决定发送到那个队列，生产者无法决定
- 交换机把消息发送给绑定过的所有队列
- 队列的消费者都能拿到消息。实现一条消息被多个消费者消费
开发生产者
//将通道声明指定的交换机
//参数一:交换机的名称 参数二:交换机的类型
channel.exchangeDeclare("logs","fanout");
//发送消息
channel.basicPublish("logs","",null,"fanout type message".getBytes());
开发消费者
多个消费者代码相同
//通道绑定指定交换机
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("consumer1 : " + new String(body));
}
});
测试结果
//Consumer1控制台
consumer1 : fanout type message
//Consumer2控制台
consumer2 : fanout type message
可以看到消息被交换机广播，多个消费者都消费到了消息
7、第四种模型（Routing）
Routing之订阅模型—Direct
在Fanout模式中，一条消息，会被所有订阅的队列都消费
但是，在某些场景下，我们希望不同的消息被不同的队列消费。这时就要用到Direct类型的Exchange
在Direct模型下：
- 队列与交换机的绑定，不能是任意绑定了，而是要指定一个
Routing Key（路由key） - 消息的发送方在向Exchange发送消息时，必须指定消息的
Routing Key - Exchange不再把消息交给每一个绑定的队列，而是根据消息的
Routing Key进行判断，只有队列的Routing key与消息的Routing key完全一致，才会接收到消息
图解：
- P：生产者，向Exchange发送消息，发送消息时会指定一个Routing Key
- X：Exchange交换机，接收生产者的消息，然后把消息传递给与Routing Key完全匹配的队列
- C1：消费者，其所在队列指定了需要Routing Key为error的消息
- C2：消费者，其所在队列指定了需要Routing Key为info、error、warning的消息
开发生产者
//通过通道声明交换机 参数一:交换机名称 参数二:direct 路由模式
channel.exchangeDeclare("logs_direct","direct");
String routingKey = "info";
//发送消息
channel.basicPublish("logs_direct",routingKey,null,("这是direct模型发布的基于路由key" + routingKey + "发送的消息").getBytes());
开发消费者
消费者1：绑定error相关的路由Routing Key
public static void main(String[] args) throws Exception {
Connection connection = ConnectionUtils.getConnection();
Channel channel = connection.createChannel();
//通道绑定交换价以及交换机的类型
channel.exchangeDeclare("logs_direct", "direct");
//创建一个临时队列
String queue = channel.queueDeclare().getQueue();
//基于路由key去绑定队列和交换机
channel.queueBind(queue, "logs_direct", "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("Consumer 1 : " + new String(body));
}
});
}
消费者2：绑定error、info、warning相关的路由Routing Key
public static void main(String[] args) throws Exception {
Connection connection = ConnectionUtils.getConnection();
Channel channel = connection.createChannel();
//通道绑定交换价以及交换机的类型
channel.exchangeDeclare("logs_direct", "direct");
//创建一个临时队列
String queue = channel.queueDeclare().getQueue();
//基于路由key去绑定队列和交换机
channel.queueBind(queue, "logs_direct", "error");
channel.queueBind(queue, "logs_direct", "info");
channel.queueBind(queue, "logs_direct", "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("Consumer 2 : " + new String(body));
}
});
}
测试结果
测试生产者Provider发送Routing Key为info的信息时
//Consumer1控制台打印为空
//Consumer2控制台打印
Consumer 2 : 这是direct模型发布的基于路由keyinfo发送的消息
说明Consumer2收到了Routing Key为info的消息，而Consumer1没有
测试生产者Provider发送Routing Key为error的信息时
//Consumer1控制台打印为空
Consumer 1 : 这是direct模型发布的基于路由keyerror发送的消息
//Consumer2控制台打印
Consumer 2 : 这是direct模型发布的基于路由keyerror发送的消息
说明Consumer1，Consumer2同时收到了Routing Key为error的消息
Routing之订阅模型—Topic
Topic类型的 Exchange 与 Direct 相比，都是可以根据 Routing Key 把消息路由到不同的队列。只不过 Topic 类型Exchange可以让队列在绑定 Routing key 的时候使用通配符！这种模型 Routingkey 一般都是由一个或多个单词组成，多个单词之间以 " . " 分割，例如：item.insert
通配符
* （star） can substitute for exactly one word 匹配不多不少恰好一个词
# （star） can substitute for exactly one word 匹配一个或多个词
如
audit.# 可以匹配audit.irs.asdf 或者 audit.irs 等
audit.* 只能匹配audit.irs
开发生产者
public static void main(String[] args) throws Exception {
Connection connection = ConnectionUtils.getConnection();
Channel channel = connection.createChannel();
channel.exchangeDeclare("topics","topic");
String routingKey = "user.save";
channel.basicPublish("topics",routingKey,null,("这里是topic动态路由模型，Routing Key : " + routingKey).getBytes());
ConnectionUtils.closeConnectionAndChannel(channel,connection);
}
开发消费者
消费者1：绑定 user.* 相关的路由Routing Key
public static void main(String[] args) throws Exception {
Connection connection = ConnectionUtils.getConnection();
Channel channel = connection.createChannel();
channel.exchangeDeclare("topics","topic");
//创建一个临时队列
String queue = channel.queueDeclare().getQueue();
//基于路由key去绑定队列和交换机
channel.queueBind(queue, "topics", "user.*");
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("Consumer 1 : " + new String(body));
}
});
}
消费者2：绑定 user.# 相关的路由Routing Key
public static void main(String[] args) throws Exception {
Connection connection = ConnectionUtils.getConnection();
Channel channel = connection.createChannel();
channel.exchangeDeclare("topics","topic");
//创建一个临时队列
String queue = channel.queueDeclare().getQueue();
//基于路由key去绑定队列和交换机
channel.queueBind(queue, "topics", "user.#");
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("Consumer 2 : " + new String(body));
}
});
}
测试结果
测试生产者Provider发送Routing Key为user.save的信息时
//Consumer1控制台打印
Consumer 1 : 这里是topic动态路由模型，Routing Key : user.save
//Consumer2控制台打印
Consumer 2 : 这里是topic动态路由模型，Routing Key : user.save
说明Consumer1，Consumer2同时收到了Routing Key为user.save的消息
测试生产者Provider发送Routing Key为user.save.all的信息时
//Consumer1控制台打印为空
//Consumer2控制台打印
Consumer 2 : 这里是topic动态路由模型，Routing Key : user.save.all
说明Consumer1不匹配Routeing Key为user.save.all的消息，Consumer2收到了Routing Key为user.save.all的消息
8、第六种模型（RPC）
RPC模式：
RPC即客户端远程调用服务端的方法 ，使用MQ可以实现RPC的异步调用，基于Direct交换机实现，流程如下：
1、客户端即是生产者就是消费者，向RPC请求队列发送RPC调用消息，同时监听RPC响应队列。
2、服务端监听RPC请求队列的消息，收到消息后执行服务端的方法，得到方法返回的结果
3、服务端将RPC方法 的结果发送到RPC响应队列
4、客户端（RPC调用方）监听RPC响应队列，接收到RPC调用结果。
9.总结
RabbitMQ提供了6种模式，分别是 HelloWorld，Work Queue，Publish/Subscribe，Routing，Topics，RPC Request/reply，本文详细讲述了前5种，并给出代码实现和思路。其中Publish/Subscribe，Routing，Topics三种模式可以统一归为 Exchange 模式，只是创建时交换机的类型不一样，分别是 fanout、direct、topic
SpringBoot整合RabbitMQ使用
1、搭建依赖环境
引入依赖环境
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-amqp</artifactId>
</dependency>
YML配置文件
spring:
application:
name: springboot_rabbitmq
rabbitmq:
host: 47.104.171.69
port: 5672
username: dinosaur
password: dinosaur
virtual-host: /dinosaur
SpringBoot提供了一个 RabbitMessagingTemplate 用来简化操作 使用的时候直接在项目注入即可使用
2、第一种Hello world模型使用
开发生产者
@SpringBootTest //springboot test
public class TestRabbitMQ {
@Resource //注入模板对象
private RabbitMessagingTemplate template;
@Test
public void test() {
//底层会把消息转换成byte[]，这里发一个对象即可
template.convertAndSend("hello","hello world");
}
}
开发消费者
@Component //注入到容器中
@RabbitListener(queuesToDeclare = @Queue("hello")) //Rabbitmq的一个消费者，接收生产者hello队列的消息
public class HelloConsumer {
@RabbitHandler //代表日后帮我们从消息队列中取出消息时的回调方法
public void receive1(String message) {
System.out.println("message = " + message);
}
}
测试结果
3、第二种Work Queue模型使用
开发生产者
@Test
public void testWorkQueue() {
for (int i = 0; i < 10; i++)
template.convertAndSend("work","work model");
}
开发消费者
@Component
public class WorkConsumer {
@RabbitListener(queuesToDeclare = @Queue("work"))
public void receive1(String message) {
System.out.println("message1 = " + message);
}
@RabbitListener(queuesToDeclare = @Queue("work"))
public void receive2(String message) {
System.out.println("message2 = " + message);
}
}
测试结果
运行我们的生产者方法，查看控制台输出
message2 = work model
message1 = work model
message2 = work model
message1 = work model
message2 = work model
message1 = work model
message2 = work model
message1 = work model
message2 = work model
message1 = work model
默认Spring AMQP实现中Work Queue为公平调度，如果需要实现能者多劳则要额外配置
4、第三种Fanout模型使用
开发生产者
@Test
public void testFanout() {
template.convertAndSend("logs", "", "fanout model");
}
开发消费者
@Component
public class FanoutConsumer {
@RabbitListener(bindings = {
@QueueBinding(
value = @Queue, //创建临时队列
exchange = @Exchange(value = "logs",type = "fanout") //绑定交换机
)
})
public void receive1(String message) {
System.out.println("message1 = " + message);
}
@RabbitListener(bindings = {
@QueueBinding(
value = @Queue, //创建临时队列
exchange = @Exchange(value = "logs",type = "fanout") //绑定交换机
)
})
public void receive2(String message) {
System.out.println("message2 = " + message);
}
}
测试结果
运行我们的生产者方法，查看控制台输出
message2 = fanout model
message1 = fanout model
5、第四种模型Route的使用
开发生产者
@Test
public void testRoute() { //参数二为路由key
template.convertAndSend("directs", "info", "发送的info的路由key信息");
}
开发消费者
@Component
public class RouteConsumer {
@RabbitListener(bindings = {
@QueueBinding(
value = @Queue,
exchange = @Exchange(value = "directs",type = "direct"), //指定交换机名称和类型
key = {
"info","error","warning" //监听路由key为error、info、warning的路由
}
)
})
public void receiver1(String message) {
System.out.println("message1 = " + message);
}
@RabbitListener(bindings = {
@QueueBinding(
value = @Queue,
exchange = @Exchange(value = "directs",type = "direct"), //指定交换机名称和类型
key = {
"error" //监听路由key为error的路由
}
)
})
public void receiver2(String message) {
System.out.println("message2 = " + message);
}
}
测试结果
运行我们的生产者方法，先发送路由key为info的信息，在发送路由key为error的信息查看控制台输出
//路由key为info
message1 = 发送的info的路由key信息
//路由key为error
message1 = 发送的info的路由error信息
message2 = 发送的info的路由error信息
6、第五种Topic模型使用
开发生产者
@Test
public void testTopic() {
template.convertAndSend("topics", "user.save", "发送的user.save的路由key信息");
}
开发消费者
@Component
public class TopicConsumer {
@RabbitListener(bindings = {
@QueueBinding(
value = @Queue,
exchange = @Exchange(type = "topic",name = "topics"),
key = {
"user.*"
}
)
})
public void receiver1(String message) {
System.out.println("message2 = " + message);
}
@RabbitListener(bindings = {
@QueueBinding(
value = @Queue,
exchange = @Exchange(type = "topic",name = "topics"),
key = {
"order.#","user.#"
}
)
})
public void receiver2(String message) {
System.out.println("message2 = " + message);
}
}
测试结果
运行我们的生产者方法，先发送路由key为user.save的信息，在发送路由key为user.all.list的信息查看控制台输出
//路由key为user.save的信息
message2 = 发送的user.save的路由key信息
message2 = 发送的user.save的路由key信息
//路由key为user.all.list的信息
message2 = 发送的user.all.list的路由key信息
MQ的应用场景
1、异步处理
场景说明：用户注册后，需要发注册邮件和注册短信,传统的做法有两种 1.串行的方式 2.并行的方式
串行方式：将注册信息写入数据库后，发送注册邮件，再发送注册短信，以上三个任务全部完成后才返回给客户端。 这有一个问题是：邮件,短信并不是必须的，它只是一个通知，而这种做法让客户端等待没有必要等待的东西
并行方式：将注册信息写入数据库后，发送邮件的同时，发送短信，以上三个任务完成后，返回给客户端，并行的方式能提高处理的时间
-
消息队列： 假设三个业务节点分别使用50ms，串行方式使用时间150ms，并行使用时间100ms。虽然并性已经提高的处理时间，但是前面说过，邮件和短信对我正常的使用网站没有任何影响，客户端没有必要等着其发送完成才显示注册成功，应该是写入数据库后就返回引入消息队列后，把发送邮件，短信不是必须的业务逻辑异步处理
由此可以看出，引入消息队列后，用户的响应时间就等于写入数据库的时间 + 写入消息队列的时间(可以忽略不计)，引入消息队列后处理后，响应时间是串行的3倍，是并行的2倍
2、应用解耦
场景：双11是购物狂节，用户下单后，订单系统需要通知库存系统，传统的做法就是订单系统调用库存系统的接口
这种做法有缺点，当库存系统出现故障时，订单就会失败 | 订单系统和库存系统高耦合
引入消息队列
订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功库存系统：订阅下单的消息，获取下单消息，进行库操作。就算库存系统出现故障，消息队列也能保证消息的可靠投递不会导致消息丢失
3、流量消峰
场景：秒杀活动，一般会因为流量过大，导致应用挂掉、为了解决这个问题，一般在应用前端加入消息队列。
作用
- 可以控制活动人数，超过此一定阀值的订单直接丢弃
- 可以缓解短时间的高流量压垮应用(应用程序按自己的最大处理能力获取订单)
- 用户的请求服务器收到后,先写入消息队列，加入消息队列长度超过最大值，则直接抛弃用户请求或跳转到错误页面
- 秒杀业务根据消息队列中的请求信息，再做后续处理
RabbitMQ的集群
1、普通集群（副本集群）
What is Replicated? ——摘自官网
All data/state required for the operation of a RabbitMQ broker is replicated across all nodes. An exception to this are message queues, which by default reside on one node, though they are visible and reachable from all nodes. To replicate queues across nodes in a cluster, use a queue type that supports replication. This topic is covered in the Quorum Queuesand Classic Mirrored Queues guides.
默认情况下：RabbitMQ代理操作所需的所有数据/状态都将跨所有节点复制
这方面的一个例外是消息队列，默认情况下消息队列位于一个节点上，尽管它们可以从所有的节点看到和访问
说明
它是默认的集群模式，Queue创建之后，如果没有其它策略，则queue就会按照普通模式集群
对于Queue来说，消息实体只存在于其中一个节点，A、B两个节点仅有相同的元数据，即队列结构，但队列的元数据仅保存有一份，即创建该队列的rabbitmq节点（A节点），当A节点宕机，你可以去其B节点查看就会发现该队列已经丢失，但声明的exchange还存在
当消息进入A节点的Queue中后，consumer从B节点拉取时，RabbitMQ会临时在A、B间进行消息传输，把A中的消息实体取出并经过B发送给consumer，所以consumer应平均连接每一个节点，从中取消息
该模式存在一个问题就是当A节点故障后，B节点无法取到A节点中还未消费的消息实体。如果做了队列持久化或消息持久化，那么得等A节点恢复，然后才可被消费，并且在A节点恢复之前其它节点不能再创建A节点已经创建过的持久队列；如果没有持久化的话，消息就会丢失。这种模式更适合非持久化队列，只有该队列是非持久的，客户端才能重新连接到集群里的其他节点，并重新创建队列。假如该队列是持久化的，那么唯一办法是将故障节点恢复起来
为什么RabbitMQ不将队列复制到集群里每个节点呢？这与它的集群的设计本意相冲突，集群的设计目的就是增加更多节点时，能线性的增加性能（CPU、内存）和容量（内存、磁盘）理由如下
- 存储空间：如果每个集群节点每个队列的一个完整副本，增加节点需要更多的存储容量。例如如果一个节点可以存储1GB的消息，添加两个节点需要两份相同的1GB的消息
- 性能：发布消息需要将这些信息复制到每个集群节点。对持久消息，要求为每条消息触发磁盘活动在所有节点上。每次添加一个节点都会带来网络和磁盘的负载
架构图
核心解决问题：当集群中某一时刻master节点宕机，可以对Queue中的信息进行备份
集群搭建
拉取镜像
[root@dinosaur ~]# docker pull rabbitmq:management
运行容器
[root@dinosaur ~]#docker run -d --hostname rabbit_host1 --name rabbitmq1 -p 15672:15672 -p 5672:5672 -e RABBITMQ_ERLANG_COOKIE='rabbitmq_cookie' rabbitmq:management
[root@dinosaur ~]#docker run -d --hostname rabbit_host2 --name rabbitmq2 -p 5673:5672 --link rabbitmq1:rabbit_host1 -e RABBITMQ_ERLANG_COOKIE='rabbitmq_cookie' rabbitmq:management
[root@dinosaur ~]#docker run -d --hostname rabbit_host3 --name rabbitmq3 -p 5674:5672 --link rabbitmq1:rabbit_host1 --link rabbitmq2:rabbit_host2 -e RABBITMQ_ERLANG_COOKIE='rabbitmq_cookie' rabbitmq:management
主要参数：
-p 15672:15672 management界面管理访问端口
-p 5672:5672 amqp访问端口
–link 容器之间连接
Erlang Cookie 值必须相同，也就是一个集群内 RABBITMQ_ERLANG_COOKIE 参数的值必须相同。因为 RabbitMQ 是用Erlang实现的，Erlang Cookie 相当于不同节点之间通讯的密钥，Erlang节点通过交换 Erlang Cookie 获得认证
加入节点到集群
设置节点1
[root@dinosaur ~]#docker exec -it myrabbit1 bash
[root@dinosaur ~]#rabbitmqctl stop_app
[root@dinosaur ~]#rabbitmqctl reset
[root@dinosaur ~]#rabbitmqctl start_app
[root@dinosaur ~]# #ctrl + p + q 退出
设置节点2，加入到集群
[root@dinosaur ~]#docker exec -it myrabbit2 bash
[root@dinosaur ~]#rabbitmqctl stop_app
[root@dinosaur ~]#rabbitmqctl reset
[root@dinosaur ~]#rabbitmqctl join_cluster --ram rabbit@rabbitmq_host1
[root@dinosaur ~]#rabbitmqctl start_app
[root@dinosaur ~]# #ctrl + p + q 退出
设置节点3，加入到集群
[root@dinosaur ~]#docker exec -it myrabbit3 bash
[root@dinosaur ~]#rabbitmqctl stop_app
[root@dinosaur ~]#rabbitmqctl reset
[root@dinosaur ~]#rabbitmqctl join_cluster --ram rabbit@rabbitmq_host1
[root@dinosaur ~]#rabbitmqctl start_app
[root@dinosaur ~]# #ctrl + p + q 退出
主要参数：–ram 表示设置为内存节点，忽略次参数默认为磁盘节点。该配置启动了3个节点，1磁盘节点和2内存节点
设置好之后，使用 http://ip:15672 进行访问，默认账号密码：guest/guest
可以看到，已经有多个节点了
2、镜像集群
This guide covers mirroring (queue contents replication) of classic queues
What is Queue Mirroring ——摘自官网
By default, contents of a queue within a RabbitMQ cluster are located on a single node (the node on which the queue was declared). This is in contrast to exchanges and bindings, which can always be considered to be on all nodes. Queues can optionally be made mirrored across multiple nodes.
镜像模式是在普通模式的基础上，增加一些镜像策略
镜像队列机制就是将队列在三个节点之间设置主从关系，消息会在三个节点之间进行自动同步
且如果其中一个节点不可用，并不会导致消息丢失或这者服务不可用的情况，提升MQ集群的整体高可用性
说明
该模式解决了上述问题，其实质和普通模式不同之处在于，消息实体会主动在镜像节点间同步，而不是在consumer取数据时临时拉取
该模式带来的副作用也很明显，除了降低系统性能外，若镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用，一个队列想做成镜像队列，需先设置policy，然后客户端创建队列的时候，rabbitmq集群根据“队列名称”自动设置是普通集群模式或镜像队列。
架构图
集群搭建
策略policy概念
使用RabbitMQ镜像功能，需要基于RabbitMQ策略来实现，策略policy是用来控制和修改群集范围的某个vhost队列行为和Exchange行为。策略policy就是要设置哪些Exchange或者queue的数据需要复制、同步，以及如何复制同步
为了使队列成为镜像队列，需要创建一个策略来匹配队列，设置策略有两个键“ha-mode和 ha-params（可选）”。ha-params根据ha-mode设置不同的值，下表说明这些key的选项
添加策略
登录rabbitmq管理页面 ——> Admin ——> Policies ——> Add / update a policy
name：随便取，策略名称
Pattern：^ 匹配符，只有一个^代表匹配所有
Definition：ha-mode=all 为匹配类型，分为3种模式：all（表示所有的queue）
或者使用命令：#rabbitmqctl set_policy ha-all “^” ‘{“ha-mode”:“all”}’
查看效果
此策略会同步所在同一Virtual Host中的交换器和队列数据。设置好policy之后，使用 http://ip:15672 再次进行访问，可以看到队列镜像同步
3、SpringBoot配置RabbitMQ集群
配置RabbitMQ单机
spring:
rabbitmq:
host: localhost
port: 5672
username: username
password: password
或者使用address
spring:
rabbitmq:
addresses: ip1:port1
username: username
password: password
配置RabbitMQ集群
spring:
rabbitmq:
addresses: ip1:port1,ip2:port2,ip3:port3
username: username
password: password
849
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
