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的镜像集群，做好主从备份。当然也可以使用仲裁队列代替镜像集群。做好维护规划。
有不同的观点可以品论区留言
