当前位置：首页 > news >正文

RabbitMQ 幂等性, 顺序性和消息积压

news 2025/9/9 12:25:25

1. 幂等性

1.1 简介

1.2 幂等性的划分

1.3 可能会引发消息重复传输的场景

1.4 如何解决消息重复接收

1.4.1 全局唯一 ID

1.4.2 业务逻辑判断

2. 顺序性

2.1 简介

2.2 会打破顺序性的情况

2.3 如何保证消息的顺序性

3. 消息积压

3.1 简介

3.2 消息积压产生的原因

3.3 如何解决消息积压

1. 幂等性

1.1 简介

幂等性是指对一个系统进行重复调用 (相同的参数), 不论请求多少次, 这些请求对系统的影响都是相同的效果.

比如, 数据库中的 seletc 操作, 不同时间两次查询结果可能不同, 但是这个操作是复合幂等性的. 幂等性指的是对资源的影响, 而不是返回结果. 查询操作对数据资源本身不会产生影响, 之所以结果不同, 可能是因为两次查询之间有其他的操作对资源进行了修改.

比如, i++ 这个操作, 就是非幂等性的. 如果调用方没有控制好逻辑, 一次流程重复调用好几次, 结果就会不同.

日常生活中, 要是我们的支付不遵循幂等性, 那还不完蛋. 所以要保持幂等性

1.2 幂等性的划分

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

At most once : 消息可能会丢失, 但绝不会重复传输 (最多一次)
At least once : 消息绝对不会丢失, 但可能重复传输 (最少一次)
Exactil once : 每条消息肯定会被传输一次且仅传输一次 (恰好一次)

RabbitMQ 支持最少一次和最多一次. 对于恰好一次, RabbitMQ 目前做不到, 而且很多消息中间价都做不到这一点.

在业务使用中, 对于可靠性要求较高的场景, 建议使用最少一次, 以防消息丢失. 最多一次会因为消息发送过程中, 网络问题, 消费出现异常等种种原因, 导致消息丢失. 但是最少一次, 就会使得消费端可能收到重复的消息, 也会造成对同一条消息的多次处理. 对于一些比较重要的业务而言, 重复处理相同的消息, 就会造成严重事故. 例如 : 当用户对一个订单付款之后, 因为网络问题, 付款成功的结果未返回给订单系统, 当用户再次点击付款时, 如果系统未做幂等性处理, 那就会造成两次扣款.

1.3 可能会引发消息重复传输的场景

当生产者给 MQ 发送消息时, MQ 已经收到消息并且返回了 ack, 但由于网络等原因, 生产者没有收到 ack, 那么此时生产者就会再次向 MQ 发送该条消息, 就造成了 MQ 收到了两条重复的消息.
当 MQ 给消费者发送消息时, 消费者已经成功处理了消息并返回了 ack, 但由于网络等原因, MQ没有收到 ack, 于是 MQ 就会再次给消费者发送该条消息, 就造成了消费者收到两条重复的消息.

1.4 如何解决消息重复接收

1.4.1 全局唯一 ID

首先, 为每条消息分配一个唯一标识符, 例如雪花算法, UUID等, 只要能保证唯一性即可.
其次, 消费者收到消息后, 先用唯一标识符判断该消息是否已经消费过, 如果消费过就直接放弃.
最后, 如果没有消费过, 消费者就开始消费信息, 业务处理成功之后, 把唯一标识符保存起来.

可以使用 Redis 的原子性操作 setnx 来保证幂等性, 将唯一标识符作为 key 放到 Redis 中. 消费消息之前, 先 setnx id 1. 如果返回值为 1 (这里成功设置表示我之前没有设置过), 表示之前没有消费过, 正常消费. 返回值为 0 (表示我们已经消费过了), 则表示这条消息之前已消费过, 直接抛弃.

这样消费者就可以根据 Redis 中是否存有接收到的消息的 ID 来判断该消息是否存储过.

1.4.2 业务逻辑判断

可以使用数据库来保证幂等性, 通过检查数据库是否已经存在相关数据记录.
也可以使用锁机制来保证幂等性, 通过使用乐观锁机制来避免更新已经被其他事务更改的数据,
还可以使用相关业务状态来保证幂等性, 在消费者处理消息之前, 先检查相关的业务状, 确保消息对应的操作尚未执行, 然后才进行处理, 具体根据业务场景来做.

2. 顺序性

2.1 简介

消息的顺序性是指消费者消费的消息和生产者发送消息的顺序是一致的. 例如生产者发送的消息依次是msg1, msg2, msg3, 那么消费者消费消息的顺序也必须按照msg1, msg2, msg3 的顺序进行.

比如, 用户需要更改他的个人信息, 这个时候就要保证顺序性, 因为用户可能会修改资料很多次, 但是我们要按照顺序执行, 最后保留的是他最后一次修改的内容. 不然就会和用户所预期的内容不一致.

2.2 会打破顺序性的情况

在没有网络故障, 消息丢失的情况下, 只有一个生产者与一个消费者时, RabbitMQ 可以保证消息的顺序性, 当出现下列情况时, RabbitMQ 就无法保证消息的顺序性.

多个生产者 : 如果有多个生产者同时发送消息, 无法确定消息到达 Broker 的前后顺序, 也就无法验证消息的顺序性.
多个消费者 : 当队列配置了多个消费者时, 消息可能会被不同的消费者并行处理, 然而消费者处理消息的速度是不同的, 从而导致消息处理的顺序性无法保证.
网络波动异常 : 在消息传递的过程中, 如果出现网络波动或异常, 可能会导致 ack (消息确认) 丢失, 从而使得消息被重新入队和重新消费, 造成顺序性问题.
消息重试 : 如果消费者在处理消息后未能及时发送确认, 或者确认消息在传输过程中丢失, 那么 MQ 可能会认为消息未被成功消费而进行重试, 这也可能导致消息处理的顺序性问题.
消息路由问题 : 复杂的路由场景中, 消息可能会根据路由键被发送到不同的队列, 然而队里消费的速度不同, 从而无法保证全局的顺序性.
死信队列 : 消息因为某些原因进入死信队列, 死信队列被消费时, 无法保证消息的顺序和生产者发送消息的顺序一致.