【RabbitMQ】回顾下RabbitMQ知识点，还记得哪些？

回顾下RabbitMQ知识点，还记得哪些？

什么是RabbitMQ?

RabbitMQ是一个消息代理 - 一个消息系统的媒介。
RabbitMQ服务器是用Erlang语言编写的，而集群和故障转移是构建在开放电信平台框架上的。
它可以为你的应用提供一个通用的消息发送和接收平台，并且保证消息在传输过程中的安全。

为什么要选择RabbitMQ,不选其他MQ?

kafka是以吞吐量高而闻名，不过其数据稳定性一般，而且无法保证消息有序性。如果公司的项目中使用了MQ作为日志收集，建议选择使用RabbitMQ。

阿里巴巴的RocketMQ基于Kafka的原理，弥补了Kafka的缺点，继承了其高吞吐的优势，其客户端目前以Java为主。但是从开源产品的稳定性而言，还是选择RabbitMQ比较好一些。

RabbitMQ基于面向并发的语言Erlang开发，虽然吞吐量不如Kafka，但是体量不大的项目够用了。而且消息可靠性较好，并且消息延迟极低，集群搭建比较方便。支持多种协议，并且有各种语言的客户端，比较灵活。Spring对RabbitMQ的支持也比较好，使用起来比较方便，开发周期快速。

RabbitMQ社区比较完善，有些疑难问题可以在社区里面找到解决问题的方案，节省时间。

使用MQ可以解决那些问题？

RabitMQ有很多特点：
可靠性: RabbitMQ提供了多种技术可以让你在性能和可靠性之间进行权衡。这些技术包括持久性机制、投递确认、发布者证实和高可用性机制。

灵活的路由: 消息在到达队列前是通过交换机进行路由的。RabbitMQ为典型的路由逻辑提供了多种内置交换机类型。如果你有更复杂的路由需求，可以将这些交换机组合起来使用，你甚至可以实现自己的交换机类型，并且当做RabbitMQ的插件来使用。

集群: 在相同局域网中的多个RabbitMQ服务器可以聚合在一起，作为一个独立的逻辑代理来使用。

联合：对于服务器来说，它比集群需要更多的松散和非可靠链接。为此RabbitMQ提供了联合模型。

高可用的队列：在同一个集群里，队列可以被镜像到多个机器中，以确保当其中某些硬件出现故障后，你的消息仍然安全。

多协议：RabbitMQ 支持多种消息协议的消息传递。

广泛的客户端：只要是你能想到的编程语言几乎都有与其相适配的RabbitMQ客户端。

可视化管理工具：RabbitMQ附带了一个易于使用的可视化管理工具，它可以帮助你监控消息代理的每一个环节。

追踪：如果你的消息系统有异常行为，RabbitMQ还提供了追踪的支持，让你能够发现问题所在。

插件系统：RabbitMQ附带了各种各样的插件来对自己进行扩展。你甚至也可以写自己的插件来使用。

最重要的还有以下几点：
解耦合：将几个业务关联的微服务调用修改为基于MQ的异步通知，可以解除微服务之间的业务耦合。同时还提高了业务性能。

流量削峰：将突发的业务请求放入MQ中，作为缓冲区。后端的业务根据自己的处理能力从MQ中获取消息，逐个处理任务。流量曲线变的平滑很多

延迟队列：基于RabbitMQ的死信队列或者DelayExchange插件，可以实现消息发送后，延迟接收的效果。

RabbitMQ如何保证消息的有序性？

RabbitMQ是队列存储，天然具备先进先出的特点，只要消息的发送是有序的，那么理论上接收也是有序的。不过当一个队列绑定了多个消费者时，可能出现消息轮询投递给消费者的情况，而消费者的处理顺序就无法保证了。

因此，要保证消息的有序性，需要做的下面几点：

如何防止MQ消息被重复消费？

消息重复消费的原因多种多样，不可避免。所以只能从消费者端入手，只要能保证消息处理的幂等性就可以确保消息不被重复消费。

而幂等性的保证又有以下三种方案：

RabbitMQ如何确保消息的不丢失？

RabbitMQ针对消息传递过程中可能发生问题的各个地方，给出了针对性的解决方案：

• 生产者发送消息时可能因为网络问题导致消息没有到达交换机： - RabbitMQ提供了publisher confirm机制 - 生产者发送消息后，可以编写ConfirmCallback函数- 消息成功到达交换机后，RabbitMQ会调用ConfirmCallback通知消息的发送者，返回ACK- 消息如果未到达交换机，RabbitMQ也会调用ConfirmCallback通知消息的发送者，返回NACK- 消息超时未发送成功也会抛出异常
• 消息到达交换机后，如果未能到达队列，也会导致消息丢失： - RabbitMQ提供了publisher return机制 - 生产者可以定义ReturnCallback函数- 消息到达交换机，未到达队列，RabbitMQ会调用ReturnCallback通知发送者，告知失败原因
• 消息到达队列后，MQ宕机也可能导致丢失消息： - RabbitMQ提供了持久化功能，集群的主从备份功能 - 消息持久化，RabbitMQ会将交换机、队列、消息持久化到磁盘，宕机重启可以恢复消息- 镜像集群，仲裁队列，都可以提供主从备份功能，主节点宕机，从节点会自动切换为主，数据依然在
• 消息投递给消费者后，如果消费者处理不当，也可能导致消息丢失 - SpringAMQP基于RabbitMQ提供了消费者确认机制、消费者重试机制，消费者失败处理策略： - 消费者的确认机制： - 消费者处理消息成功，未出现异常时，Spring返回ACK给RabbitMQ，消息才被移除- 消费者处理消息失败，抛出异常，宕机，Spring返回NACK或者不返回结果，消息不被异常- 消费者重试机制： - 默认情况下，消费者处理失败时，消息会再次回到MQ队列，然后投递给其它消费者。Spring提供的消费者重试机制，则是在处理失败后不返回NACK，而是直接在消费者本地重试。多次重试都失败后，则按照消费者失败处理策略来处理消息。避免了消息频繁入队带来的额外压力。- 消费者失败策略： - 当消费者多次本地重试失败时，消息默认会丢弃。- Spring提供了Republish策略，在多次重试都失败，耗尽重试次数后，将消息重新投递给指定的异常交换机，并且会携带上异常栈信息，帮助定位问题。

RabbitMQ如何避免消息堆积？

消息堆积问题产生的原因往往是因为消息发送的速度超过了消费者消息处理的速度。因此解决方案无外乎以下三点：提高消费者处理速度，增加更多消费者， 增加队列消息存储上限。
1）提高消费者处理速度
消费者处理速度是由业务代码决定的，所以这个时候能做的事情主要包括：

• 尽可能优化业务代码，提高业务性能
• 接收到消息后，开启线程池，并发处理多个消息

优点：成本低，改改代码即可。
缺点：开启线程池会带来额外的性能开销，对于高频、低时延的任务不合适。推荐任务执行周期较长的业务。在定方案前做好业务需求分析相关的工作。

2）增加更多消费者
一个队列绑定多个消费者，共同争抢任务，自然可以提供消息处理的速度。
优点：能用钱解决的问题都不是问题，实现简单粗暴。
缺点：问题是没有钱。成本太高了。

3）增加队列消息存储上限

在RabbitMQ的1.8版本后，加入了新的队列模式：Lazy Queue

这种队列不会将消息保存在内存中，而是在收到消息后直接写入磁盘中，理论上没有存储上限。可以解决消息堆积问题。
优点：磁盘存储更安全；存储无上限；避免内存存储带来的Page Out问题，性能更稳定；
缺点：磁盘存储受到IO性能的限制，消息时效性不如内存模式，但影响不大。
所以根据实际的业务情况提前做好规划和预防。

如何保证RabbitMQ的高可用？

要实现RabbitMQ的高可用，要做到下面两点：
第一点：做好交换机、队列、消息的持久化。
第二点： 搭建RabbitMQ的镜像集群，做好主从备份。当然也可以使用仲裁队列代替镜像集群。做好维护规划。