一 、RabbitMQ概念
1 架构图
2 相关概念
Publisher - ⽣产者：发布消息到RabbitMQ中的Exchange
Consumer - 消费者：监听RabbitMQ中的Queue中的消息
Broker：接收和分发消息的应用，RabbitMQ Server就是 Message Broker，也就是我们的RabbitMQ服务器
Virtual host：出于多租户和安全因素设计的，在RabbitMQ中可以创建出多个虚拟消息服务器VirtualHost。
Connection：publisher／consumer 和 broker 之间的 TCP 连接
channel-信道： 网络信道，几乎所有操作都在channel中进行，channel是消息读写的通道。客户端可以建立多个channel，每个channel表示一个会话任务 ， 信道有特定的功能，比如创建交换机，创建队列。
Exchange - 交换机：和⽣产者建⽴连接并接收⽣产者的消息 ，并且不能保存消息。
Queue - 队列：Exchange会将消息分发到指定的Queue，Queue和消费者进⾏交互 ，队列是可以保存消息的。
Routes - 路由：交换机以什么样的策略将消息发布到Queue。生产者发消息的时候，可以给消息贴一个标签，为了让指定的消费者接收消息。
-
结构解读：
首先安装好的RabbitMQ就是一个Broker，如果我们想将MQ给多个用户使用并且互不影响，那我们就需要将MQ通过虚拟化的方式分割成多个提供MQ的服务，也就是Virtual host，每个Virtual host都有独立的路径，并且和用户绑定。这样我们就可以在自己的世界里发消息了。
-
通信解读：一条消息到底是怎么从生产者到了消费者的？
-
首先生产者通过连接的方式连接到MQ的一个虚拟机，需要知道MQ的ip,端口，虚拟机路径，用户名和密码，准备好了以后就可以建立连接了TCP 连接Connection连接，
-
但是建立和关闭TCP连接是有代价的，频繁的建立关闭TCP连接对于系统的性能有很大的影响，而且TCP的连接数也有限制，这也限制了系统处理高并发的能力。但是，在TCP连接中建立Channel是没有上述代价的，所以我们使用信道changel的方式发送和接受消息。
-
消息进入MQ的第一站是Exchange交换机，交换机的作用：① 接收生产者发送的消息 ②和队列绑定。交换机是不保存信息的。生产者发消息的时候可以指定一个路由键，路由键可以理解为就是给消息贴了一个标签(做标记作用，消费者接收消息的时候有用)
-
消息进入第二站queue，消费者要接收消息，需要一直监听着queue，那么消费者在监听queue的时候需要先指定队列要和那个交换机绑定，绑定的时候也需要指定路由键，如果发消息时的路由键和接收消息时候路由键一样，那么这个消息就会进入到这个队列。
-
最后消费者就拿到消息了。需要说明的一点，所有的交换机和队列创建的时候都是需要起名字的。
-
3 RabbitMQ的通讯
官网介绍：RabbitMQ Tutorials — RabbitMQ
二 案例解释
新建maven工程，Spring整合MQ。因为MQ中有很多概念在boot中是体会不到的，boot屏蔽了很多概念。
1 简单队列模式
这是RabbitMQ最简单的工作方式
-
生产者声明好队列，然后把信息给了MQ默认的交换机，交换机将信息发给队列
-
消费者也声明好队列，然后监听队列获取信息
2 work queue
队列模式： 能者多劳模式
在简单模式的基础上添加了多个消费者，每个消费者添加了等待时间。
生产者一次往队列里投放多条消息，消费者根据能力来消费这里面的所有消息，性能强的消费的消息多，所以是能者多劳
3 订阅发布
平分秋色
交换机类型 fanout
发布订阅，这次使用了交换机，之前的两种方式都是没有显式的声明使用交换机，之前其实用的系统默认的交换机。
这次使用了交换机，但是 没有使用路由键。只要和交换机绑定了的对了都可以接受到消息，也就是上图两个队列中可以收到相同的消息。
4 .路由 routing
暗送秋波
交换机direct
-
在⽣产者发送消息时指明routing-key
-
在消费者声明队列和交换机的绑定关系时，指明routing-key
-
解决的问题是：
-
因为交换机和两个队列都绑定了，但是为了给队列里发送的消息不一样，也就是区分给那个队列发什么样 的消息，就有了routing key的概念。发消息的时候指定一下路由键，接收消息的时候队列要和交换机绑定，这时候也需要指定路由键，如果这两次的路由键一样，那么这个消息就放着这个队列里面
-
5 通配符模式
你的心思我要
交换机是 topic
-
因为路由模式里是精确匹配，比较局限，使用通配符方式，通配符，提⾼了匹配的范围，扩展业务。
-
Routingkey 一般都是有一个或多个单词组成，多个单词之间以”.”分割，例如： item.insert
-
通配符规则：# 匹配一个或多个词，* 匹配不多不少恰好1个词，例如：item.# 能够匹配 item.insert.abc 或者 item.insert，item.* 只能匹配 item.insert。
三 消息的可靠性投递
1 什么是消息的可靠性投递
-
保证消息一定能发到消息队列中
-
细节
-
保证mq节点成功接受消息
-
消息发送端需要接受到mq服务端接收到消息的确认应答
-
完善的消息补偿机制，发送失败的消息可以再感知并二次处理
-
-
RabbitMQ消息投递路径
-
生产者-->交换机-->队列-->消费者
-
通过两个点的控制，保证消息的可靠性投递
-
生产者到交换机 confirmCallback
-
交换机到队列 returnCallbakc
-
-
-
建议
-
开启消息确认机制以后，保证了消息的准确送达，但由于频繁的确认交互，RabbitMQ的整体效率变低，吞吐量下降严重，不是非常重要的消息不建议用消息确认机制
-
2 confirmCallback
-
机制：
生产者投递消息以后，如果Broker收到消息以后，会给生产者一个ACK，生产者通过ACK可以确认这条消息是否成功发送到Broker。
-
开启confirmCallback
spring.rabbitmq.publisher-confirm-type: correlated
-
发送代码
@Test
void confirm(){rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {/*** 消息到交换机的确认* @param correlationData 配置信息* @param ack 交换机确认 true消息接受成功 false消息接受失败* @param cause 消息发送失败原因*/@Overridepublic void confirm(CorrelationData correlationData, boolean ack, String cause) {System.out.println("ConfirmCallback==========>");System.out.println("correlationData==========>"+correlationData);System.out.println("ack==========>"+ack);System.out.println("cause==========>"+cause);if(ack){System.out.println("发送成功");// 更新数据库 成功}else {System.out.println("发送失败,日志或数据库纪录");// 更新数据库 失败}}});rabbitTemplate.convertAndSend(RabbitConfig.EXCHANGE_NAME,"xinzhi.15","老韩学it");
}
-
模拟失败场景,修改发送时候交换机名称
2 returnCallback
-
return机制保证消息在rabbitmq中能够成功的投递到队列⾥
-
两种模式：
-
交换机到队列不成功，则丢弃消息（默认）
-
交换机到队列不成功，返回生产者，触发returnCallback
-
-
开启returnCallback，交换机到队列的可靠性投递
spring.rabbitmq.publisher-returns=true
-
修改投递到队列失败的策略
spring.rabbitmq.template.mandatory=true
-
发送消息验证.
@Test void returnCallback(){rabbitTemplate.setReturnsCallback(new RabbitTemplate.ReturnsCallback() {@Overridepublic void returnedMessage(ReturnedMessage returned) {int code = returned.getReplyCode();System.out.println("code==>"+code);System.out.println("returned==>"+returned);}});rabbitTemplate.convertAndSend(RabbitConfig.EXCHANGE_NAME," "," "); }
-
发送消息以后，没有任何提示，我们修改路由键
四 消息确认
1 背景
保证消息从队列到消费者的过程。
2 ACK介绍
-
消费者从RabbitMQ中获取消息并且处理完成以后，反馈给RabbitMQ，RabbitMQ收到确认消息以后才能把消息从队列中删除
-
消费者在处理消息的时候出现了网络不稳定、服务器异常等情况，那么就不会有ACK反馈，RabbitMQ认为这个消息没有正常消费，就将这个消息放回队列里面
-
只有当消费者正确发送ack以后，RabbitMQ才会把消息从队列中删除
-
消息的ack确认机制默认是打开的，消息如果未被进行ack的消息确认机制，这条消息将被锁定
3 确认方式
-
自动
-
手动manual
spring.rabbitmq.listener.simple.acknowledge-mode=manual
-
发送消息，并且开启监听模式，虽然消息被消费了，但是因为开启了手动确认模式配置，但是代码里没有手动确认所以队列里的消息不会删除
-
代码中开启确认机制
channel.basicAck(msgTag,false);
-
消息拒绝
// false 一次拒绝一条 true 重新回到队列
channel.basicNack(msgTag,false,true);结果就会看到控制台一直接受消息，因为对列有消息就会被监听到，监听以后拒绝了又放到队列里面，然后 又监听...
-
DeliveryTag
表示消息投递的序号，每次消费消息或者消息重新投递以后，DeliveryTag都会+1
-
basicReject
也是消息拒绝的，一次只能拒绝一条消息，也可以设置是否重新回如队列
