RabbitMQ--应用问题

⼀些资料显示RabbitMQ的消息能够保障顺序性, 这是不严谨的. 在不考虑消息丢失, ⽹络故障等异常的情况下, 如果只有⼀个消费者, 最好也只有⼀个⽣产者的情况下, 是可以保证消息的顺序性. 如果有多个生产者同时发送消息, 无法确定消息到达RabbitMQ Broker的前后顺序, 也就无法验证消息的顺序性.

哪些情况可能会打破RabbitMQ的顺序性呢? 下面介绍几种常见的场景:

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

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

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

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

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

包括但不仅限于以上⼏种情形会使RabbitMQ消息错序, 如果要保证消息的顺序性, 需要业务⽅使⽤

RabbitMQ之后做进⼀步的处理

2.2 顺序性保障方案

消息顺序性保障分为: 局部顺序性保证和全局顺序性保证.

局部顺序性通常指的是在单个队列内部保证消息的顺序. 全局顺序性是指在多个队列或多个消费者之间保证消息的顺序.

在实际应用中, 全局顺序性很难实现, 可以考虑使用业务逻辑来保证顺序性, 比如在消息中嵌⼊序列号,并在消费端进行排序处理. 相对而言, 局部顺序性更常见, 也更容易实现.

RabbitMQ作为⼀个分布式消息队列, 主要优化的是吞吐量和可用性, 而不是严格的顺序性保证. 如果业务场景确实需要严格的消息顺序, 可能需要在应用层面进行额外的设计和实现.

接下来说⼀下消息的顺序性保证的常见策略

2.2.1 单队列单消费者

最简单的方法是使用单个队列, 并由单个消费者进行处理. 同⼀个队列中的消息是先进先出的, 这是

RabbitMQ来帮助我们保证的

2.2.2 分区消费

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

⽐如用户修改资料后, 发送⼀条用户资料消息. 消费者在处理时, 需要保证消息发送的先后顺序

但这种场合并不需要保证全局顺序. 只需要保证同⼀个用户的消息顺序消费就可以. 这时候就可以采

⽤把消费按照⼀定的规则, 分为多个区, 每个分区由⼀个消费者处理

RabbitMQ本⾝并不⽀持分区消费, 需要业务逻辑去实现, 或者借助spring-cloud-stream来实现

参考: https://docs.spring.io/spring-cloud-stream/reference/rabbit/rabbit_partitions.html

2.2.3 消息确认机制

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

2.2.4 业务逻辑控制

在某些情况下, 即使消息乱序到达, 也可以在业务逻辑层面实现顺序控制. 比如通过在消息中嵌⼊序列号, 并在消费时根据这些信息来处理

RabbitMQ本⾝并不保证全局的严格顺序性, 特别是在分布式系统中. 在实际应用开发中, 根据具体的业务需求, 可能需要结合多种策略来实现所需要的顺序保证

三、消息积压问题

3.1 原因分析

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

通常有以下⼏种原因：

1. 消息生产过快: 在高流量或者高负载的情况下, 生产者以极高的速率发送消息, 超过了消费者的处理能⼒.

2. 消费者处理能力不足: 消费者处理处理消息的速度跟不上消息⽣产的速度, 也会导致消息在队列中积压.

可能原因有:

1) 消费端业务逻辑复杂, 耗时长

2) 消费端代码性能低

3) 系统资源限制, 如CPU、内存、磁盘I/O等也会限制消费者处理消息的效率.

4) 异常处理处理不当. 消费者在处理消息时出现异常, 导致消息无法被正确处理和确认.

3. 网 络问题: 因为⽹络延迟或不稳定, 消费者⽆法及时接收或确认消息, 最终导致消息积压

4. RabbitMQ 服务器配置偏低

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

3.2 解决方案

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

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

1. 提高消费者效率

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

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

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

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

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

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

b. 限流: 使用限流⼯具, 为消息发送速率设置⼀个上限

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

⼒

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

上述这些策略选择时, 需要综合考虑业务需求和系统的实际承载能力.