1.什么是rabbitmq
RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件；
采用AMQP（高级消息队列协议）高级消息队列协议的一种消息队列技术,最大的特点就是消费并不需要确保提供方存在,实现了服务之间的高度解耦；
RabbitMQ是一款开源的，Erlang编写的，基于AMQP协议的，消息中间件；
2.为什么要使用rabbitmq
1.在（分布式系统）下具备异步,削峰,负载均衡等一系列高级功能;
2.拥有持久化的机制，进程消息，队列中的信息也可以保存下来。
3.实现消费者和生产者之间的解耦。
4.对于高并发场景下，利用消息队列可以使得同步访问变为串行访问达到一定量的限流，利于数据库的操作。
5.可以使用消息队列达到异步下单的效果，排队中，后台进行逻辑下单。
3.使用rabbitmq的场景
1.服务间异步通信
2.顺序消费
3.定时任务
4.请求削峰
4.如何确保消息正确地发送至RabbitMQ？ 如何确保消息接收方消费了消息？
发送方确认模式：
将信道设置成confirm模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的ID。
一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）。
如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（not acknowledged，未确认）消息。
发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息。
接收方确认机制
接收方消息确认机制：消费者接收每一条消息后都必须进行确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitMQ才能安全地把消息从队列中删除。
这里并没有用到超时机制，RabbitMQ仅通过Consumer的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了Consumer足够长的时间来处理消息。保证数据的最终一致性；
下面罗列几种特殊情况：
如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ会认为消息没有被分发，然后重新分发给下一个订阅的消费者。（可能存在消息重复消费的隐患，需要去重）
如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多的消息。
5.如何避免消息重复投递或重复消费？
在消息生产时，MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重的依据（消息投递失败并重传），避免重复的消息进入队列；
在消息消费时，要求消息体中必须要有一个bizId（对于同一业务全局唯一，如支付ID、订单ID、帖子ID等）作为去重的依据，避免同一条消息被重复消费。
一个解决思路是：保证消息的唯一性，就算是多次传输，不要让消息的多次消费带来影响；保证消息等幂性；
比如：在写入消息队列的数据做唯一标示，消费消息时，根据唯一标识判断是否消费过；
6.消息基于什么传输？
由于TCP连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据。信道是建立在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制。
7.消息如何分发？
若该队列至少有一个消费者订阅，消息将以循环（round-robin）的方式发送给消费者。每条消息只会分发给一个订阅的消费者（前提是消费者能够正常处理消息并进行确认）。
通过路由可实现多消费的功能
channel.basicQos(1);。怎样消费快的，多消费。设置只拉取一条消息。（每个消费者同时只处理一条消息
）
8.消息怎么路由？
从概念上来说，消息路由必须有三部分：交换器、路由、绑定。生产者把消息发布到交换器上；绑定决定了消息如何从路由器路由到特定的队列；消息最终到达队列，并被消费者接收。
消息发布到交换器时，消息将拥有一个路由键（routing key），在消息创建时设定。
通过队列路由键，可以把队列绑定到交换器上。
消息到达交换器后，RabbitMQ会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）。如果能够匹配到队列，则消息会投递到相应队列中；如果不能匹配到任何队列，消息将进入 “黑洞”。
常用的交换器主要分为一下三种：
direct：如果路由键完全匹配，消息就被投递到相应的队列
fanout：如果交换器收到消息，将会广播到所有绑定的队列上
topic：可以使来自不同源头的消息能够到达同一个队列。 使用topic交换器时，可以使用通配符，比如：“*” 匹配特定位置的任意文本， “.” 把路由键分为了几部分，“#” 匹配所有规则等。特别注意：发往topic交换器的消息不能随意的设置选择键（routing_key），必须是由"."隔开的一系列的标识符组成。
9.如何确保消息不丢失？
1.手动ack 手动确定（手动消费则任务完成确认）
2.消息持久化，当然前提是队列必须持久化
RabbitMQ确保持久性消息能从服务器重启中恢复的方式是，将它们写入磁盘上的一个持久化日志文件，当发布一条持久性消息到持久交换器上时，Rabbit会在消息提交到日志文件后才发送响应。
一旦消费者从持久队列中消费了一条持久化消息，RabbitMQ会在持久化日志中把这条消息标记为等待垃圾收集。如果持久化消息在被消费之前RabbitMQ重启，那么Rabbit会自动重建交换器和队列（以及绑定），并重新发布持久化日志文件中的消息到合适的队列。
10.使用RabbitMQ有什么好处？
服务间高度解耦，
异步通信性能高，
流量削峰
消息分发
消息缓冲
…
12.mq的缺点
系统可用性降低
系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好了，人ABCD四个系统好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，你不就完了么。
系统复杂性提高：
硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已
一致性问题：
A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。
---------------------
11.rabbitmq的集群
镜像集群模式
你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。
好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue
12、如何保证RabbitMQ消息的可靠传输？(消息不丢失？)
答：消息不可靠的情况可能是消息丢失，劫持等原因；
丢失又分为：生产者丢失消息、消息列表丢失消息、消费者丢失消息；
生产者丢失消息：（生产者确认消息机制）从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和confirm模式来确保生产者不丢消息；
transaction机制就是说：发送消息前，开启事务（channel.txSelect()）,然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()）,如果发送成功则提交事务（channel.txCommit()）。然而，这种方式有个缺点：吞吐量下降；
confirm模式用的居多：一旦channel进入confirm模式，所有在该信道上发布的消息都将会被指派一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后；
rabbitMQ就会发送一个ACK给生产者（包含消息的唯一ID），这就使得生产者知道消息已经正确到达目的队列了；
如果rabbitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。
消息队列丢数据：消息持久化。
处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。
这个持久化配置可以和confirm机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。
这样，如果消息持久化磁盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。
那么如何持久化呢？
这里顺便说一下吧，其实也很容易，就下面两步
将queue的持久化标识durable设置为true,则代表是一个持久的队列
发送消息的时候将deliveryMode=2
这样设置以后，即使rabbitMQ挂了，重启后也能恢复数据
消费者丢失消息：消费者丢数据一般是因为采用了自动确认消息模式，改为手动确认消息即可！
消费者在收到消息之后，处理消息之前，会自动回复RabbitMQ已收到消息；
如果这时处理消息失败，就会丢失该消息；
解决方案：处理消息成功后，手动回复确认消息。
13、如何保证RabbitMQ消息的顺序性？
答：单线程消费保证消息的顺序性；对消息进行编号，消费者处理消息是根据编号处理消息；
14.如何指定消息的优先级
设置队列的 max priority 参数，RabbitMQ中消息的优先级默认是0，最大值是10
15.消息的持久化是如何实现的
RabbitMQ的持久化分为:交换器的持久化、队列的持久化和消息的持久化
交换器和队列的持久化都是通过在声明时将 durable 参数置为 true 实现的
消息的持久化是在发送消息指定deliveryMode为2实现的
16.如何设置消息的过期时间
设置队列属性，队列中所有消息都有相同的过期时间
对消息本身进行单独设置，每条消息的 TTL 可以不同
如果两种方法一起使用，则消息的 TTL 以两者之间较小的那个数值为准
17.投递失败的消息怎么处理
首先投递失败存在如下两个情况
当交换器无法根据自身的类型和路由键找到符合条件的队列
如果交换器在将消息路由到队列时发现队列上并不存在任何消费者
解决方案：
在生产者投递消息时指定mandatory或者imrnediate参数设为 true 时，RabbitMQ 会把无法投递的消息通过Basic.Return 命令将消息返回给生产者，此时生产者需要调用channel.addReturnListener 来添加 ReturnListener 监昕器实现监听投递失败的消息
如果设置了上方两个参数就要添加ReturnListener 逻辑，使生产者的逻辑变得复杂，RabbitMQ中的备份交换机也可以处理这个问题
以通过在声明交换器(调用 channel.exchangeDeclare 方法)的时候添加alternate-exchange 参数来实现
对于备份交换器，使用时包含几种特殊情况:
如果设置的备份交换器不存在，客户端和 RabbitMQ 服务端都不会有异常出现，此时消息会丢失
如果备份交换器没有绑定任何队列，客户端和 RabbitMQ 服务端都不会有异常出现，此时消息会丢失
如果备份交换器没有任何匹配的队列，客户端和 RabbitMQ 服务端都不会有异常出现，此时消息会丢失
如果备份交换器和 mandatory 参数一起使用，那么 mandatory 参数无效
18.Spring AMQP
低层是rabbitMq
（rabbitTemplate.convertAndSend(转换并发送) ）
AmqpTemplate.convertAndSend(转换并发送)
Spring 帮我们进行了序列化 反序列化。
通过
ObjectOutputStream 序列化
ObjectOutputStream 反序列化
19.**template（模板）代码层面 自动生成交换机队列并绑定持久化。
或者控制台自己创建
19.生产者发送消息重试的设置
20.RabbitMQ消息幂等性之全局唯一ID
MQ解决消息重发--做到幂等性
https://blog.csdn.net/wo1901446409/article/details/97011754
下半场保证幂等性，不重复消费。
生成唯一ID，结合 MYsql 的唯一性。
原文链接：https://blog.csdn.net/wo1901446409/article/details/97389212