mq消费端宕机如何保证不重复消费

ookkkks:
这个方案很重，且redis读状态有并发问题。（存在网络交互的场景一定会存在并发场景，这里不要觉得MQ重试有时间间隔就不会一条消息并发，比如消费者在扩容触发的rebalance导致的重复消费；比如消费时一台机器在GC，broker端认为超时重新投递到消费者组里另一台机器，这时候前一台GC机器缓过来了，都有可能并发） 其实对于业务代码来说，是做幂等的问题。做好一锁二判三更新。加db行锁或者分布式锁成功后，再去判断数据的状态（比如需要加积分，就是去查流水；比如是更新状态到完成，那就是校验当前锁完之后读到的状态） 且一般消费也有线程池，这里正常上下线也会最大限度等待线程池内的消费完（优雅停机）； 再比如极端宕机场景，上述比如加select for update行锁，也是在事务里，宕机事务也不会提交，相当于这个流程没有做过，下次重启拉起来继续消费（一锁二判三更新）即可。

biliSectumsempra:
UP请教一下，这套redis放分阶段，mq 手动ACK的方案逻辑换kafka或者rocketmq也是OK的吧？

橙汁最好喝:
一开始我想,如果分段的话,好像也不能解决宕机问题.在redis里更改状态前宕了,实际处理完成了,再次投入也好像会重复消费.后来发现我想错了.处理步骤里加校验,做过的步骤就跳过.从没开始做的步骤开始就行了. 看这类的东西时,脑子老是觉得计算机的数据处理是一下子就完成的(这么描述不太对,但是我不知道该如何描述了),却忽略掉程序是数据的变更和存储,是一步步来的.加上校验,就能知道在哪一步停止了,就从哪一步再继续就好了. 有时候感觉自己就是绕不过弯[笑哭]

【回复】回复 @彪子的刀子 :肯定会重复消费，所以过期时间一定要考虑多久能恢复来进行设置。如果硬件富裕可以考虑给一个特别大的过期时间，然后手动删除
【回复】回复 @酸奶XX : 操作日志，这个我录制了一个若依 plus版的日志系统里的最后两讲有讲过。
【回复】配上实际的场景，一下就明白了[呲牙]
Raven3450:
如果是实际生产的话还是应该要针对ack提交失败的重复消息进行再次手动提交吧

【回复】对的，什么也不做，直接手动提交就可以