一、消费幂等
当出现消费者对某条消息重复消费的情况时,重复消费的结果与消费一次的结果是相同的,并且多次消费并未对业务系统产生任何负面影响,那么这个消费过程就是消费幂等的。
幂等:若某操作执行多次与执行一次对系统产生的影响是相同的,则称该操作是幂等的。
在互联网应用中,尤其在网络不稳定的情况下,消息很有可能会出现重复发送或重复消费。如果重复的消息可能会影响业务处理,那么就应该对消息做幂等处理。
二、消息重复的场景分析
什么情况下可能会出现消息被重复消费呢?最常见的有以下三种情况:
1、发送时消息重复
当一条消息已被成功发送到 Broker 并完成持久化,此时出现了网络闪断,从而导致 Broker 对 Producer 应答失败。
如果此时 Producer 意识到消息发送失败并尝试再次发送消息,此时 Broker 中就可能会出现两条内容相同并且 Message ID 也相同的消息,那么后续 Consumer 就一定会消费两次该消息。
2、消费时消息重复
消息已投递到 Consumer 并完成业务处理,当 Consumer 给 Broker 反馈应答时网络闪断,Broker 没有接收到消费成功响应。为了保证消息至少被消费一次的原则,Broker 将在网络恢复后再次尝试投递之前已被处理过的消息。此时消费者就会收到与之前处理过的内容相同、Message ID 也相同的消息。
3、Rebalance 时消息重复
当 Consumer Group 中的 Consumer 数量发生变化时,或其订阅的 Topic 的 Queue 数量发生变化时,会触发 Rebalance,此时 Consumer 可能会收到曾经被消费过的消息。
三、通用解决方案
1、两要素
幂等解决方案的设计中涉及到两项要素:幂等令牌,与唯一性处理。只要充分利用好这两要素,就可以设计出好的幂等解决方案。
- 幂等令牌:是生产者和消费者两者中的既定协议,通常指具备唯⼀业务标识的字符串。例如,订单号、流水号。一般由 Producer 随着消息一同发送来的。
- 唯一性处理:服务端通过采用⼀定的算法策略,保证同⼀个业务逻辑不会被重复执行成功多次。例如,对同一笔订单的多次支付操作,只会成功一次。
2、解决方案
对于常见的系统,幂等性操作的通用性解决方案是:
- 首先通过缓存去重。在缓存中如果已经存在了某幂等令牌,则说明本次操作是重复性操作;若缓存没有命中,则进入下一步。
- 在唯一性处理之前,先在数据库中查询幂等令牌作为索引的数据是否存在。若存在,则说明本次操作为重复性操作;若不存在,则进入下一步。
- 在同一事务中完成三项操作:唯一性处理后,将幂等令牌写入到缓存,并将幂等令牌作为唯一索引的数据写入到 DB 中。
第 1 步已经判断过是否是重复性操作了,为什么第 2 步还要再次判断?能够进入第 2 步,说明已经 不是重复操作了,第 2 次判断是否重复?
当然不重复。一般缓存中的数据是具有有效期的。缓存中数据的有效期一旦过期,就是发生缓存穿透,使请求直接就到达了 DBMS。
3、解决方案举例
以支付场景为例:
-
当支付请求到达后,首先在 Redis 缓存中却获取 key 为支付流水号的缓存 value。若 value 不空,则说明本次支付是重复操作,业务系统直接返回调用侧重复支付标识;若 value 为空,则进入下一步操作
-
到 DBMS 中根据支付流水号查询是否存在相应实例。若存在,则说明本次支付是重复操作,业务系统直接返回调用侧重复支付标识;若不存在,则说明本次操作是首次操作,进入下一步完成唯一性处理
-
在分布式事务中完成三项操作:
- 完成支付任务
- 将当前支付流水号作为 key,任意字符串作为 value,通过 set(key, value, expireTime)将数据写入到 Redis 缓存
- 将当前支付流水号作为主键,与其它相关数据共同写入到 DBMS
四、消费幂等的实现
消费幂等的解决方案很简单:为消息指定不会重复的唯一标识。因为 Message ID 有可能出现重复的情况,所以真正安全的幂等处理,不建议以 Message ID 作为处理依据。最好的方式是以业务唯一标识作为幂等处理的关键依据,而业务的唯一标识可以通过消息 Key 设置。
以支付场景为例,可以将消息的 Key 设置为订单号,作为幂等处理的依据。具体代码示例如下:
Message message = new Message();
message.setKey("ORDERID_100");
SendResult sendResult = producer.send(message);
消费者收到消息时可以根据消息的 Key 即订单号来实现消费幂等:
consumer.registerMessageListener(new MessageListenerConcurrently() {
@Override
public ConsumeConcurrentlyStatus consumeMessage (List< MessageExt> msgs, ConsumeConcurrentlyContext context){
for (MessageExt msg : msgs) {
String key = msg.getKeys();
// 根据业务唯一标识Key做幂等处理
// ……
}
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
});
RocketMQ 能够保证消息不丢失,但不能保证消息不重复。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
· 没有源码,如何修改代码逻辑?
· NetPad:一个.NET开源、跨平台的C#编辑器
· 面试官:你是如何进行SQL调优的?
2021-08-08 JavaWeb 之 JSP
2021-08-08 JavaWeb 之 备用
2021-08-08 JavaWeb 之 备用
2021-08-08 JavaWeb 之 备用
2021-08-08 JavaWeb 之 备用
2021-08-08 JavaWeb 之 web项目中的路径问题
2021-08-08 JavaWeb 之 请求与响应的乱码问题