1. 幂等性保障
1.1 幂等性介绍
幂等性是数学和计算机科学中某些运算的性质，他们可以被多次应用，而不会改变初始应用的结果
应用程序的幂等性介绍
在应用程序中，幂等性就是指对一个系统进行重复调用（相同参数），不论请求多少次，这些请求对系统的影响都是相同的效果
比如数据库 select 操作时幂等性操作，i++时非幂等性操作
MQ幂等性介绍
对于MQ而言，幂等性是指同一条消息，对系统的影响是相同的
一般消息中间件的消息传输保障分为三个层次
- At most once：最多一次，消息可能会丢失，但绝对不会重复传输
- At least once：最少一次，消息绝对不会丢死，但可能重复传输
- Exactly once：恰好一次，每条消息都肯定会被传输一次且仅传输一次
RabbitMQ支持"最多一次"和"最少一次"
在业务使用中，对于可靠性要求比价高的场景，建议使用"最少一次"，以防止消息丢失，"最多一次"为因为发送过程中的一些问题，导致消息丢失
但是"最少一次"可能会造成消费端会收到重复的消息，也会造成对同一消息进行多次处理，一些不重要的业务还好，对于重要的业务，如果不对重复的消息进行处理，可能会造成严重事故
1.2 解决方案
全局唯一ID
- 为每条消息分配一个唯一的标识，不如UUID或者MQ消息中的唯一ID，一定要保证唯一性
- 消费者收到消息后，先用该id判断该消息是否被消费过了，入股偶已经消费过了，则放弃处理
- 如果未消费过，消费者可以消费消息，业务处理成功后，把唯一ID保存起来
业务逻辑判断
在业务逻辑层面实现消息处理的幂等性
例如：通过检查数据中是否已经存在相关数据记录，或者使用乐观锁机制来避免更新已被其他事务更改的数据，再或者在处理消息之前，先检查相关业务的状态，确保消息对应的操作尚未执行，然后才进行处理，具有根据业务场景来处理
2. 顺序性保障
2.1 顺序性保障介绍
消息的顺序性是指消费者消费的消息和生产者发送的顺序是一致的
很多业务场景下，消息的消费是不用保证顺序的，比如使用MQ实现订单超时处理，但有些业务场景，可能存在多个消息顺序处理的情况，比如用户信息修改，对同一个用户的同一个资料进行修改，需要保证消息的顺序
一些资料显示RabbitMQ的消息能够保证书顺序性是不够眼睛的，在不考虑消息丢失、网络故障等异常情况下，如果只有一个消费者，最好也只有一个生产者的情况下，是可以保证消息的顺序性，如果有多个生产者同时发送消息，无法确认消息到达RabbitMQ Broken 的前后顺序，也就无法办证验证消息的顺序性
哪些情况会打破RabbitMQ的顺序性
- 多个消费者：当队列配置了多个消费者，消息可能会被不同的消费者进行处理，从而导致消息处理的顺序性无法保证
- 网路波动或异常：在消息传递的过程中，如果出现网络波动异常，可能会导致消息确认丢失，从而使得消息重新入队和重新消费，造成顺序性问题
- 消息重试：入股消费者在处理消息后未能及时发送确认，或者确认消息在传输过程中丢失，那么MQ会认为消息未被成功消费而进行重试，这也可能导致消息处理的顺序性问题
- 消息路由问题：在复杂的路由场景下，消息可能会根据路由键被发送到不同的队列，从而无法保证全局的顺序性
- 死信队列：消息因为某些原因被放入死信队列中，死信队列被消费时，无法保证消息的顺序和生产者发送消息的顺序一致
2.2 顺序保障方案
消息顺序性保障分为：局部顺序性保证和全局顺序性保证
局部顺序性通常指的是在一个单个队列内部保证消息的顺序，全局顺序性是指在多个队列或多个消费者之间保证消息的顺序
在实际应用中，全局顺序性很难实现，可以考虑使用业务逻辑保证，比如在消息中嵌入序列号，并在消费端进行排序处理，相对而言，局部顺序性更常见，也更容易实现
RabbitMQ作为一个分布式消息队列，主要优化的是吞吐量和可用性，而不是严格的顺序性保证，如果业务场景确实需要严格的消息顺序，可能需要在应用层面进行额外的设计和实现
单队列单消费者
最简单的方法是使用单个队列，并由单个消费者进行处理，同一个队列中的消息是先进先出的，这是RabbitMQ来帮助我们保证的
分区消费
单个消费者的吞吐太低了，当需要多个消费者以提高处理速度时，可以使用分区消费，把一个队列分割成多个分区，每个分区由一个消费者处理，一次来保持每个分区内消息的顺序性
消息确认机制
使用手动确认机制，消费者在处理完一条消息后，异步地发送确认，这样RabbitMQ才会移除并继续发送吓一跳消息
业务逻辑控制
在某些情况下，即使消息乱序到达，也可以在业务逻辑层面实现控制，比如通过在消息中嵌入序列号，并在消费时根据这些信息来处理
RabbitMQ本身并不会保证全局的严格顺序性，特别是在分布式系统中，在实际应用开发中，根据具体的业务需求，可能需要结合多种策略来实现所需的顺序保证
3. 消息积压问题
3.1 原因分析
消息积压是指在消息队列中，待处理的消息数量超过了消费者处理的能力，导致消息在队列中不断堆积的现象
通常有以下几种原因：
1）消息产生过快：在高流量或者高负载的情况下，生产者以极高的速率发送消息，没超过了消费者的处理能力
2）消费者处理能力不足：消费者处理消息的速度跟不上消息生产的速度，也会导致消息队在队列中积压
- 可能原因：消费端业务逻辑度砸，耗时长
- 消费代码性能低
- 系统资源限制
- 异常处理不当，消费者在处理消息时出现异常，导致消息无法被正确和确认
3）网络问题：因为网络延迟或不稳定，消费者无法及时接收和确认消息，最终导致消息积压
4）RabbitMQ 服务器配置偏低
3.2 解决方案
首先分析造成消息积压的原因，根据原因来调整策略
1）提高消费者效率
- 增加消费者实例的数量
- 优化业务逻辑
- 设置prefetchCount，当一个消费者阻塞时，消息转发到其他未阻塞的队列中
- 消息发生异常时，设置合适的重试策略，或者转入死信队列
2）限制生成者速率，比如流量控制、限流算法等
- 流量控制，在消息生产者中实现流量控制逻辑，根据消费者处理能力动态调整发送速率
- 限流：使用限流工具，为消息发送率设置一个上限
- 设置过期时间，如果消息过期为消费，可以配置死信队列，也避免消息丢失，并减少对主队列的压力
3）资源与配置优化，比如升级RabbitMQ服务器硬件，调整配置参数