【无标题】

@自己总结

MQ的作用是什么？

1.吞吐量提升：无需等待订阅者处理完成，响应更快速
2.故障隔离：服务没有直接调用，不存在级联失败的问题
3.调用间没有阻塞，不会造成无效的资源占用
4.耦合度极低，每个服务都可以灵活的插拔，可替换
5.流量削峰：不管发布事件的流量波动多大，都由Broker接收，订阅者可以按照自己的速度去处理事件

RabbitMQ支持哪些消息模式

rabbitMQ有5种工作模式
1.简单模式：一对一模式，一个生产者，一个队列，一个消费者
2.工作队列模式：一对多模式，一个生产者，一个队列，多个消费者去消费同一个队列中的数据
3.发布订阅模式（Fanout Exchange）：多了一个Exchange的角色，生产者发送消息到交换机上，交换机把消息交给所有绑定在交换机的队列上，队列接收消息，缓存消息，消费者等待消息的到来
4.路由模式（direct EXchange） ：定向，生产者发送消息的时候会传递一个routingkey，队列和交换机通过bindingkey进行绑定，只有routingkey与bindingkey一致的队列才会接收到消息
5.通配符模式（topic exchange）：就是在路由模式的基础上，设置模糊的绑定方式，“*”操作符将“.”视为分隔符，匹配单个字符;“#”通配符没有分块的概念，它将任意“.”均视为关键字的匹配部分，能够匹配多个字符
交换机：只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与交换机绑定，或则没有符合路由规则的队列，那么消息会丢失

消息转换器的作用

messageConverter的作用主要有两个方面。
1.它可以把我们的非标准化的message对象转换成我们的目标message对象，这主要是用在发送消息的时候
2.另一方面它又可以把我们的message对象转化成对应的目标对象，这主要是用在接收消息的时候

RabbitMq怎么保证消息的可靠性？防止消息丢失

可以从3个方面进行分析。

1.生产者发送消息时，出现丢失的情况，可以有以下两种解决方案。

1）方案一：发送消息之前开启RabbitMq的事务，（采用该种方法由于事务机制，会导致系统吞吐量下降，太消耗性能）
2）方案二：开启confirm模式（使用SpringBoot时，在application.yml配置文件中做出相关配置，实现confirm回调接口，生产者发送消息时设置confirm回调）
小结： 事务机制和confirm机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那，但是confirm机制是异步的你发送一个消息之后就可以发送下一个消息，RabbitMQ接收到消息之后会异步回调confirm接口通知你这个消息接受到了，一般生产者这块避免数据丢失，建议使用confirm机制。

2.RabbitMQ本身弄丢消息的情况

1）第一步：创建queue时设置持久化队列，这样可以保证RabbitMQ持久化queue的元数据，此时还是不会持久化queue里的数据
2）第二步：发送消息时将消息的deliveryMode设置为持久化，此时queue里面的消息才会持久化到磁盘
小结:同时设置了queue和message持久化以后，RabbitMQ挂了再重启，也会从磁盘重新恢复queue，恢复这个queue里的数据，保证数据不会丢失。但是就算开启了持久化机制，也有可能出现上面说的消息落盘时服务挂掉的情况。这是可以考虑结合生产者的confirm机制来处理，持久化机制开启后消息只有成功落盘的时候才会通过confirm回调通知生产者，所以可以考虑生产者在生产消息的时候维护一个正在等待消息发送确认的队列，超过一定时间还没从confirm中收到对应消息的反馈，自动进行重发处理

3.消费者弄丢消息的情况

关闭自动ACK，使用手动ACK
RabbitMQ中有一个ACK机制，默认情况下消费者接收到消息，RabbitMQ会自动提交ACK，之后这条消息就不会再发送给消费者了，我们可以更改为手动ACK模式，每次处理完消息之后，再手动ACK一下。不过这样可能会出现刚处理完消息还没手动ACK确认，消费者挂了，导致消息重复消费，不过我们只需要保证幂等性就好了，重复消费也不会造成问题。
步骤一：在springBoot中修改application.yml配置文件更改为手动ACK模式
步骤二：手动实现ack的callback

rabbitMQ怎么防止消息被重复消费？

每个消息用一个唯一标识来区分，消费前先判断标识有没有被消费过，若已消费过。则直接ack

RabbitMQ如何避免消息堆积

1.去优化消费者代码，提交消费能力。减少消费时间
2.可以给消息设置生命周期，如果超时就丢弃掉，可以不让消息大量堆积在消息队列中
3.可以设置队列的最大长度：如果超过了，就无法接收消息到队列中
4.建立新的消息队列，采用订阅模式，消费者同时去订阅新的，还有旧的消息队列,多个消费者同时去消费消息。

RabbitMQ如何保证高可用

使用镜像集群模式

RabbitMQ如何保证顺序消费

rabbitmq的queue本身就是队列，是可以保证消息的顺序投递的
但是消息的顺序消费是另外一回事，所谓的顺序消费意味着是否顺序到达目的地，比如数据库的操作消息，生产者发送3条消息到rabbitmq队列中，3个消费者去消费消息，但是第二条数据被消费者率先执行完，就会影响到我们数据的可靠性。
解决方案：将原来的一个队列，拆分成多个队列，每个队列都有一个自己的消费者，核心就是生产者投递消息的时候根据业务数据关键值来将需要保证先后顺序的同一类数据发送到同一个queue当中，一个队列就一个消费者，在消费者中维护多个内存队列，根据业务数据关键值将消息加入到不同的内存队列中，然后多个真正负责处理消息的线程去各自对应的内存队列中获取消息进行消费