关于幂等性方案的疑惑点

Question

1.老师您好，视频中的统一ID生成服务是业务ID（比如订单ID），还是说是消息ID？个人认为应该说的是业务ID，那么MSGDB中存储的是不是业务ID？
2.是不是消费端成功处理了消息后，还要把MSGDB中对应记录的状态置为成功？
3.假设消费者处理消息抛异常了，但是MSGDB中已经入库了。那么这个时候我们应该如何让消费端重新去处理这条消息？我个人想的一个办法是消费端用一个定时任务专门去查询MSGDB中的记录，如果发现记录中有失败的记录，则让消费端重做。
4.然后视频看到这里其实一直期待老师讲一讲如何配合redis来保证幂等性的，但是老师说用双缓存策略来保证，这里讲的有一点抽象，老师能否讲的更详细一点，谢谢

Answer 1

阿神 2019-08-15 21:26:40

首先msgdb和消费端没有关系蛤，消费端幂等就是业务ID去做的，msgdb就是生产端做可靠性投递去做的。至于说mq的一系列问题，你可以这样理解。就解决两个事情
一定要分开思考，因为mq帮我们做了解耦，也就是生产端可靠性投递，消费端幂等。生产端只关注消息是不是100%到达mq，也就是mq与数据库一个原子性一致性问题。需要利用定时任务去检查失败或者中间状态，然后去补偿，生产端和消费端没有任何关系的，如果保障了可靠性投递，接下来就是幂等处理了，如果最后你想要消费失败以后，和生产端的数据保持一致，那么这又是另外一个问题，即，最终一致性，可以通过消费端主动发起一些回滚的请求，通知到生产端去做最终一致性的补偿。这个和mq本事没有关系了，是另外一层面上的问题。
采用redis与数据库保障一致性也是一样，都是要做合理的兜底，最终一致性处理的。