一、MQ的相关概念

1.1 什么是MQ

本质是个队列,FIFO先入先出,只不过队列中存放的内容是消息而已,是一种跨进程的通信机制,用于上下游传递消息

1.2 为什么要用MQ

1. 流量消峰
   好处是将多次访问排队进行处理,缺点是排队就会导致时间长.在处理大量请求时,速度慢比崩溃要好

2. 应用解耦
   订单系统调用支付系统和库存系统以及物流系统时如果哪一个系统出故障会导致其他的系统都无法正常使用,但将mq部署上去,让订单系统的消息传递给mq让mq进行分发,即便那个系统奔溃,也会正常的执行其他的系统,mq会不断的给奔溃的系统发送消息,直至成功调用

3. 异步处理
   例如,A调用B的API,B要执行很长一段时间,那么A如果一直等待B执行完,对用户的体验极差.那么这可以用mq来实现,A调用B以后,A可以继续做A自己的事情,B执行完,发消息给MQ,MQ再告诉A,B执行完的结果

1.3 MQ的分类

1.3.1 ActiveMQ

优点:单机吞吐量万级,时效性ms级,可用性高,基于主从架构实现高可用性,消息可靠性较低的概率丢失数据

缺点:官方ActiveMQ 5.x维护越来越少,高吞吐量场景较少使用

1.3.2 Kafka

大数据的杀手锏,为大数据而生的消息中间件

优点:性能卓越单机写入TPS约在百万条/秒,最大的有点就是吞吐量高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用,在大数据领域的实时计算和日志采集

缺点:Kafka单机超过64个队列/分区,Load会发现明显的飙高现象,队列越多,load越高,发送消息响应时间变长,使用短轮询方式,时效性取决于轮询间隔时间,消费失败不支持重试;支持消息顺序但是一台代理宕机后,就会产生消息乱序,社区更新较慢

1.3.3 RocketMQ

RocketMQ出自阿里巴巴的开源产品,用java语言实现,设计时参考Kafka,被阿里巴巴广泛应用在订单,交易,充值,流计算,消息推送,日志流式处理,binglog分发

优点:单机吞吐量十万级可用性非常高,分布式架构,消息可以做到0丢失,MQ功能较为完善,还是分布式的,扩展性好,支持10亿级别的消息堆积,不会因为堆积导致性能下降

缺点:支持的客户端语言不多,目前是java及c++

1.3.4 RabbitMQ

2007年发布,是一个在AMQP(高级信息队列协议)基础上完成的,可复用的企业消息系统,是当前最主流的消息中间件之一

优点:由于erlang语言的高并发特性,性能较好;吞吐量万级,MQ功能比较完备,健壮,稳定,易用,跨平台,支持多种语言,如:Python,Ruby,.NET,Java,JMS,C,PHP,ActionScript,XMPP,STOMP等,支持AJAX文档齐全开源提供的管理界面非常棒,用起来很好用,社区活跃最高;更新频率相当高

缺点:商业版需要收费,学习成本高

二、RabbitMQ

2.1 RabbitMQ的概念

RabbitMQ是一个消息中间件,它接受并转发消息.你可以把它当做一个快递站点,当你要发送一个包裹时,你把你包裹放到快递站,快递员最终会把你的快递送到收件人那里,按照这个逻辑RabbitMQ是一个快递站,一个快递员帮你传递快件.RabbitMQ与快递站的主要区别在于,它不处理快件而是接收存储和转发消息数据

2.2 四大核心概念

1. 生产者
2. 交换机
3. 队列
4. 消费者

2.3 RabbitMQ核心部分

1. Hello World!(简单模式)
2. Work queues(工作模式)
3. Publish/Subscribe(发布订阅模式)
4. Routing(路由模式)
5. Topics(主题模式)
6. Publisher Confirms(发布确认模式)

2.4 RabbitMQ工作原理

Broker:接收和分发消息的应用,RabbitMQ Server就是Message Broker

Virtual host:出于多租户和安全因素设计的,把AMQP的基本组件划分到一个虚拟的分组中,类似于网络中的namespace概念.当多个不同的用户使用同一个RabbitMQ server提供的服务时,可以划分出多个vhost,每个用户在自己的vhost创建 exchange/queue等

Connection: publisher/consumer和broker之间的TCP连接

Channel:如果每一次访问 RabbitMQ都建立了一个Connection,在消息量大的时候建立TCP Connection的开销将巨大的,消息也较低.Channel 是再 connection内部建立的逻辑连接,如果应用程序支持多线程,通常每个thread创建单独的channel进行通讯,AMQP method 包含了 channel id帮助客户端和message broker 识别 channel 之间的完全隔离的.Channel作为轻量级的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的分发依据

安装

添加一个新的用户

创建账号

rabbitmqctl add_user admin 123

设置用户角色

rabbitmqctl set_user_tags admin administrator

设置用户权限

set_permissions [-p <vhostpath>]<user><conf><write><read>
rabbitmqctl set_permissions -p "/" admin ".*" ".*" "."

用户user_admin 具有/vhost1 这个 virtual host中所有资源的配置、写、读权限

当前用户和角色

rabbitmqctl list_users

java环境

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><groupId>com.zjz</groupId><artifactId>rabbitmq-hello</artifactId><version>1.0-SNAPSHOT</version><packaging>jar</packaging><name>rabbitmq-hello</name><url>http://maven.apache.org</url><properties><project.build.sourceEncoding>UTF-8</project.build.sourceEncoding></properties><dependencies><!-- rabbitmq 依赖客户端 --><dependency><groupId>com.rabbitmq</groupId><artifactId>amqp-client</artifactId><version>5.8.0</version></dependency><!-- 操作文件流的一个依赖 --><dependency><groupId>commons-io</groupId><artifactId>commons-io</artifactId><version>2.6</version></dependency></dependencies><build><plugins><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-compiler-plugin</artifactId><configuration><source>8</source><target>8</target></configuration></plugin></plugins></build></project>

2.5 Hello World

生产者代码

package com.zjz.rabbitmq.one;import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;import java.io.IOException;
import java.util.concurrent.TimeoutException;/*** 生产者 : 发消息*/
public class Producer {// 队列名称public static final String QUEUE_NAME = "hello";// 发消息public static void main(String[] args) throws IOException, TimeoutException {// 创建一个连接工厂ConnectionFactory factory = new ConnectionFactory();//工厂IP 连接 RabbitMQ 的队列factory.setHost("192.168.88.132");// 用户名factory.setUsername("admin");// 密码factory.setPassword("123");// 创建连接Connection connection = factory.newConnection();// 获取信道Channel channel = connection.createChannel();/*** 生成一个队列* 1.队列名称* 2.队列里面的消息是否持久化(磁盘),默认情况消息存储在内存中* 3.该队列是否只提供一个消费者进行消费 是否进行消息共享 true可以多个消费者消费 false: 只能一个消费者消费* 4.是否自动删除 最后一个消费者端开连接以后 该队一句是否自动删除 true自动删除 false不自动删除*/channel.queueDeclare(QUEUE_NAME,false,false,false,null);// 发消息String message = "hello world"; //初次使用/*** 发送一个消息* 1.发送到那个交换机* 2.路由的Key值是哪个 本次是队列的名称* 3.其他参数信息* 4.发送消息的消息体*/channel.basicPublish("",QUEUE_NAME,null,message.getBytes());System.out.println("发送消息完毕");}}

消费者代码

package com.zjz.rabbitmq.one;import com.rabbitmq.client.*;import java.io.IOException;
import java.util.concurrent.TimeoutException;/*** 消费者 接收消息的*/
public class Consumer {// 队列的名称public static final String QUEUE_NAME = "hello";// 接收消息public static void main(String[] args) throws IOException, TimeoutException {// 创建连接工厂ConnectionFactory factory = new ConnectionFactory();// 工厂IP 连接 rabbitMQ 队列factory.setHost("192.168.88.132");// 用户名factory.setUsername("admin");// 密码factory.setPassword("123");Connection connection = factory.newConnection();Channel channel = connection.createChannel();// 声明 接受消息DeliverCallback deliverCallback = (consumerTag, message) -> {System.out.println(new String(message.getBody()));};// 取消消息时的回调CancelCallback cancelCallback= consumerTag -> {System.out.println("消息消费被中断");};/*** 消费者消费消息* 1.消费哪个队列* 2.消费成功之后是否要自动应答 true 代表的自动应答 false 代表手动应答* 3.消费者未成功消费的回调* 4.消费者取录消费的回调**/channel.basicConsume(QUEUE_NAME, true,deliverCallback,cancelCallback);}}

2.6 Work Queues

工作队列(又称任务队列)的主要思想是避免立即执行资源密集型任务,而不得不等待它完成.相反我们安排任务在之后执行.我们把任务封装为消息并其发送到队列.在后台运行的工作进程将弹出任务并最终执行作业.当有多个工作线程时,这些工作线程将一起处理这些任务

2.6.1 轮询分发消息

一个消息只能被处理一次,不可以处理多次,多个线程之间的关系是竞争关系

2.7 消息应答

2.7.1 概念

消费者完成一个任务可能需要一段时间,如果其中一个消费者处理一个长的人物并权只完成了部分突然它挂掉了,会发生什么情况.
RabbitMQ 一旦消费者传递了一条消息,便立即将该消息标记为删除.在这种情况下,突然有个消费者挂掉了,我们将失去正在处理的消息.一级后续发送给该消费者的消息,因为它无法接收到

为了保证消息在发送过程中不丢失,rabbitmq引入消息应答机制,消息应答就是:消费者在接收到消息并且处理该消息之后,告诉rabbitmq它已经处理了,rabbitmq可以把该消息删除了

2.7.2 自动应答

消息发送后立即被认为已经传送成功,这种模式需要在高吞吐量和数据传输安全性方面做权衡,因为这种模式如果消息在接收到之前,消费者那边出现连接或者channel关闭,那么消息就丢失了,当然另一方面这种模式消费者那边可以传递过载信息,没有对传递的消息数量进行限制, 使得内存耗尽,最终这些消费者线程被操作系统杀死,所以这种模式仅适用在消费者可以高效并以某种速率能够处理这些消息的情况下使用

2.7.3 消息应答的方法

A.Channel.basicAck(用于肯定确认)
RabbitMQ已知道该消息并且成功的处理消息,可以将其丢弃了

B.Channel.basicNack(用于否定确认)

C.Channel.basicReject(用于否定确认)
于Channel.basicNack相比少一个参数
不处理该消息了直接拒绝,可以将其丢弃了

2.7.4 Multiple的解释

手动应答的好处是可以批量应答并且减少网络拥堵

multiple的true和false表达意思不同

• true代表批量应答channel上未应答的消息
  比如说channel上有传送的tag的消息 5,6,7,8 当前tag是8那么此时5~8这些未应答的消息都会被确认收到消息应答
• false同上面相比
  只会应答tag=8的消息,5,6,7这三个消息依赖不会被确认收到消息应答

最好为false,只应答当前需要的数据,因为其他数据不知道是否正确

2.7.5 消息自动重新入队

如果消费者由于某种原因失去连接(其通道已关闭,连接已关闭或TCP连接丢失),导致消息未发送ACK确认,RabbitMQ将了解到消息未完全处理,并将对其重新排队.如果此时其他消费者可以处理,它将很快将其重新分发给另一个消费者.这样,即使某个消费者偶尔死亡,也可以确保不会丢失任何消息

2.8 RabbitMQ持久化

刚刚我们已经看到了如何处理任务不丢失的情况,默认情况下RabbitMQ退出或由于某种原因崩溃时,它忽视队列和消息,除非告知它不要这样做.确保消息不会丢失需要做两件事:我们需要将队列和消息都标记为持久化

2.8.1 队列如何实现持久化

2.8.2 消息实现持久化

要想让消息实现持久化需要在消息生产者修改代码,MessageProperties.PERSISTENT_TEXT_PLAIN 添加这个属性

将消息标记为持久化并不能完全保证不会丢失消息.尽管它告诉RabbitMQ将消息保存到磁盘,但是这里依然存在当消息刚准备存储在磁盘的时候,但是没有存储完,消息还在缓存的一个间隔点.此时并没有真正写入磁盘.持久性保存并不强

package com.zjz.rabbitmq.three;import com.rabbitmq.client.Channel;
import com.rabbitmq.client.MessageProperties;
import com.zjz.rabbitmq.utils.RabbitMqUtils;import java.util.Scanner;/*** 消息在手动应答时是不丢失、放回队列中的重新消费*/
public class Task02 {// 队列名称public static final String TASK_QUEUE_NAME = "ack_queue";public static void main(String[] args) throws Exception {Channel channel = RabbitMqUtils.getChannel();// 声明一个队列boolean durable=true;// 需要让Queue进行持久化channel.queueDeclare(TASK_QUEUE_NAME,durable,false,false,null);// 从控制台中输入信息Scanner scanner = new Scanner(System.in);while(scanner.hasNext()){String message = scanner.next();// 设置生产者发送消息为持久化消息(要求保存到磁盘上) 保存在内存中channel.basicPublish("",TASK_QUEUE_NAME, MessageProperties.PERSISTENT_TEXT_PLAIN,message.getBytes("UTF-8"));System.out.println("生产者发出消息:"+message);}}}

2.8.3 不公平分发

在最开始的时候我们学习到的RabbitMQ分发消息采用的轮询分发,但是在某种场景下这种策略并不是很好,比如说在两个消费者在处理任务,其中有个消费者1处理任务的速度非常快,而另外一个消费者2处理速度却很慢,这个时候我们还是采用轮询分发的话就会导致处理速度快的这个消费者很大部分时间处于空闲状态,而处理慢的那个消费者一直在干活,这种分配方式在这种情况下其实就不太好,但是RabbitMQ并不知道这种情况它依然很公平的进行分发

为了避免这种情况,我们可以设置参数 channel.basicQos(1)



不公平分发

package com.zjz.rabbitmq.three;import com.rabbitmq.client.Channel;
import com.zjz.rabbitmq.utils.RabbitMqUtils;
import com.zjz.rabbitmq.utils.SleepUtils;public class Work03 {// 队列名称public static final String TASK_QUEUE_NAME = "ack_queue";// 接受消息public static void main(String[] args) throws Exception {Channel channel = RabbitMqUtils.getChannel();System.out.println("C1等待接收消息处理事件较短");// 采用手动应答boolean autoAck = false;// 不公平分发int prefetchCOunt = 1;channel.basicQos(prefetchCOunt);channel.basicConsume(TASK_QUEUE_NAME,autoAck,(consumerTag,message)->{// 沉睡1SSleepUtils.sleep(1);System.out.println("接受到的消息"+new String(message.getBody(),"UTF-8"));System.out.println("deliveryTag:"+message.getEnvelope().getDeliveryTag());// 手动应答/*** 1.消息的标记 tag* 2.是否批量应答 false:不批量应答信道中的消息 true:批量*/channel.basicAck(message.getEnvelope().getDeliveryTag(),false);},consumerTag->{System.out.println("消息消费被中断");});}
}

2.8.4 预取值

三、发布确认

3.1 发布确认原理

生产者将信道设置成confirm模式,一旦信道进入confirm模式,所有在该信道上发布的消息都将会被指派一个唯一的ID(从1开始),一旦消息被投递到所有匹配的队列之后,broker就会发送一个确认给生产者(包含消息的唯一ID),这就使得生产者知道消息已经正确到达目的队列了,如果消息和队列是可持久化的,那么确认消息会在将消息写入磁盘之后发出,broker回传给生产者的确认消息中delivery-tag域包含了确认消息的序列号,此外broker也可以设置basic.ack的multiple域,表示到这个序列号之前的所有消息都已经得到了处理

confirm模式最大的好处在于它是异步的,一旦发布一条消息,生产者应用程序就可以再等信道返回确认的同时继续发送下一条消息,当消息最终得到确认之后,生产者应用便可以通过回调方法来处理该确认消息,如果RabbitMQ因为自身内部错误导致消息丢失,就会发送一条nack消息,生产者应用程序同意可以在回调方法钟处理该nack消息

要想保证数据不丢失
1.设置要求队列必须持久化
2.设置要求队列中的消息必须持久化
3.发布确认

3.2 发布确认的策略

发布确认默认是没有开启的,如果要开启需要调用方法confirmSelect,每当你想要使用发布确认,都需要在channel上调用该方法

		Channel channel = RabbitMqUtils.getChannel();// 开启发布确认channel.confirmSelect();

3.2.1 单个确认发布

这是一个简单的确认方式,它是一种同步确认发布的方式,也就是发布一个消息之后只有它被确认发布,后续的消息才能继续发布,waitForConfirmsOrDie(long)这个方法只有在消息被确认的时候才返回,如果在指定时间范围内这个消息没有被确认那么它将抛出异常

这种确认方式有一个最大的确认就是:发布速度特别慢,以为你如果没有确认发布的消息就会阻塞所有后续的消息发布,这种方式最多提供每秒不超过数百条的消息的吞吐量.当然对于某些应用程序来说这可能已经足够了

// 单个确认public static void publishMessageIndividually() throws Exception {Channel channel = RabbitMqUtils.getChannel();// 队列的声明String queueName = UUID.randomUUID().toString();channel.queueDeclare(queueName, true, false, false, null);// 开启发布确认channel.confirmSelect();// 开始时间long begin = System.currentTimeMillis();// 批量发消息for (int i = 0; i < MESSAGE_COUNT; i++) {String message = i + "";channel.basicPublish("",queueName,null,message.getBytes("UTF-8"));// 单个消息就马上运行发布确认boolean flag = channel.waitForConfirms();if(flag){System.out.println("消息发送成功");}}// 结束时间long end =System.currentTimeMillis();System.out.println("发布"+ MESSAGE_COUNT +"个单独确认消息,耗时"+(end-begin)+"ms");}

3.2.2 批量确认发布

 // 批量发布确认public static void publishMessageBatch() throws Exception {// 声明一个信道Channel channel = RabbitMqUtils.getChannel();// 声明一个队列// 队列名String queueName = UUID.randomUUID().toString();channel.queueDeclare(queueName, true, false, false, null);// 发布确认channel.confirmSelect();// 开始时间long begin = System.currentTimeMillis();// 批量确认消息大小int batchSize = 100;// 批量发送消息 批量发布确认for (int i = 0; i < MESSAGE_COUNT; i++) {String message = i + "";channel.basicPublish("", queueName, null, message.getBytes("UTF-8"));// 判断达到100条的时候 批量确认一次if(i%batchSize==0){// 发布确认channel.waitForConfirms();}}// 结束时间long end = System.currentTimeMillis();System.out.println("发布" + MESSAGE_COUNT + "个批量确认消息,耗时" + (end - begin) + "ms");}

3.2.3 异步确认发布

 // 异步发布确认public static void publishMessageAsync() throws Exception {Channel channel = RabbitMqUtils.getChannel();// 声明一个队列// 队列名String queueName = UUID.randomUUID().toString();channel.queueDeclare(queueName, false, false, false, null);// 发布确认channel.confirmSelect();/*** 线程安全有序的一个哈希表 适用于高并发的情况下*  1.轻松的将序号与消息进行关联*  2.轻松批量删除条目 只要给到序号*  3.支持高并发*/ConcurrentSkipListMap<Long, String> outstandingConfirms = new ConcurrentSkipListMap<>();// 开始时间long begin = System.currentTimeMillis();// 消息确认成功 回调ConfirmCallback ackCallback = (deliveryTag, multiple) -> {if (multiple) {// 2.删除到已经确认的消息 剩下的就是未确认的消息ConcurrentNavigableMap<Long, String> confirmed = outstandingConfirms.headMap(deliveryTag);confirmed.clear();} else {outstandingConfirms.remove(deliveryTag);}
//            System.out.println("确认的消息:"+deliveryTag);};// 消息确认失败 回调/*** 1.消息的标记* 2.是否为批量确认*/ConfirmCallback nackCallback = (deliveryTag, multiple) -> {String message = outstandingConfirms.get(deliveryTag);// 3.打印一下未确认的消息都有哪些System.out.println("未确认的消息是:" + message + ":::未确认的消息tag:" + deliveryTag);};// 准备消息的监听器 监听那些消息成功了 那些消息失败了/*** 1.监听那些消息成功了* 2.监听那些消息失败了*/channel.addConfirmListener(ackCallback, nackCallback); // 异步通知// 批量发布消息for (int i = 0; i < MESSAGE_COUNT; i++) {String message = "消息" + i;channel.basicPublish("", queueName, null, message.getBytes("UTF-8"));// 1.此处记录下所有要发送的消息outstandingConfirms.put(channel.getNextPublishSeqNo(), message);}// 结束时间long end = System.currentTimeMillis();System.out.println("发布" + MESSAGE_COUNT + "个异步确认消息,耗时" + (end - begin) + "ms");}

3.2.4 如何处理异步未确认消息

最好的解决方案就是把未确认 的消息放到一个基于内存的能被发布线程访问的队列,比如说用 ConcurrentLinkedQueue 这个队列在 confirm callbacks 与发布线程之间进行消息的传递

3.2.5 以上3种发布确认速度对比

• 单独发布消息
  同步等待确认,简单,但吞吐量非常有限
• 批量发布消息
  批量同步等待确认,简单,合理的吞吐量,一旦出现问题但很难推断出是那条消息出了问题
• 异步处理
  最佳性能和资源使用,在出现错误的情况下可以很好的控制,但是实现起来稍微难些

四、 交换机

在上一节中,我们创建了一个工作队列.我们假设是工作队列背后,每个任务都恰好交付给一个消费者(工作进程).在这一部分中,我们将做一些完全不同的事情,我们将消息传达给多个消费者.这种模式成为"发布订阅"

为了说明这种模式,我们将构建一个简单的日志系统.它将由两个程序组成:第一个程序将发出日志消息,第二个程序是消费者.其中我们会启动两个消费者,其中一个消费者接收到消息后把日志存储在磁盘,另外一个消费者接收到消息后把消息打印在屏幕上,事实上第一个程序发出的日志消息将广播给所有消费者

4.1 Exchanges

4.1.1 Exchanges 概念

RabbitMQ消息传递模型的核心思想是:生产者生产的消息从不会直接发送到队列.实际上,通常生产者甚至都不知道这些消息传递到了哪些队列中

相反,生产者只能将消息发送到交换机(Exchanges),交换机工作的内容非常简单,一方面它接收来自生产者的消息,另一方面将它们推入队列.交换机必须确切知道如何处理收到的消息.是应该把这些消息放到特定队列还是说把他们放到许多队列中还是说应该丢弃它们.这就得由交换机的类型来决定.

4.1.2 Exchanges 的类型

总共有以下类型:
直接(direct),主题(topic),标题(headers),扇出(fanout)[发布/订阅]

4.1.3 无名exchange

之前能实现的原因是因为我们使用的是默认交换机,我们可以通过空字符串(“”)进行标识

 channel.basicPublish("", queueName, null, message.getBytes("UTF-8"));

第一个参数是交换机的名称.空字符串标识默认或无名称交换机:消息能路由发送到队列中其实是由routingKey(bindingkey)绑定key指定的,如果它存在的话

4.2 临时队列

之前的章节我们使用的是具有特定名称的队列(还记得 hello 和 ack_queue吗?).队列的名称对我们来说至关重要,我们需要指定我们的消费者去消费哪个队列的消息

每当我们连接到Rabbit时,我们都需要一个全新的空队列,为此我们可以创建一个具有随机名称的队列,或者能让服务器为我们选择一个随机队列名称那就更好了.其次一旦我们断开了消费者的连接,队列将自动删除

创建临时队列的方式如下:

String queueName = channel.queueDedare().getQueue();

4.3 绑定(bindings)

什么是bindings呢,binding其实是exchnage和queue之间的桥梁,它告诉我们exchange和那个队列进行了绑定关系.比如说下面这张图片告诉我们的就是X与Q1和Q2进行了绑定

4.4 Fanout(扇出)

Fanout这种类型非常简单.它是将接收到的所有消息广播到它知道的所有队列中.系统中默认有些exchange类型

4.5 Fanout实战

4.5.1 生产者

package com.zjz.rabbitmq.five;import com.rabbitmq.client.BuiltinExchangeType;
import com.rabbitmq.client.Channel;
import com.zjz.rabbitmq.utils.RabbitMqUtils;import java.util.Scanner;public class EmitLog {// 交换机的名称public static final String EXCHANGE_NAME = "logs";public static void main(String[] args) throws Exception {Channel channel = RabbitMqUtils.getChannel();channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.FANOUT);Scanner scanner = new Scanner(System.in);while(scanner.hasNext()){String message = scanner.next();channel.basicPublish(EXCHANGE_NAME,"",null,message.getBytes("UTF-8"));System.out.println("生产者发送的消息是:"+message);}}}

4.5.2 消费者

两个消费者,ReceiveLogs01 同 ReceiveLogs02 代码一致

package com.zjz.rabbitmq.five;import com.rabbitmq.client.BuiltinExchangeType;
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.DeliverCallback;
import com.zjz.rabbitmq.utils.RabbitMqUtils;/*** 消息的接收*/
public class ReceiveLogs01 {// 交换机的名称public static final String EXCHANGE_NAME = "logs";public static void main(String[] args) throws Exception {Channel channel = RabbitMqUtils.getChannel();// 声明一个交换机channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.FANOUT);// 声明一个队列 临时队列/*** 生成一个临时队列 队列的名称是随机的* 当消费者断开与队列的连接的时候 队列就自动删除*/String queue = channel.queueDeclare().getQueue();/*** 绑定交换机与队列*/channel.queueBind(queue,EXCHANGE_NAME,"");System.out.println("等待接受消息,把接受到的消息打印在屏幕上.......");// 接收消息DeliverCallback deliverCallback=(consumerTag,message)->{System.out.println("ReceiveLogs01控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8"));};// 消费者取消时回调接口channel.basicConsume(queue,true,deliverCallback,consumerTag->{});}
}

4.6 Direct exchange(直接)

4.6.1 回顾

在上一节,我们构建了一个简单的日志记录系统.我们能够向许多接收者广播日志消息.在本节我们将向其中一些特别的功能-比方说我们只让某个消费者订阅发布的部分消息.例如我们只把严重错误消息定向存储到日志文件(以节省磁盘空间),同时仍然能够在控制台打印所有日志消息

我们再次来回顾一下什么是bindings,绑定是交换机和队列之间的桥梁关系.也可以理解:队列只对它绑定的交换机的消息感兴趣.绑定用参数:routingkey来表示也可以称该参数为binding key,创建绑定我们用代码:channel.queueBind(queueName,EXCHANGE_NAME,“routingKey”);*绑定之后的意义由其交互类型决定

4.6.2 Direct exchange 介绍

在上一节中的我们的日志系统将所有消息广播给所有的消费者,对此我们想做一些改变,例如我们希望将日志写入磁盘的程序仅接收严重错误(errors),而不存储哪些警告(warning)或消息(info)日志消息避免浪费磁盘空间.Fanout这种交换类型并不能给我们带来很大的灵活性-它只能进行无意识的广播,在这里我们将使用direct这种类型来进行替换,这种类型的工资方式是,消息只去到它绑定的routingKey队列中去

在上面这张图中,我们可以看到X绑定了两个队列,绑定类型是direct.队列Q1绑定键为orange,队列Q2绑定键有两个:一个绑定建为blanck,另一个绑定建为green

在这种绑定情况下,生产者发布消息到exchange上,绑定键为orange的消息会被发布到队列Q1.绑定键为black和green的消息会被发布到队列Q2,其他消息类型的消息将会被丢弃

4.6.3 多重绑定

当如果exchange的绑定类型是direct,**但是它绑定的多个队列的key如果都相同,**在这种情况下虽然绑定的类型是direct 但是它表现的就和fanout有点类似了,就跟广播差不多,如上图所示.

4.6.4 实战

Exchange:direct_logs

4.6.5 生产者

package com.zjz.rabbitmq.direct;import com.rabbitmq.client.Channel;
import com.zjz.rabbitmq.utils.RabbitMqUtils;import java.util.Scanner;public class DirectLogs {// 交换机名称public static final String EXCHANGE_NAME = "directlogs";public static void main(String[] args) throws Exception {Channel channel = RabbitMqUtils.getChannel();Scanner scanner = new Scanner(System.in);while (scanner.hasNext()) {String message = scanner.next();channel.basicPublish(EXCHANGE_NAME, "info", null, message.getBytes("UTF-8"));System.out.println("生产者发出的消息:" + message);}}}

4.6.6 消费者1

package com.zjz.rabbitmq.direct;import com.rabbitmq.client.BuiltinExchangeType;
import com.rabbitmq.client.Channel;
import com.zjz.rabbitmq.utils.RabbitMqUtils;public class ReceiveLogsDirect01 {public static final String EXCHANGE_NAME = "direct_logs";public static void main(String[] args) throws Exception {Channel channel = RabbitMqUtils.getChannel();// 声明一个交换机channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.DIRECT);// 声明一个临时队列String queueName = "console";channel.queueDeclare(queueName, false, false, false, null);channel.queueBind(queueName, EXCHANGE_NAME, "info");channel.queueBind(queueName, EXCHANGE_NAME, "warning");channel.basicConsume(queueName,true,(consumerTag,message)->{System.out.println("ReceiveLogsDirect01控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8"));},(consumerTag)->{});}}

4.6.7 消费者2

package com.zjz.rabbitmq.direct;import com.rabbitmq.client.BuiltinExchangeType;
import com.rabbitmq.client.Channel;
import com.zjz.rabbitmq.utils.RabbitMqUtils;public class ReceiveLogsDirect02 {public static final String EXCHANGE_NAME = "direct_logs";public static void main(String[] args) throws Exception {Channel channel = RabbitMqUtils.getChannel();// 声明一个交换机channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.DIRECT);// 声明一个临时队列String queueName = "disk";channel.queueDeclare(queueName, false, false, false, null);channel.queueBind(queueName, EXCHANGE_NAME, "error");channel.basicConsume(queueName,true,(consumerTag,message)->{System.out.println("ReceiveLogsDirect02控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8"));},(consumerTag)->{});}}

4.7 Topics(主题)

4.7.1 之前类型的问题

再上一个小节中,我们改进了日志记录系统.我们没有使用只能进行随意广播的fanout交换机,而是使用了direct交换机,从而有能实现有选择性地接收日志.

尽管使用direct交换机改进了我们的系统,但是它仍然存在局限性-比方说我们想接收的日志类型有info.base和info,advantage,某个队列只想info,base的消息,那这个时候direct就办不到了.这个时候就只能使用topic类型

4.7.2 topic的要求

发送到类型是topic交换机的消息的routing_key不能随意写,必须满足一定的需求,它必须是一个单词列表,易点好分隔开.这些单词可以是任意单词,比如说:“stock.usd.nyse”,“nyse.vmw”,"quick.orange.rabbit"这种类型的.当然这个单词列表最多不能超过255个字节

在这个规则列表中,其中有两个替换符是大家需要注意的

*(星号)可以代替一个单词
#(井号)可以替代零个或多个单词

4.7.3 Topic匹配案例

下图绑定关系如下
Q1–>绑定的是
中间带orange带3个单词的字符串(*.orange.*)

Q2–>绑定的是
最后一个单词是rabbit的3个单词(*.*.rabbit)
第一个单词是lazy的多个单词(lazy.#)

当一个队列绑定键是#,那么这个队列将接收所有数据,就有点像fanout了

如果队列绑定键当中没有#和*出现,那么该队列绑定类型就是direct了

4.7.4 消费者01

package com.zjz.rabbitmq.topic;import com.rabbitmq.client.BuiltinExchangeType;
import com.rabbitmq.client.Channel;
import com.zjz.rabbitmq.utils.RabbitMqUtils;/*** 声明主题交换机 及相关队列*/
public class ReceiveLogsTopic01 {public static final String EXCANGE_NAME = "topic_logs";// 接收消息public static void main(String[] args) throws Exception {Channel channel = RabbitMqUtils.getChannel();// 声明交换机channel.exchangeDeclare(EXCANGE_NAME, BuiltinExchangeType.TOPIC);// 声明队列String queueName = "Q1";channel.queueDeclare(queueName,false,false,false,null);// 绑定channel.queueBind(queueName,EXCANGE_NAME,"*.orange.*");System.out.println("等待接收消息.....");channel.basicConsume(queueName,true,(consumerTag,message)->{System.out.println(new String(message.getBody(),"utf-8"));System.out.println("接收队列:"+queueName+"绑定键:"+message.getEnvelope().getRoutingKey());}, consumerTag->{});}}

4.7.5消费者02

package com.zjz.rabbitmq.topic;import com.rabbitmq.client.BuiltinExchangeType;
import com.rabbitmq.client.Channel;
import com.zjz.rabbitmq.utils.RabbitMqUtils;/*** 声明主题交换机 及相关队列*/
public class ReceiveLogsTopic02 {public static final String EXCANGE_NAME = "topic_logs";// 接收消息public static void main(String[] args) throws Exception {Channel channel = RabbitMqUtils.getChannel();// 声明交换机channel.exchangeDeclare(EXCANGE_NAME, BuiltinExchangeType.TOPIC);// 声明队列String queueName = "Q2";channel.queueDeclare(queueName,false,false,false,null);// 绑定channel.queueBind(queueName,EXCANGE_NAME,"*.*.rabbit");channel.queueBind(queueName,EXCANGE_NAME,"lazy.#");System.out.println("等待接收消息.....");channel.basicConsume(queueName,true,(consumerTag,message)->{System.out.println(new String(message.getBody(),"utf-8"));System.out.println("接收队列:"+queueName+"绑定键:"+message.getEnvelope().getRoutingKey());}, consumerTag->{});}}

4.7.6 生产者

package com.zjz.rabbitmq.topic;import com.rabbitmq.client.Channel;
import com.zjz.rabbitmq.utils.RabbitMqUtils;import java.io.IOException;
import java.util.HashMap;
import java.util.Map;/*** 生产者*/
public class EmitLogTopic {// 交换机名称public static final String EXCHANGE_NAME = "topic_logs";public static void main(String[] args) throws Exception {Channel channel = RabbitMqUtils.getChannel();Map<String, String> bindingKeyMap = new HashMap<>();bindingKeyMap.put("quick.orange.rabbit", "被队列Q1Q2接收到");bindingKeyMap.put("lazy.orange.elephant", "被队列Q1Q2接收到");bindingKeyMap.put("quick.orange.fox", "被队列Q1接收到");bindingKeyMap.put("lazy.brown.fox", "被队列Q2接收到");bindingKeyMap.put("lazy.pink.rabbit", "虽然满足两个绑定但只被队列Q2接收一次");bindingKeyMap.put("quick.brown.fox", "不匹配任何绑定不会被任何队列接收到会被丢弃");bindingKeyMap.put("quick.orange.male.rabbit", "是四个单词不匹配任何绑定会被丢弃");bindingKeyMap.put("lazy.orange.male.rabbit", "是四个单词但匹配Q2");bindingKeyMap.entrySet().forEach(map->{String routingKey = map.getKey();String message =map.getValue();try {channel.basicPublish(EXCHANGE_NAME,routingKey,null,message.getBytes("UTF-8"));} catch (IOException e) {throw new RuntimeException(e);}System.out.println("生产者发出消息:"+message);});}}

五、 死信队列

5.1 死信队列的概念

先从概念解释上搞清楚这个定义,死心,顾名思义就是无法被消费的消息,字面意思可以这样理解,一般来说,producer将消息投递到broker或者直接到queue里了,consumer从queue取出消息进行消费,但某些时候由于特定的 原因导致queue中的某些消息无法被消费, 这样的消息如果没有后续的处理,就变成了私信,有私信自然就有了死信队列

应用场景:为了保证订单业务的消息数据不丢失,需要使用到RabbitMQ的死信队列机制,当消息消费发送异常时,将消息投入死信队列中,还有比如说:用户在商城下单成功并点击去支付后在指定的时间未支付时自动失效

5.2 死信的来源

• 消息TTL过期
• 队列达到最大长度(队列满了,无法再添加数据到mq中)
• 消息被拒绝(basic.reject或basic.nack)并且requeue=false

5.3 死信实战

5.3.1 代码架构图

5.3.2 生产者

package com.zjz.rabbitmq.deadqueue;import com.rabbitmq.client.AMQP;
import com.rabbitmq.client.Channel;
import com.zjz.rabbitmq.utils.RabbitMqUtils;/*** 死信队列* 生产者*/
public class DeadProducer {// 普通交换机的名称public static final String NORMAL_EXCHANGE = "normal_exchange";public static void main(String[] args) throws Exception {Channel channel = RabbitMqUtils.getChannel();// 延迟消息 死信消息 设置TTL时间 time to liveAMQP.BasicProperties properties=new AMQP.BasicProperties().builder().expiration("10000").build();for (int i = 1; i < 11; i++) {String message = "info"+i;channel.basicPublish(NORMAL_EXCHANGE,"zhangsan",properties,message.getBytes("UTF-8"));}}}

5.3.3 消费者1 (重点)

package com.zjz.rabbitmq.deadqueue;import com.rabbitmq.client.BuiltinExchangeType;
import com.rabbitmq.client.Channel;
import com.zjz.rabbitmq.utils.RabbitMqUtils;import java.util.HashMap;
import java.util.Map;/*** 死信队列* <p>* 消费者1*/
public class DeadConsumer01 {// 普通交换机的名称public static final String NORMAL_EXCHANGE = "normal_exchange";// 死信队列的名称public static final String DEAD_EXCHANGE = "dead_exchange";// 普通队列的名称public static final String NORMAL_QUEUE = "normal_queue";// 死信队列的名称public static final String DEAD_QUEUE = "dead_queue";public static void main(String[] args) throws Exception {Channel channel = RabbitMqUtils.getChannel();// 声明死信和普通的交换机 类型为directchannel.exchangeDeclare(NORMAL_EXCHANGE, BuiltinExchangeType.DIRECT);channel.exchangeDeclare(DEAD_EXCHANGE,BuiltinExchangeType.DIRECT);// 声明普通队列Map<String,Object> arguments = new HashMap<>();// 过期时间 10s=10000ms
//        arguments.put("x-message-ttl",100000);// 正常队列设置死信交换机arguments.put("x-dead-letter-exchange",DEAD_EXCHANGE);// 设置死信RoutingKeyarguments.put("x-dead-letter-routing-key","lisi");channel.queueDeclare(NORMAL_QUEUE,false,false,false,arguments);//// 声明死信队列channel.queueDeclare(DEAD_QUEUE,false,false,false,null);// 绑定普通的交换机和队列channel.queueBind(NORMAL_QUEUE,NORMAL_EXCHANGE,"zhangsan");// 绑定死信的交换机和死信的队列channel.queueBind(DEAD_QUEUE,DEAD_EXCHANGE,"lisi");System.out.println("等待接收消息.....");channel.basicConsume(NORMAL_QUEUE,true,(consumerTag,message)->{System.out.println("DeadConsumer01接收的消息是:"+new String(message.getBody(),"UTF-8"));},(consumerTag)->{});}}

5.3.4 消费者2 处理死信队列

package com.zjz.rabbitmq.deadqueue;import com.rabbitmq.client.Channel;
import com.zjz.rabbitmq.utils.RabbitMqUtils;
/*** 死信队列* <p>* 消费者2*/
public class DeadConsumer02 {// 死信队列的名称public static final String DEAD_EXCHANGE = "dead_exchange";// 死信队列的名称public static final String DEAD_QUEUE = "dead_queue";public static void main(String[] args) throws Exception {Channel channel = RabbitMqUtils.getChannel();System.out.println("等待接收消息.....");channel.basicConsume(DEAD_QUEUE,true,(consumerTag,message)->{System.out.println("DeadConsumer02接收的消息是:"+new String(message.getBody(),"UTF-8"));},consumerTag->{});}
}

6.延迟队列

6.1 延迟队列概念

延迟队列,队列内部是有序的,最重要的特性就提现在它的延时属性上,延时队列中的元素时希望在指定时间到了以后或之前取出和处理,简单来说,延时队列就是用来存放需要再指定时间被处理的元素的队列

6.2 延迟队列使用场景

• 订单在十分钟之内未支付则自动取消
• 新创建的店铺,如果在十天内都没有上传过商品,则自动发送消息提醒
• 用户注册成功后,如果三天内没有登录则进行短信提醒
• 用户发起退款,如果三天内没有得到处理则通知相关运营人员
• 预定会议后,需要再预定的时间点前十分钟通知各个与会人员参加会议

这些场景都有一个特点,需要在某个事件发生之后或者之前的指定时间点完成某一项任务,如:发生订单生成事件,在十分钟之后检查该订单支付状态,然后将未支付的订单进行关闭;看起来似乎使用定时任务,一直轮询数据,每秒查一次,取出需要被处理的数据,然后处理不就完事了吗?如果数据量比较少,确实可以这样做,比如:对于"如果账单一周内未支付则进行自动结算"这样的需求,如果对于时间不是严格限制,而是宽松意义上的一周,那么每天晚上跑个定时任务检查一下所有未支付的账单,确实也是一个可行的方案.但对于数据量比较大,并且时效性较强的场景,如:“订单十分钟内未支付则关闭”,短期内未支付的订单的数据可能会有很多,活动期间甚至会达到百万甚至千万级别,对这么庞大的数据量仍旧使用轮询的方式显然是不可取的,很可能在一秒内无法完成所有订单的检查,同事会给数据库带来很大的压力,无法满足业务要求而且性能低下

6.3 整合springboot

6.3.1 添加依赖

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><parent><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-parent</artifactId><version>2.6.11</version><relativePath/> <!-- lookup parent from repository --></parent><groupId>com.zjz</groupId><artifactId>springboot-rabbitmq</artifactId><version>0.0.1-SNAPSHOT</version><name>springboot-rabbitmq</name><description>springboot-rabbitmq</description><properties><java.version>1.8</java.version></properties><dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-amqp</artifactId></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><scope>test</scope></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><dependency><groupId>io.springfox</groupId><artifactId>springfox-swagger2</artifactId><version>2.9.2</version></dependency><dependency><groupId>io.springfox</groupId><artifactId>springfox-swagger-ui</artifactId><version>2.9.2</version></dependency><dependency><groupId>com.alibaba</groupId><artifactId>fastjson</artifactId><version>2.0.24</version></dependency><dependency><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId></dependency><dependency><groupId>org.springframework.amqp</groupId><artifactId>spring-rabbit-test</artifactId><scope>test</scope></dependency></dependencies><build><plugins><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-compiler-plugin</artifactId><version>3.8.1</version><configuration><source>1.8</source><target>1.8</target><encoding>UTF-8</encoding></configuration></plugin><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId></plugin></plugins></build></project>

6.3.2 配置文件

spring:rabbitmq:host: 192.168.88.132port: 5672username: adminpassword: 123

6.3.3 配置Swagger

package com.zjz.springbootrabbitmq.config;import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import springfox.documentation.builders.ApiInfoBuilder;
import springfox.documentation.service.ApiInfo;
import springfox.documentation.service.Contact;
import springfox.documentation.spi.DocumentationType;
import springfox.documentation.spring.web.plugins.Docket;
import springfox.documentation.swagger2.annotations.EnableSwagger2;@Configuration
@EnableSwagger2
public class SwaggerConfig {@Beanpublic Docket webApiConfig(){return new Docket(DocumentationType.SWAGGER_2).groupName("webApi").apiInfo(webApiInfo()).select().build();}private ApiInfo webApiInfo(){return new ApiInfoBuilder().title("rabbitmq接口文档").description("本文档描述了rabbitmq微服务接口定义").version("1.0").contact(new Contact("xijian","","xijian001122@163.com")).build();}}

6.4 队列TTL

6.4.1 代码架构图

创建两个队列QA和QB,晾着队列TTL分别设置为10S和40S,然后再创建一个交换机X和死信交换机Y,它们的类型都是direct,创建一个死信队列QD,它们的绑定关系如下:

6.4.2 配置文件类代码

package com.zjz.springbootrabbitmq.config;import org.springframework.amqp.core.*;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;import java.util.HashMap;
import java.util.Map;/*** TTL队列 配置文件类代码*/
@Configuration
public class TtlQueueConfig {// 普通交换机的名称public static final String X_EXCHANGE="X";// 死信交换机的名称public static final String Y_DEAD_LETTER_EXCHANGE="Y";// 普通队列名称public static final String QUEUE_A="QA";public static final String QUEUE_B="QB";// 死信队列名称public static final String DEAD_LETTER_QUEUE="QD";// 声明xExchange   别名@Bean("xExchange")public DirectExchange xExchange(){return new DirectExchange(X_EXCHANGE);}// 声明yExchange   别名@Bean("yExchange")public DirectExchange yExchange(){return new DirectExchange(Y_DEAD_LETTER_EXCHANGE);}// 声明普通队列 TTL 为 10S@Bean("queueA")public Queue queueA(){Map<String,Object> arguments =new HashMap<>(3);// 设置死信交换机arguments.put("x-dead-letter-exchange",Y_DEAD_LETTER_EXCHANGE);// 设置死信RoutingKeyarguments.put("x-dead-letter-routing-key","YD");// 设置TTL    单位是msarguments.put("x-message-ttl",10000);return QueueBuilder.durable(QUEUE_A).withArguments(arguments).build();}// 声明普通队列 TTL 为 10S@Bean("queueB")public Queue queueB(){Map<String,Object> arguments =new HashMap<>(3);// 设置死信交换机arguments.put("x-dead-letter-exchange",Y_DEAD_LETTER_EXCHANGE);// 设置死信RoutingKeyarguments.put("x-dead-letter-routing-key","YD");// 设置TTL    单位是msarguments.put("x-message-ttl",40000);return QueueBuilder.durable(QUEUE_B).withArguments(arguments).build();}// 死信队列@Bean("queueD")public Queue queueD(){return QueueBuilder.durable(DEAD_LETTER_QUEUE).build();}// 绑定@Beanpublic Binding queueABindingX(@Qualifier("queueA") Queue queueA, @Qualifier("xExchange") DirectExchange xExchange){return BindingBuilder.bind(queueA).to(xExchange).with("XA");}// 绑定@Beanpublic Binding queueBBindingX(@Qualifier("queueB") Queue queueB, @Qualifier("xExchange") DirectExchange xExchange){return BindingBuilder.bind(queueB).to(xExchange).with("XA");}// 绑定@Beanpublic Binding queueDBindingX(@Qualifier("queueD") Queue queueD, @Qualifier("yExchange") DirectExchange yExchange){return BindingBuilder.bind(queueD).to(yExchange).with("YD");}
}

6.4.3 队列TTL 生产者

package com.zjz.springbootrabbitmq.controller;import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;import java.util.Date;/***  发送延迟消息*/
@Slf4j
@RestController
@RequestMapping("/ttl")
public class SendMsgController {@Autowiredprivate RabbitTemplate rabbitTemplate;// 开始发消息@GetMapping("/sendMsg/{message}")public void sendMsg(@PathVariable String message){log.info("当前时间:{},发送一条信息给两个TTL队列:{}",new Date().toString(),message);rabbitTemplate.convertAndSend("X","XA","消息来自ttl为10s的队列:"+message);rabbitTemplate.convertAndSend("X","XB","消息来自ttl为40s的队列:"+message);}}

6.4.4 队列TTL 消费者

package com.zjz.springbootrabbitmq.consumer;import com.rabbitmq.client.Channel;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.Message;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;import java.util.Date;/***  队列TTL 消费者*/
@Slf4j
@Component
public class DeadLetterQueueConsumer {// 接收消息@RabbitListener(queues = "QD")public void receiveD(Message message, Channel channel){String msg = new String(message.getBody());log.info("当前时间:{},收到死信队列的消息:{}",new Date().toString(),msg);}}

第一条消息在10S后变成了死信消息,然后被消费者消费掉,第二条消息在40S之后变成了死信消息,然后被消费者消费掉,这样的一个延时队列就打造完成了

不过,如果这样使用的话,每增加一个新的时间需求,就要更新一个队列,这里只有10S和40S两个时间选项,如果需要一个小时后处理,那么就需要增加TTL为一个小时的队列,如果是预定会议室然后提示通知的这样的场景,岂不是要增加无数个队列才能满足需求?

6.5 延时队列优化

6.5.1 代码架构图

在这里新增一个队列QC,绑定关系如下,该队列不设置TTL时间

6.5.2 新增一个QC不设置TTL

package com.zjz.springbootrabbitmq.config;import org.springframework.amqp.core.*;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;import java.util.HashMap;
import java.util.Map;/*** TTL队列 配置文件类代码*/
@Configuration
public class TtlQueueConfig {// 普通交换机的名称public static final String X_EXCHANGE="X";// 死信交换机的名称public static final String Y_DEAD_LETTER_EXCHANGE="Y";// 普通队列名称public static final String QUEUE_A="QA";public static final String QUEUE_B="QB";public static final String QUEUE_C="QC";// 死信队列名称public static final String DEAD_LETTER_QUEUE="QD";// 声明xExchange   别名@Bean("xExchange")public DirectExchange xExchange(){return new DirectExchange(X_EXCHANGE);}// 声明yExchange   别名@Bean("yExchange")public DirectExchange yExchange(){return new DirectExchange(Y_DEAD_LETTER_EXCHANGE);}// 声明普通队列 TTL 为 10S@Bean("queueA")public Queue queueA(){Map<String,Object> arguments =new HashMap<>(3);// 设置死信交换机arguments.put("x-dead-letter-exchange",Y_DEAD_LETTER_EXCHANGE);// 设置死信RoutingKeyarguments.put("x-dead-letter-routing-key","YD");// 设置TTL    单位是msarguments.put("x-message-ttl",10000);return QueueBuilder.durable(QUEUE_A).withArguments(arguments).build();}// 声明普通队列 TTL 为 10S@Bean("queueB")public Queue queueB(){Map<String,Object> arguments =new HashMap<>(3);// 设置死信交换机arguments.put("x-dead-letter-exchange",Y_DEAD_LETTER_EXCHANGE);// 设置死信RoutingKeyarguments.put("x-dead-letter-routing-key","YD");// 设置TTL    单位是msarguments.put("x-message-ttl",40000);return QueueBuilder.durable(QUEUE_B).withArguments(arguments).build();}@Bean("queueC")public Queue queueC(){Map<String,Object> arguments =new HashMap<>(3);// 设置死信交换机arguments.put("x-dead-letter-exchange",Y_DEAD_LETTER_EXCHANGE);// 设置死信RoutingKeyarguments.put("x-dead-letter-routing-key","YD");// 没有声明TTL属性return QueueBuilder.durable(QUEUE_C).withArguments(arguments).build();}// 死信队列@Bean("queueD")public Queue queueD(){return QueueBuilder.durable(DEAD_LETTER_QUEUE).build();}// 绑定@Beanpublic Binding queueABindingX(@Qualifier("queueA") Queue queueA, @Qualifier("xExchange") DirectExchange xExchange){return BindingBuilder.bind(queueA).to(xExchange).with("XA");}// 绑定@Beanpublic Binding queueBBindingX(@Qualifier("queueB") Queue queueB, @Qualifier("xExchange") DirectExchange xExchange){return BindingBuilder.bind(queueB).to(xExchange).with("XB");}// 绑定@Beanpublic Binding queueCBindingX(@Qualifier("queueC") Queue queueC,@Qualifier("xExchange") DirectExchange xExchange){return BindingBuilder.bind(queueC).to(xExchange).with("XC");}// 绑定@Beanpublic Binding queueDBindingX(@Qualifier("queueD") Queue queueD, @Qualifier("yExchange") DirectExchange yExchange){return BindingBuilder.bind(queueD).to(yExchange).with("YD");}
}

6.5.3 生产者发送时设置TTL

package com.zjz.springbootrabbitmq.controller;import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.MessagePostProcessor;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;import java.util.Date;/*** 发送延迟消息*/
@Slf4j
@RestController
@RequestMapping("/ttl")
public class SendMsgController {@Autowiredprivate RabbitTemplate rabbitTemplate;// 开始发消息@GetMapping("/sendMsg/{message}")public void sendMsg(@PathVariable String message) {log.info("当前时间:{},发送一条信息给两个TTL队列:{}", new Date().toString(), message);rabbitTemplate.convertAndSend("X", "XA", "消息来自ttl为10s的队列:" + message);rabbitTemplate.convertAndSend("X", "XB", "消息来自ttl为40s的队列:" + message);}// 开始发消息 消息TTL@GetMapping("/sendExpirationMsg/{message}/{ttlTime}")public void sendMsg(@PathVariable String message, @PathVariable String ttlTime) {log.info("当前时间:{},发送一条时长{}毫秒TTL信息给TTL队列QC:{}", new Date().toString(), ttlTime, message);rabbitTemplate.convertAndSend("X", "XC", message, msg -> {// 发送消息的时候 延迟时长msg.getMessageProperties().setExpiration(ttlTime);return msg;});}}

6.6 延迟队列(基于死信队列存在的问题)

看起来似乎没什么问题,但是在最开始的时候,就介绍过如果使用在消息属性上设置TTL的方式,消息可能并不会按时"死亡",因为 RabbitMQ只会检查第一个消息是否过期 ,如果过期则丢到死信队列,如果第一个消息的延时时长很长 ,而第二个消息的延时时长很短,第二个消息并不会优先得到执行

6.7 Rabbitmq插件实现延迟队列

如果不能实现在消息粒度上的TTL,并使其在设置的TTL时间及时死亡,就无法设计成一个通用的延时队列.那如何解决呢,接下来我们就去解决该问题

6.7.1 安装延时队列插件

在官网上下载 https://www.rabbitmq.com/community-plugins.html , 下载
rabbitmq_delayed_message_exchange 插件 ,然后解压设置到RabbitMQ的插件目录

进入Rabbit的安装目录下的plgins目录,执行下面命令让该插件生效,然后重启RabbitMQ

 rabbitmq-plugins enable rabbitmq_delayed_message_exchange

6.6.2 代码架构图

在这里新增了一个队列 delayed.queue,一个自定义交换机 delayed.exchange,绑定关系如下

6.6.3 配置文件类代码

在我们自定义的交换机中,这是一种新的交换类型,该类型消息支持延时投递机制 消息传递后并不会立即投递到目标队列中,而是存储在mnesia(一个分布式数据系统)表中,当达到投递时间时,才投递到目标队列中

package com.zjz.springbootrabbitmq.config;import org.springframework.amqp.core.Binding;
import org.springframework.amqp.core.BindingBuilder;
import org.springframework.amqp.core.CustomExchange;
import org.springframework.amqp.core.Queue;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;import java.util.HashMap;
import java.util.Map;@Configuration
public class DelayedQueueConfig
{// 交换机public static final String DELAYED_QUEUE_NAME="delayed.queue";//队列public static final String DELAYED_EXCHANGE_NAME="delayed.exchange";// routingKeypublic static final String DELAYED_ROUTING_KEY= "delayed.routingkey";// 声明交换机 基于插件的@Beanpublic CustomExchange delayedExchange(){Map<String,Object> arguments = new HashMap<>();arguments.put("x-delayed-type","direct");/***  1.交换机的名称*  2.交换机的类型*  3.是否需要持久化*  4.是否需要自动删除*/return new CustomExchange(DELAYED_EXCHANGE_NAME,"x-delayed-message",true,false,arguments);}// 声明队列@Beanpublic Queue delayedQueue(){return new Queue(DELAYED_QUEUE_NAME);}// 绑定@Beanpublic Binding delayedQueueBindingDelayedExchange(@Qualifier("delayedQueue") Queue delayedQueue,@Qualifier("delayedExchange") CustomExchange delayedExchange){return BindingBuilder.bind(delayedQueue).to(delayedExchange).with(DELAYED_ROUTING_KEY).noargs();}}

6.6.4 生产者

 // 开始发消息 基于插件的 消息 及 延迟时间@GetMapping("/sendDelayMsg/{message}/{delayTime}")public void sendMsg(@PathVariable String message, @PathVariable Integer delayTime) {log.info("当前时间:{},发送一条时长{}毫秒TTL信息给延时队列delayed.queue:{}", new Date().toString(), delayTime, message);rabbitTemplate.convertAndSend(DelayedQueueConfig.DELAYED_EXCHANGE_NAME,DelayedQueueConfig.DELAYED_ROUTING_KEY,message,msg->{// 发送消息的时候 延迟时长 单位:msmsg.getMessageProperties().setDelay(delayTime);return msg;});}

6.6.5 消费者

package com.zjz.springbootrabbitmq.consumer;import com.zjz.springbootrabbitmq.config.DelayedQueueConfig;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.Message;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;import java.util.Date;/*** 基于插件的延迟消息*/
@Slf4j
@Component
public class DelayQueueConsumer {// 监听消息@RabbitListener(queues = DelayedQueueConfig.DELAYED_QUEUE_NAME)public void receiveDelayQueue(Message message){String msg =new String(message.getBody());log.info("当前时间:{},收到延迟队列的消息:{}",new Date().toString(),msg);}}

6.7 总结

延时队列在需要延时处理的场景中非常有用,使用RabbitMQ来实现延时队列可以很好的利用RabbitMQ的特性,如:消息可靠发送,消息可靠投递,死信队列来保障消息至少被消费一次以及未被正确处理的消息不会被丢弃.另外,通过RabbitMQ集群的特性,可以很好的解决单点故障问题,不会因为单个节点挂掉导致延时队列不可用或者消息丢失

当然,延时队列还有很多其他选择,比如利用Java的DelayQueue,利用Redis的zset,利用Quartz或者利用kafka的时间轮,这些方式各有各的特点,看需要适用的场景

七、 发布确认高级

在生产环境中由于一些不明原因,导致rabbitmq重启,在RabbitMQ重启期间生产者消息传递失败,导致消息丢失,需要手动处理和恢复.于是,我们开始思考,如何才能进行RabbitMQ的消息可靠传递呢?
特别是在这样比较极端的情况下,RabbitMQ集群不可用的时候,无法传递的消息该如何处理呢:

7.1 发布确认springboot版本

7.1.1 确认机制方案

7.1.2 代码架构图

7.1.3 配置文件

在配置文件当中需要添加

spring.rabbitmq.publisher-confirm-type=correlated

• NONE
  禁用发布确认模式,是默认值
• CORRELATED
  发布消息成功到交换机后会触发回调方法
• SIMPLE
  经测试有两种效果,其一效果和CORRELATED值一样会触发回调方法,
  其二在发布消息成功后使用rabbitTemplate调用waitForConfirms或waitForConfirmOrDie方法等待broker节点返回发送结果,根据返回结果来判定下一步的逻辑,要注意的点是waitForConfirmsOrDie方法如果返回false贼会关闭channel,则接下来无法发送消息到broker

spring:rabbitmq:host: 192.168.88.132port: 5672username: adminpassword: 123publisher-confirm-type: correlated

7.1.4 添加配置类

package com.zjz.springbootrabbitmq.config;import org.springframework.amqp.core.*;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;/*** 配置类 发布确认(高级)*/
@Configuration
public class ConfirmConfig {// 交换机public static final String CONFIRM_EXCHANGE_NAME="confirm_exchange";// 队列public static final String CONFIRM_QUEUE_NAME="confirm_queue";// routingKeypublic static final String CONFIRM_ROUTING_KEY="key1";// 声明交换机@Bean("confirmExchange")public Exchange confirmExchange(){return ExchangeBuilder.directExchange(CONFIRM_EXCHANGE_NAME).build();}// 声明队列@Bean("confirmQueue")public Queue confirmQueue(){return QueueBuilder.durable(CONFIRM_QUEUE_NAME).build();}// 绑定@Beanpublic Binding confirmQueueBindingconfirmExchange(@Qualifier("confirmQueue") Queue confirmQueue,@Qualifier("confirmExchange") Exchange confirmExchange){return BindingBuilder.bind(confirmQueue).to(confirmExchange).with(CONFIRM_ROUTING_KEY).noargs();}
}

7.1.5 消息生产者

package com.zjz.springbootrabbitmq.controller;import com.zjz.springbootrabbitmq.config.ConfirmConfig;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.connection.CorrelationData;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;@Slf4j
@RestController
@RequestMapping("/confirm")
public class ProducerController {@Autowiredprivate RabbitTemplate rabbitTemplate;// 发消息@GetMapping("/sendMessage/{message}")public void sendMessage(@PathVariable String message){CorrelationData correlationData=new CorrelationData("1");rabbitTemplate.convertAndSend(ConfirmConfig.CONFIRM_EXCHANGE_NAME,ConfirmConfig.CONFIRM_ROUTING_KEY,message,correlationData);log.info("发送消息内容:{}",message);}
}

7.1.6 回调接口

package com.zjz.springbootrabbitmq.config;import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.connection.CorrelationData;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;import javax.annotation.PostConstruct;@Slf4j
@Component
public class MyCallBack implements RabbitTemplate.ConfirmCallback {@Autowiredprivate RabbitTemplate rabbitTemplate;@PostConstructpublic void init(){// 注入rabbitTemplate.setConfirmCallback(this);}/*** 交换机确认回调方法* 1.发消息 交换机接受到了消息** @param correlationData 1.1保存回调消息的ID及相关信息* @param b               1.2 交换机收到消息 true* @param s               1.3 s null*                        <p>*                        2.发消息 交换机接收失败了 回调* @param correlationData 2.1 保存回调消息的ID及相关信息* @param b               2.2 交换机收到消息 false* @param s               2.3 s 失败的原因*/@Overridepublic void confirm(CorrelationData correlationData, boolean b, String s) {String id = correlationData != null ? correlationData.getId() : "";if (b) {log.info("交换机已经收到Id为:{}的消息", id);} else {log.info("交换机还未收到Id为:{}的消息,由于原因:{}", id,s);}}
}

7.1.7 消息消费者

package com.zjz.springbootrabbitmq.consumer;import com.zjz.springbootrabbitmq.config.ConfirmConfig;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.Message;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;/*** 接收消息*/
@Slf4j
@Component
public class ConfirmConsumer {@RabbitListener(queues = ConfirmConfig.CONFIRM_QUEUE_NAME)public void receiveConfirmMessage(Message message){String msg = new String(message.getBody());log.info("接受到的队列confirm.queue消息:{}",msg);}}

7.2 回退消息

7.2.1 Mandatory参数

在仅开启了生产者确认机制的情况下,交换机接收到消息后,会直接给消息消费者发送确认消息,如果发现该消息不可路由,那么消息会被直接丢弃,此时生产者是不知道消息被丢弃这个事件的 . 那么如何让无法被路由的消息帮我想办法处理一下?最起码通知我一声,我好自己处理.通过设置mandatory参数可以在消息传递过程中不可达目的地时将消息返回给生产者

配置文件添加参数

 spring.rabbitmq.publisher-returns = true 

7.2.2 消息生产者代码

package com.zjz.springbootrabbitmq.config;import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.ReturnedMessage;
import org.springframework.amqp.rabbit.connection.CorrelationData;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;import javax.annotation.PostConstruct;@Slf4j
@Component
public class MyCallBack implements RabbitTemplate.ConfirmCallback,RabbitTemplate.ReturnsCallback {@Autowiredprivate RabbitTemplate rabbitTemplate;@PostConstructpublic void init(){// 注入rabbitTemplate.setConfirmCallback(this);rabbitTemplate.setReturnsCallback(this);}/*** 交换机确认回调方法* 1.发消息 交换机接受到了消息** @param correlationData 1.1保存回调消息的ID及相关信息* @param b               1.2 交换机收到消息 true* @param s               1.3 s null*                        <p>*                        2.发消息 交换机接收失败了 回调* @param correlationData 2.1 保存回调消息的ID及相关信息* @param b               2.2 交换机收到消息 false* @param s               2.3 s 失败的原因*/@Overridepublic void confirm(CorrelationData correlationData, boolean b, String s) {String id = correlationData != null ? correlationData.getId() : "";if (b) {log.info("交换机已经收到Id为:{}的消息", id);} else {log.info("交换机还未收到Id为:{}的消息,由于原因:{}", id,s);}}// 可以在当消息传递过程中不可达目的地时将消息返回给生产者// 只有不可达目的地的时候 才进行回退@Overridepublic void returnedMessage(ReturnedMessage returnedMessage) {log.error("消息{},被交换机{}退回,退回原因:{},路由Key:{}",new String(returnedMessage.getMessage().getBody()),returnedMessage.getExchange(),returnedMessage.getRoutingKey());}
}

7.3 备份交换机

有了mandatory参数和回退消息,我们获得了对无法传递消息的感知能力,有机会在生产者的消息无法被投递时发现并处理.但有时候,我们并不知道该如何处理这些无法路由的消息,最多打印个日志,然后触发报警,再来手动处理.而通过日志来处理这些无法路由的消息是很不优雅的做法,特别是当生产者所在的服务有多台机器的时候,手动复制日志会更加玛法而且容易出错.而且设置mandatory参数会增加生产者的复杂性,需要添加处理死信队列的文章中,我们提到,可以为队列设置死信交换机来存储那些处理失败的消息,科室这些不可路由消息根本没有机会进入到队列,因此无法使用死信交换机来保存消息.在RabbitMQ中,有一种备份交换机的机制存在,可以很好的应对这个问题.什么是备份交换机呢?备份交换机可以理解为RabbitMQ交换机中的"备胎",当我们为某一个交换机声明一个对应的备份交换机时,就是为它创建一个备胎,当交换机接收到不可路由消息时,将会把这条消息转发到备份交换机中,由备份交换机来进行转发和处理,通常备份交换机的类型为Fanout,这样就能把所有消息都投递到与其绑定的队列中,然后我们在备份交换机下绑定一个队列,这样所有那些原交换机无法被路由的消息,就会都进入这个队列了.当然,我们还可以建立一个报警队列,用独立的消费者来进行监测和报警

7.3.1 代码架构图

7.3.2 修改配置类

package com.zjz.springbootrabbitmq.config;import org.springframework.amqp.core.*;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;/*** 配置类 发布确认(高级)*/
@Configuration
public class ConfirmConfig {// 交换机public static final String CONFIRM_EXCHANGE_NAME = "confirm_exchange";// 队列public static final String CONFIRM_QUEUE_NAME = "confirm_queue";// routingKeypublic static final String CONFIRM_ROUTING_KEY = "key1";// 备份交换机public static final String BACKUP_EXCHANGE_NAME = "backup_exchange";// 备份队列public static final String BACKUP_QUEUE_NAME = "backup_queue";// 报警队列public static final String WARNING_QUEUE_NAME = "warning_queue";// 声明交换机@Bean("confirmExchange")public Exchange confirmExchange() {return ExchangeBuilder.directExchange(CONFIRM_EXCHANGE_NAME).durable(true).withArgument("alternate-exchange",BACKUP_EXCHANGE_NAME).build();}// 声明队列@Bean("confirmQueue")public Queue confirmQueue() {return QueueBuilder.durable(CONFIRM_QUEUE_NAME).build();}// 绑定@Beanpublic Binding confirmQueueBindingconfirmExchange(@Qualifier("confirmQueue") Queue confirmQueue, @Qualifier("confirmExchange") Exchange confirmExchange) {return BindingBuilder.bind(confirmQueue).to(confirmExchange).with(CONFIRM_ROUTING_KEY).noargs();}// 声明 备份交换机@Bean("backupExchange")public FanoutExchange backupExchange(){return new FanoutExchange(BACKUP_EXCHANGE_NAME);}// 声明 备份队列@Bean("backupQueue")public Queue backupQueue(){return QueueBuilder.durable(BACKUP_QUEUE_NAME).build();}// 声明 报警队列@Bean("warningQueue")public Queue warningQueue(){return QueueBuilder.durable(WARNING_QUEUE_NAME).build();}// 备份交换机绑定 备份队列@Beanpublic Binding backupQueueBindingbackupExchange(@Qualifier("backupQueue") Queue backupQueue,@Qualifier("backupExchange") Exchange backupExchange){return BindingBuilder.bind(backupQueue).to(backupExchange).with("").noargs();}// 备份交换机绑定 备份队列@Beanpublic Binding warningQueueBindingbackupExchange(@Qualifier("warningQueue") Queue warningQueue,@Qualifier("backupExchange") Exchange backupExchange){return BindingBuilder.bind(warningQueue).to(backupExchange).with("").noargs();}}

7.3.3 报警消费者

package com.zjz.springbootrabbitmq.consumer;import com.zjz.springbootrabbitmq.config.ConfirmConfig;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.core.Message;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;/*** 报警消费者*/
@Slf4j
@Component
public class WarningConsumer {// 接收报警消息@RabbitListener(queues = ConfirmConfig.WARNING_QUEUE_NAME)public void receiveWarningMsg(Message message){String msg=new String(message.getBody());log.error("报警发现不可路由消息:{}",msg);}
}

7.3.4 测试注意事项

7.4.4 结果分析

mandatory参数与备份交换机可以一起使用的时候,如果两者同时开启,消息究竟何去何从?谁优先级高,经过上面结果显示答案是备份交换机优先级高

八、 RabbitMQ其他知识点

8.1 幂等性

8.1.1 概念

用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会以为你多次点击而产生了副作用.举个最简单的例子,那就是支付,用户购买商品后支付,支付扣款成功,但是返回结果的时候网络异常,此时钱已经扣了,用户再次点击按钮,此时会进行第二次扣款,返回结果成功,用户查询余额发现多扣钱了,流水记录也变成了两条.在以前的单应用系统中,我们只需要把数据操作放入事务中即可,发送错误立即回滚,但是再响应客户端的时候也有可能出现网络终端或者异常等等

8.1.2 消息重复消费

消费者在消费MQ红的消息时,MQ已把消息发送给消费者,消费者在给MQ返回ack时网络终端,故MQ未收到确认消息,该条消息会重新发送给其他的消费者,或者在网络重连后再次发送给该消费者,但实际上该消费者已成功消费了该条消息,造成消费者消费了重复的消息

8.1.3 解决思路

MQ消费者的幂等性的解决一般使用全局ID或者写个唯一标识比如时间戳,或者UUD或者订单消费者消费MQ中的消息也可以利用MQ的该id来判断,或者可按自己的规则生成一个全局唯一id,每次消费消息时用该id先判断该消息是否消费过

8.1.4 消费端的幂等性保障

在海量订单生成的业务高峰期,生产端有可能就会重复发生了消息,这时候消费端就要实现幂等性,这就意味着我们的消息永远不会被消费多次,即使我们收到了一样的消息.业界主流的幂等性有两种操作:a.唯一ID+指纹码机制,利用数据库主键去重,b.利用redis的原子性去实现

8.1.5 唯一ID+指纹码机制

指纹码:我们的一些规则或者时间戳加别的服务给到的维信息码,它并不一定是我们系统生成的,基本都是由我们的业务规则拼接而来,但是一定要保证唯一性,然后就利用查询语句进行判断这个id是否存在数据库中,优势就是实现简单就一个拼接,然后查询判断是否重复;劣势就是在高并发时,如果是单个数据库就会有些人性能瓶颈当然也可以采用分库分表提升性能,但也不是我们最推荐的方式

8.1.6 redis的原子性

利用redis执行setnx命令,天然具有幂等性.从而实现不重复消费

8.2 优先级队列

8.2.1 使用场景

在我们系统中有一个订单催付的场景,我们的客户在天猫下的订单,淘宝会及时将订单推送给我们,如果在用户设定的时间内未支付那么就会给用户推送一条短信提醒,很简单的一个功能对吧,但是,天猫商家对我们来说,肯定是要分大客户和小客户的对吧,比如像苹果,小米这样的大商家一年起码能给我们创造很大的利润,所以理所应当,他们的订单必须得到优先处理,而曾经我们的后端系统是使用redis来存放的定时轮询,大家都知道redis只能用List做一个简简单单的消息队列,并不能实现一个优先级的场景

所以订单量大了后采用RabbitMQ进行改造和优化,如果发现是大客户的订单给一个相对比较高的优先级

8.2.2 如何添加

a.控制台页面添加
在这里插入图片描述

b.队列中代码添加优先级

c.消息中代码添加优先级

d.注意事项
要让队列实现优先级需要做的事情有如下事情:队列需要设置为优先级队列,消息需要设置消息的优先级,消费者需要等待消息已经发送到队列中才去消费因为,这样才有机会对消息进行排序

8.3 惰性队列

8.3.1 使用场景

RabbitMQ从3.6.0版本开始引入了惰性队列的概念.惰性队列会尽可能的将消息存入磁盘中,而在消费者消费到相应的消息时才会被加载到内存中,它的一个重要的设计目标是能够支持更长的队列,即支持更多的消息存储.当消费者由于各种各样的原因(比如消费者下线、宕机亦或者是由于维护而关闭等)而致使长时间内不能消费消息造成堆积时,惰性队列就很有必要了

默认情况下,当生产者将消息发送到RabbitMQ的时候,队列中的消息会尽可能的存储在内存之中,这样可以更加快速的将消息发送给消费者.即使是持久化的消息,在被写入磁盘的同时也会在内存中驻留一份备份.当RabbitMQ需要释放内存的时候,会将内存中的消息换页至磁盘中,这个操作会耗费较长的时间,也会阻塞队列的操作,进而无法接收到新的消息.虽然RabbitMQ的开发者们一直在升级相关的算法,但是效果始终不太理想,尤其是再消息量特别大的时候

8.3.2 两种模式

队列具备两种模式:default和lazy.默认的维default模式,在3.6.0之前的版本无需做任何变更,lazy模式即为惰性队列的模式,可以通过调用channel.queueDeclare方法的时候在参数中设置,也可以通过Policy的方式设置,如果一个队列同时使用这两种方式设置的话,那么Policy的方式具备更高的优先级.如果要通过声明的方式改变已有队列的模式的话,那么只要先删除队列,然后再重新声明一个新的

在队列声明的时候可以通过"x-queue-mode"参数来设置队列的模式,取值"default"和"lazy".下面示例演示了一个惰性队列的声明细节:

Map<String,Object> args = new HashMap<String,Object>();
args.put("x-queue-mode","lazy");
new Queue("myqueue",false,false,args);

九、 RabbitMQ集群

9.1 clustering

9.1.1 使用集群的原因

最开始我们介绍了如何安装及运行RabbitMQ服务,不过这些事单机版的,无法满足目前真实应用的要求.如果RabbitMQ服务器遇到内存崩溃、机器掉电或者主板故障等情况,该怎么办?单台RabbitMQ服务器可以满足每秒1000条消息的吞吐量,那么如果应用需要RabbitMQ服务满足每秒10万条消息的吞吐量呢>购买昂贵的服务器来增强单机RabbitMQ服务器的性能显得捉襟见肘,搭建一个RabbitMQ集群才是解决实际问题的关键

9.1.2 搭建步骤

1.修改3台机器的主机名称
vim /etc/hostname

node1

2.配置各个节点的hosts文件,让各个节点都能相互识别对方
vim /etc/hosts

192.168.88.132 node1
192.168.88.133 node2
192.168.88.134 node3

3.以确保各个节点的cookie文件使用的是同一个值
在node1上执行远程操作命令

scp /var/lib/rabbitmq/.erlang.cookie root@node2:/var/lib/rabbitmq/.erlang.cookiescp /var/lib/rabbitmq/.erlang.cookie root@node3:/var/lib/rabbitmq/.erlang.cookie

4.启动RabbitMQ服务,顺带启动Erlang虚拟机和RabbitMQ应用服务(在三台节点上分别执行以下)

rabbitmq-server -detached

5.在节点2执行

rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@node1
rabbitmqctl start_app

6.在节点3执行

rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@node2
rabbitmqctl start_app

7.集群状态

rabbitmqctl cluster_status

8.需要重新设置用户

创建账号

rabbitmqctl add_user admin 123

设置用户角色

rabbitmqctl set_user_tags admin administrator

设置用户权限

rabbitmqctl set_permissions -p "/" admin "." "." "."

9.解除集群节点(node2和node3机器分别执行)

rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl start_app
rabbitmqctl cluster_status
// (node1机器上执行)
rabbitmqctl forget_cluster_node rabbit@node2 

9.2 镜像队列

9.2.1 使用镜像的原因

如果RabbitMQ集群中只有一个Broker节点,那么该节点的失效将导致整体服务的临时性不可用,并且也可能会导致消息的丢失.可以将所有消息都设置为持久化,并且对应队列的durable属性也设置为true,但是这样仍然无法避免由于缓存导致的问题:因为消息在发送之后被写入磁盘并执行刷盘动作之间存在一个短暂却会产生问题的时间戳.通过 publisherconfirm 机制能够确保客户端知道哪些消息已经存入磁盘,尽管如此,一般不希望遇到因单点故障导致的服务不可用

引入镜像队列(Mirror Queue)的机制,可以将队列镜像到集群中的其他Broker节点上,如果集群中的一个节点失败了,队列自动地切换到镜像中的另一个节点上以保证服务的可用性

9.2.2 搭建步骤

1.启动三台集群节点
2.随便找一个节点添加policy

3.在node1上创建一个队列发送一条消息,队列存在镜像队列

4.停掉node1之后发现node2成为镜像队列


5.就算整个集群只剩下一台机器了 依然能消费队列里面的消息
说明队列里面的消息被镜像队列传递到相应机器里面了

9.3 Haproxy实现负载均衡

9.3.1 整体架构图

9.3.2 Haproxy实现负载均衡

HAProxy 提高高可用性、负载均衡及基于TCPHTTP应用的代理,支持虚拟主机,它是免费、快速并可靠的一种解决方案,包括Twitter,Reddit,StackOverFlow,GitHub在内的多家知名互联网公司在使用.
HAProxy实现了一种事件驱动、单一进程模型,此模型支持非常大的并发连接数

扩展nginx,lvs,haproxy之间的区别:http://www.ha97.com/5646.html

9.3.3 搭建步骤

可参考链接

9.4 Federation Exchange

9.4.1 使用它的原因

(broker 北京),(broker 深圳)彼此之间相距甚远,网络延迟是一个不得不面对的问题.有一个在北京的业务(Client 北京) 需要连接(broker 北京),向其中的交换器exchangeA发送消息,此时的网络延迟很小,(Client 北京)可以迅速将消息发送至exchangeA中,就算在开启了publisherconfirm机制或者事务机制的情况下,也可以迅速收到确认消息.此时又有个深圳的业务(Client 深圳)需要向exchangeA发送消息,那么(Client 深圳)(broker 北京)之间有很大的网络延迟,(Client 深圳)将发送消息至exchangeA会经历一定的延迟,尤其是在开启了publisherconfirm机制或者事务机制的情况下,(Client 深圳)会等待很长的延迟时间来接收(broker 北京)的确认消息,进而必然造成这条发送线程的性能降低,甚至造成一定程度上的阻塞

将业务(Client 深圳) 部署到北京的机房可以解决这个问题,但是如果(Client 深圳)调用的另些服务都部署在深圳,那么又会引发新的延时问题,总不见得将所有业务全部部署在一个机房,那么容灾又何以实现?这里使用Federation插件就可以很好地解决这个问题

9.4.2 搭建步骤

1.需要保证每台节点单独运行
2.在每台机器上开启federation相关插件

rabbitmq-plugins enable rabbitmq_federation
rabbitmq-plugins enable rabbitmq_federation_management

3.原理图(先运行consumer在node2创建fed_exchange)

4.在downstream(node2) 配置upstream(node1)

5.添加 policy

6.成功的前提

9.5 Federation Queue

9.5.1 使用它的原因

联邦队列可以在多个Broker节点(或者集群)之间为单个队列提供均衡负载的功能.一个联邦队列可以连接一个或者多个上游队列(upstream queue),并从这些上游队列中获取消息以满足本地消费者消费消息的需求

9.6 Shovel

9.6.1 使用它的原因

Federation 具备的数据转发功能类似，Shovel 够可靠、持续地从一个 Broker 中的队列(作为源端即source)拉取数据并转发至另一个 Broker 中的交换器(作为目的端，即 destination)。作为源端的队列和作为目的端的交换器可以同时位于同一个Broker，也可以位于不同的 Broker 上。Shovel 以翻译为"铲子"，是一种比较形象的比喻，这个"铲子"可以将消息从一方"铲子"另一方。Shovel 行就像优秀的客户端应用程序能够负责连接源和目的地、负责消息的读写及负责连接失败问题的处理。

9.6.2 搭建步骤

1.开启插件(需要的机器都开启)

rabbitmq-plugins enable rabbitmq_shovel
rabbitmq-plugins enable rabbitmq_shovel_management

2.原理图(在源头发送的消息直接回进入到目的地队列)

3.添加 shovel 源和目的地