RabbitMQ 应用问题

一.幂等性问题

幂等性是数学和计算机科学中某些运算的性质，它们可以被多次应用，而不会改变初始应用的结果。

对于MQ而言，幂等性是指同一条消息，多次消费，对系统的影响是相同的。

⼀般消息中间件的消息传输保障分为三个层级：

1）At most once：最多一次，消息可能会丢失，但绝不会重复传输；

2）At least once：最少一次，消息绝不会丢失，但可能会重复传输；

3）Exactly once：恰好一次，每条消息肯定会被传输⼀次且仅传输一次。

RabbitMQ仅支持 最多⼀次 和 最少⼀次。

在业务使用中，对于可靠性要求比较高的场景，建议使用 最少⼀次，以防止消息丢失。最多⼀次会因为消息发送过程中，网络问题，消费出现异常等种种原因，导致消息丢失。

但是 最少⼀次 就会造成⼀个问题，消费端会收到重复的消息，也会造成对同⼀条消息进行多次处理。⼀些不重要的业务还好⼀点，对于重要的业务，如果不对重复的消息进行处理，会造成严重事故。

对于这个问题，解决办法有两种：

1）全局唯一ID

让生产者发送消息时，每条消息加一个全局唯一ID。消费时，将ID加入Redis中。每次消费都从Redis中判断这个消息有没有被消费。

2）业务逻辑判断

在业务逻辑层面实现消息处理的幂等性。例如：通过检查数据库中是否已存在相关数据记录，或者使用乐观锁机制来避免更新已被其他事务更改的数据，再或者在处理消息之前，先检查相关业务的状态，确保消息对应的操作尚未执行，然后才进行处理，具体根据业务场景来处理。

二.顺序性问题

1.介绍

消息的顺序性是指消费者消费的消息和生产者发送消息的顺序是⼀致的。比如生产者发送的消息分别是msg1、msg2、msg3，那么消费者也是按照msg1、msg2、msg3的顺序进行消费的。

以下几种情况会打破RabbitMQ的顺序性：

1）多个消费者：当队列配置了多个消费者时，消息可能会被不同的消费者并行处理，从而导致消息处理的顺序性无法保证；

2）网络波动或异常：在消息传递过程中，如果出现网络波动或异常，可能会导致消息确认(ACK) 丢失，从而使得消息被重新入队和重新消费，造成顺序性问题；

3）消息重试：如果消费者在处理消息后未能及时发送确认，或者确认消息在传输过程中丢失，那么MQ可能会认为消息未被成功消费而进行重试，这也可能导致消息处理的顺序性问题；

4）消息路由问题：在复杂的路由场景中，消息可能会根据路由键被发送到不同的队列，从而无法保证全局的顺序性；

5）死信队列：消息因为某些原因(如消费端拒绝消息)被放入死信队列，死信队列被消费时，无法保证消息的顺序和生产者发送消息的顺序⼀致。

2.解决方案

消息顺序性保障分为：局部顺序性保证和全局顺序性保证。

局部顺序性通常指的是在单个队列内部保证消息的顺序。

全局顺序性是指在多个队列或多个消费者之间保证消息的顺序。

在实际应用中，全局顺序性很难实现，可以考虑使用业务逻辑来保证顺序性，比如在消息中嵌入序列号，并在消费端进行排序处理。相对而言，局部顺序性更常见，也更容易实现。RabbitMQ作为一个分布式消息队列，主要优化的是吞吐量和可用性，而不是严格的顺序性保证。如果业务场景确实需要严格的消息顺序，可能需要在应用层面进行额外的设计和实现。

下面说几个常见的策略：

1）单队列单消费者

最简单的方法是使用单个队列，并由单个消费者进行处理。同一个队列中的消息是先进先出的；

2）分区消费

单个消费者的吞吐太低了，当需要多个消费者以提高处理速度时，可以使用分区消费。把一个队列分割成多个分区，每个分区由⼀个消费者处理，以此来保持每个分区内消息的顺序性；

3）消息确认机制

使用手动消息确认机制，消费者在处理完⼀条消息后，显式地发送确认，这样RabbitMQ才会移除并继续发送下一条消息；

4）业务逻辑控制

在某些情况下，即使消息乱序到达，也可以在业务逻辑层面实现顺序控制。比如通过在消息中嵌入序列号，并在消费时根据这些信息来处理RabbitMQ本身并不保证全局的严格顺序性，特别是在分布式系统中。在实际应用开发中，根据具体的业务需求，可能需要结合多种策略来实现所需要的顺序保证。

三.消息积压

1.介绍

消息积压是指在消息队列(如RabbitMQ)中，待处理的消息数量超过了消费者处理能力，导致消息在队列中不断堆积的现象。

1）消息生产过快

在高流量或者高负载的情况下，生产者以极高的速率发送消息，超过了消费者的处理能力；

2）消费者处理能力不足

消费者处理处理消息的速度跟不上消息生产的速度，也会导致消息在队列中积压。

可能原因有：消费端业务逻辑复杂，耗时长；消费端代码性能低；系统资源限制，如CPU、内存、磁盘I/O等也会限制消费者处理消息的效率；异常处理处理不当，消费者在处理消息时出现异常，导致消息无法被正确处理和确认；

3）网络问题

网络延迟或不稳定，消费者无法及时接收或确认消息，最终导致消息积压；

4）RabbitMQ 服务器配置偏低

消息积压可能会导致系统性能下降，影响用户体验，甚至导致系统崩溃。因此，及时发现消息积压并解决对于维护系统稳定性至关重要。

2.解决方案

遇到消息积压时，首先要分析消息积压造成的原因。根据原因来调整策略。

主要从以下几个方面来解决：

1） 提高消费者效率

a. 增加消费者实例数量，比如新增机器；

b. 优化业务逻辑，比如使用多线程来处理业务；

c. 设置prefetchCount，当⼀个消费者阻塞时，消息转发到其他未阻塞的消费者；

d. 消息发生异常时，设置合适的重试策略，或者转入到死信队列。

2）限制生产者速率，比如流量控制，限流算法等

a. 流量控制：在消息生产者中实现流量控制逻辑，根据消费者处理能力动态调整发送速率；

b. 限流：使用限流工具，为消息发送速率设置⼀个上限；

c. 设置过期时间，如果消息过期未消费，可以配置死信队列，以避免消息丢失，并减少对主队列的压力。

3）资源与配置优化，比如升级RabbitMQ服务器的硬件，调整RabbitMQ的配置参数等。