RabbitMQ应用问题 - 幂等性保障

文章目录

幂等性保障


理论

在应用程序中,幂等性简单来讲就是,一个方法无论被调用多少次,都不会改变第一次调用后的结果.

a)幂等案例:

redis 中的 setnx 操作,表示如果 key 不存在,则设置,如果 key 存在则不设置.

假设 key 不存在,那么通过 setnx 操作后,就会成功设置 key,并且在这之后无论多少次调用 setnx,都不会在影响第一次调用 setnx 操作后的结果.

b)非幂等案例:

i++ 这个操作就是非幂等的.

假设 i 初始为 0, 第一次调用后会 i = 1,并且后面每次调用都会影响第一调用后的结果(第二次 i++ ,i 就等于 2).

MQ 的幂等性

a)基本概念

对于 MQ 而言,幂等性就是指统一消息,无论被消费多少次,都不会改变第一次消费后的结果.

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

  • At most once:同一个消息最多被一次消费一次. 消息可能会丢失,但肯定会重复传输.
  • At least once:同一个消息最少被一次消费一次. 消息肯定不会丢失,但可能会重复传输.
  • Exactly once:同一个消息恰好被消费一次. 每条消息肯定肯定不会丢失,并且只传输一次.

Ps:RabbitMQ 支持 At most onceAt least once.(不可能有任何一个 MQ 支持 Exactly once).

因此,对于可靠性要求高的场景,建议使用 At most once

b)哪些场景会导致消息发送重复呢?

  • 生产者发送消息时重复:当开启了生产者确认机制后(例如 confirm),那么当 交换机 成功接收到消息,就会返回 ack,但是由于网络问题,导致生产者没有接收到 ack,那么生产者就会重发消息.
  • 队列给消费者投递时重复:当开启了消费者确认机制后,那么当 消费者 成功接收到消息并正确处理后,就会返回 ack,但是由于网络问题,导致 ack 没有返回给 mq,mq 就会就会重发消息.

幂等性的保障方案

MQ 消费者幂等性的解决方案主要有以下两种:

Note:全局唯一ID 这个方案基本上就覆盖了 90% 的应用场景. 可能网上也还有很多其他资料描述其他的方法,但基本上都是围绕 全局唯一ID 的拓展(本质的思想都一样).

a)全局唯一ID:

  • 给每个消息分配一个唯一ID,比如 UUID、MQ消息唯一ID...
  • 消费者接收到消息后,会先根据 id 判断这个消息是否被消费过(判断 id 是否存在),如果消费过,就放弃处理.
  • 如果没有消费过,消费者就处理消息,处理完成后,就把 id 保存起来(例如 Redis).

Ps:以上过程,使用 Redis 的 setnx 操作就可以保证幂等性 ->

  • setnx 返回 1,说明 key 不存在,设置成功,进而说明之前没有消费,正常消费即可.
  • setnx 返回 0,说明 key 存在,设置失败,进而说明之前消费过,抛弃这条消息.

b)业务逻辑判断:

例如订单系统,通过检查数据库中 status 字段(枚举),是否是已经付款的状态,如果已经付款,就抛弃该消息.

相关推荐
大新新大浩浩1 小时前
arm64适配系列文章-第六章-arm64环境上rabbitmq-management的部署,构建cluster-operator
rabbitmq·arm
躺不平的理查德3 小时前
General Spark Operations(Spark 基础操作)
大数据·分布式·spark
talle20213 小时前
Zeppelin在spark环境导出dataframe
大数据·分布式·spark
渣渣盟3 小时前
大数据开发环境的安装,配置(Hadoop)
大数据·hadoop·分布式
Angindem4 小时前
SpringClound 微服务分布式Nacos学习笔记
分布式·学习·微服务
电脑玩家粉色男孩6 小时前
2、Ubuntu 环境下安装RabbitMQ
linux·rabbitmq
龙仔72512 小时前
离线安装rabbitmq全流程
分布式·rabbitmq·ruby
〆、风神14 小时前
Spring Boot 整合 Lock4j + Redisson 实现分布式锁实战
spring boot·分布式·后端
胡萝卜糊了Ohh15 小时前
kafka
分布式·kafka