消息队列的消费幂等性如何保证

参考大佬文章：消息队列的消费幂等性如何保证

这里先介绍下幂等性：
幂等性：
一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同
比如：一条数据或者一个请求，重复发起多次，我们要确保对应的数据不会受影响。

为什么要保证消费的幂等性？
基于"业务场景"进行分析，比如某些正常情况下，我们是不允许同一个订单重复支付，这种场景就需要保证操作的幂等性。

常用的幂等性保证方法：
1.利用数据库的唯一约束实现幂等
比如将订单表中的订单编号设置为唯一索引，创建订单时，根据订单编号就可以保证幂等
2.利用redis的原子性
每次操作都直接set到redis里面，然后将redis数据定时同步到数据库中
3.多版本（乐观锁）控制
此方案多用于更新的场景下。其实现的大体思路是：给业务数据增加一个版本号属性，每次更新数据前，比较当前数据的版本号是否和消息中的版本一致，如果不一致则拒绝更新数据，成功更新数据的同时将版本号+1

具体做法：
（1）MySQL：比如消费后直接执行insert这种操作是非幂等性的，改进做法 >>> 每次insert之前，我们可以先根据主键去查询，要是该数据已存在就不再执行insert操作，而是执行update操作。
（2）redis：具有天然幂等性，一个key只能有一条数据，不会出现多次消费的情况
（3）复杂订单场景：比如标识某个订单的orderId（唯一）你已经消费过，下次重复消费时，先根据orderId去redis或MySQL中查，如果没有消费过就处理，反之消费过就直接返回，避免重复操作。

总结：
（1）kafka、mq等消息队列没法帮你做到消费端的幂等性，消费端的幂等性得基于业务场景进行实现。
（2）不过消息队列得保证消息不能丢，至少保证消息能够被消费一次（不然消息丢失了，没数据讲啥业务幂等性）
（3）其实重复消费不可怕，可怕的是忽略了重复消费后，该如何保证消费的幂等性？如何防止重复消费 + 即使重复消费也要保证操作的幂等性
（4）是否要保证幂等性，得基于业务进行考量（比如日志记录，就不需要做幂等性操作；订单场景则需要保证幂等性）
补充：在实现消费端处理业务时，要确保消费端是采用手工确认应答机制，而不是自动应答机制。这样能够确保消费端一旦业务处理失败，生产者还能再次发送同个消息给消费端