RabbitMQ应用问题
一.幂等性
1.简述概念
在应用程序中，幂等性就是指对⼀个系统进行重复调用(相同参数)，不论请求多少次，这些请求对系统的影响都是相同的效果。
举个栗子
比如数据库的 select 操作，不同时间两次查询的结果可能不同，但是这个操作是符合幂等性的。
幂等性指的是对资源的影响，而不是返回结果。查询操作对数据资源本身不会产生影响，之所以结果不同，可能是因为两次查询之间有其他操作对资源进行了修改。.
比如 i++ 这个操作，就是非幂等性的。如果调用方没有控制好逻辑，⼀次流程重复调用好几次，结果就会不同。
2.MQ的幂等性介绍
对于MQ而言，幂等性是指同⼀条消息，多次消费，对系统的影响是相同的。
⼀般消息中间件的消息传输保障分为三个层级：
- At most once:最多⼀次 。消息可能会丢失，但绝不会重复传输。
- At least once:最少⼀次。消息绝不会丢失，但可能会重复传输。
- Exactly once:恰好⼀次。每条消息肯定会被传输⼀次且仅传输⼀次。
RabbitMQ支持"最多⼀次"和"最少⼀次"。
在业务使用中，对于可靠性要求比较高的场景，建议使用"最少⼀次"，以防止消息丢失。"最多⼀次"会因为消息发送过程中，网络问题，消费出现异常等种种原因，导致消息丢失。
幂等性的问题
比如：当用户对⼀个订单付款之后，因为网络问题，付款成功的结果未返回给订单系统，当用户再次点击付款时，如果系统未做幂等性处理，那就会造成两次扣款。
3.解决幂等性问题
(1)全局唯一ID
- 为每条消息分配一个唯一标识符，比如UUID或者MQ消息中的唯⼀ID，但是⼀定要保证唯⼀性。
- 消费者收到消息后，先用该id判断该消息是否已经消费过，如果已经消费过，则放弃处理。
- 如果未消费过，消费者开始消费消息，业务处理成功后，把唯⼀ID保存起来(数据库或Redis等)
(2)业务逻辑判断
在业务逻辑层面实现消息处理的幂等性.
例如：通过检查数据库中是否已存在相关数据记录，或者使用乐观锁机制来避免更新已被其他事务更改的数据。
再或者在处理消息之前，先检查相关业务的状态，确保消息对应的操作尚未执行，然后才进行处理，具体根据业务场景来处理。
二.顺序性保障
1.简单介绍
消息的顺序性是指消费者消费的消息和生产者发送消息的顺序是⼀致的。
比如生产者发送的消息分别是msg1，msg2，msg3，那么消费者也是按照msg1，msg2，msg3的顺序进行消费的。
很多业务场景下，消息的消费是不用保证顺序的，比如使用MQ实现订单超时的处理。但有些业务场景，可能存在多个消息顺序处理的情况。
比如用户信息修改，对同⼀个用户的同⼀个资料进行修改，需要保证消息的顺序。
RabbitMQ的消息能够保障顺序性，并不是百分之百的，在不考虑消息丢失，网络故障等异常的情况下，如果只有⼀个消费者，最好也只有⼀个生产者的情况下，是可以保证消息的顺序性。
2.无法保证顺序性的场景
如果有多个生产者同时发送消息无法确定消息到达RabbitMQ Broker的前后顺序，也就无法验证消息的顺序性。
下面几种常见的场景：
- 多个消费者：当队列配置了多个消费者时，消息可能会被不同的消费者并行处理，从而导致消息处理的顺序性无法保证。
- 网络波动或异常：在消息传递过程中，如果出现网络波动或异常，可能会导致消息确认(ACK)丢失，从而使得消息被重新入队和重新消费，造成顺序性问题。
- 消息重试：如果消费者在处理消息后未能及时发送确认，或者确认消息在传输过程中丢失，那么MQ可能会认为消息未被成功消费而进行重试，这也可能导致消息处理的顺序性问题。
- 消息路由问题：在复杂的路由场景中，消息可能会根据路由键被发送到不同的队列，从而无法保证全局的顺序性。
- 死信队列：消息因为某些原因(如消费端拒绝消息)被放入死信队列，死信队列被消费时，无法保证消息的顺序和生产者发送消息的顺序⼀致。
- 包括但不仅限于以上几种情形会使RabbitMQ消息错序，如果要保证消息的顺序性，需要业务方使用RabbitMQ之后做进⼀步的处理。
3.保障方案
消息顺序性保障分为：局部顺序性保证 和全局顺序性保证。
局部顺序性通常指的是在单个队列内部保证消息的顺序。
全局顺序性是指在多个队列或多个消费者之间保证消息的顺序。
在实际应用中，全局顺序性很难实现，可以考虑使用业务逻辑来保证顺序性，比如在消息中嵌⼊序列号，并在消费端进行排序处理。相对而言，局部顺序性更常见，也更容易实现。
RabbitMQ作为⼀个分布式消息队列，主要优化的是吞吐量和可用性，而不是严格的顺序性保证。如果业务场景确实需要严格的消息顺序，可能需要在应用层面进行额外的设计和实现。
1)单队列消费者
最简单的方法是使用单个队列，并由单个消费者进行处理。同⼀个队列中的消息是先进先出的，这是RabbitMQ来帮助我们保证的。
2)分区消费
单个消费者的吞吐太低了,当需要多个消费者以提高处理速度时，可以使用分区消费。把⼀个队列分割成多个分区，每个分区由⼀个消费者处理，以此来保持每个分区内消息的顺序性。（RabbitMQ本身并不支持分区消费，需要业务逻辑去实现，或者借助spring-cloud-stream来实现）
3)消息确认机制
使用手动消息确认机制，消费者在处理完⼀条消息后，显式地发送确认，这样RabbitMQ才会移除并继续发送下⼀条消息。
4)业务逻辑控制
在某些情况下，即使消息乱序到达，也可以在业务逻辑层面实现顺序控制，比如通过在消息中嵌入序列号，并在消费时根据这些信息来处理RabbitMQ本身并不保证全局的严格顺序性，特别是在分布式系统中。
在实际应⽤开发中，根据具体的业务需求，可能需要结合多种策略来实现所需要的顺序保证。
三.消息积压问题
1.原因分析
消息积压是指在消息队列(如RabbitMQ)中，待处理的消息数量超过了消费者处理能力，导致消息在队列中不断堆积的现象。
通常有以下几种原因：
- 消息生产过快：在高流量或者高负载的情况下，生产者以极高的速率发送消息，超过了消费者的处理能力。
- 消费者处理能力不足：消费者处理处理消息的速度跟不上消息生产的速度，也会导致消息在队列中积压。
可能原因有:
1)消费端业务逻辑复杂,耗时长
2)消费端代码性能低
3)系统资源限制，如CPU、内存、磁盘I/O等也会限制消费者处理消息的效率。
4)异常处理处理不当。消费者在处理消息时出现异常，导致消息无法被正确处理和确认。 - ⽹络问题：因为网络延迟或不稳定，消费者无法及时接收或确认消息，最终导致消息积压。
- RabbitMQ 服务器配置偏低：消息积压可能会导致系统性能下降，影响用户体验，甚至导致系统崩溃。因此，及时发现消息积压并解决对于维护系统稳定性至关重要。
2.解决方案
遇到消息积压时，首先要分析消息积压造成的原因。根据原因来调整策略。
主要从以下几个方面来解决
- 提高消费者效率
a. 增加消费者实例数量，比如新增机器
b. 优化业务逻辑，比如使用多线程来处理业务
c. 设置prefetchCount，当⼀个消费者阻塞时，消息转发到其他未阻塞的消费者。
d. 消息发生异常时，设置合适的重试策略，或者转入到死信队列 - 限制⽣产者速率。比如流量控制，限流算法等。
a. 流量控制：在消息生产者中实现流量控制逻辑，根据消费者处理能力动态调整发送速率
b. 限流：使用限流工具，为消息发送速率设置⼀个上限。
c. 设置过期时间：如果消息过期未消费，可以配置死信队列，以避免消息丢失，并减少对主队列的压⼒ - 资源与配置优化：比如升级RabbitMQ服务器的硬件，调整RabbitMQ的配置参数等
上述这些策略选择时，需要综合考虑业务需求和系统的实际承载能力。