如何避免消息队列重复消费问题:Redis解决重复消费问题

为了解决RabbitMQ中因手动ack失败可能导致的重复消费问题,本文提出了利用Redis作为解决方案。通过在消费消息前将消息ID存入Redis,并设置状态标记,配合setnx操作防止多个消费者同时处理同一消息。同时,设置Redis key的过期时间以避免死锁风险。通过测试,该方法被证实可行。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

重复消费问题

为了解决消费端因为种种原因而造成的消息丢失问题,我们都知道根源在于因为RabbitMQ的自动ack机制,所以为了避免以上问题,我们会选中手动ack,以确保消息不会因为某些原因而丢失。

但随之而来的也有一个问题如果忘记ack,或者又因为种种原因消费者端没能给RabbitMQ对应ack,无法确认消息已经被消费完了,那这条未被“约束”的消息也许就会被另一个消费者消费,就会造成重复消费问题

如果是进行增加,或者一些非幂等性操作,比如扣费业务,那可就完犊子了

而其中用Redis似乎是对解决重复消费问题的一个比较好的方案:

思路如下:

在消费者消费消息之前,先将消息的id放到Redis中

最明了的方式:设置id为0时为正在执行业务,id为1是为业务执行成功,消费完毕

若手动ack失败,在RabbitMQ将消息交给其他的消费者时,先执行setnx,若key已经存在,则获取他的值,如果值为0,即当前消息还没消费完,当前消费者就什么都不做,如果值为1,则直接ack操作。

当然,这也会有一种非常严重的隐患

若第一个消费者在执行业务时,出现了死锁问题,便会无法获取key的资源

为此我们应该在将消息id放入Redis时,为它设置一个生存时间,也可以叫过期时间,避免在极端情况下的死锁问题。

 

话不多,先来测试实践一下

一、测试依赖导导导

<dependencies>
        <dep
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值