什么是幂等性
用户对于同一操作发起的一次请求或者多次请求的结果是一致的。
我们可以借鉴数据库的乐观锁机制来举个例子
- 首先为表添加一个版本字段
version - 在执行更新操作前呢，会先去数据库查询这个
version - 然后执行更新语句，以
version作为条件，例如：UPDATE T_REPS SET COUNT = COUNT -1，VERSION = VERSION + 1 WHERE VERSION = 1 - 如果执行更新时有其他人先更新了这张表的数据，那么这个条件就不生效了，也就不会执行操作了，通过这种乐观锁的机制来保障幂等性。
MQ的幂等性问题
消费者在消费 MQ 中的消息时，MQ 已把消息发送给消费者，消费者在给 MQ 返回 ack 时网络中断，故 MQ 未收到确认信息，该条消息会重新发给其他的消费者，或者在网络重连后再次发送给该消费者，但实际上该消费者已成功消费了该条消息，造成消费者消费了重复的消息；注意，RabbitMQ 这种消息重试(补偿)机制是默认的。
这种问题的出现主要是由RabbitMQ的消息重试机制导致的
解决方案
如何保证消息幂等性，这在工作或者面试中都是常见的问题，很重要。
主要解决方式有两种
- 唯一ID + 指纹码机制
- Redis原子性保存机制
唯一ID + 指纹码
- 唯一ID + 指纹码机制，利用数据库主键去重
SELECT COUNT(1) FROM T_ORDER WHERE ID = 唯一ID +指纹码- 好处：实现简单
- 坏处：高并发下有数据库写入的性能瓶颈
- 解决方案：跟进ID进行分库分表进行算法路由
整体思路就是，在消息发送时创建一个唯一ID比如UUID，并添加一个指纹码，这个指纹码不一定是系统生成的，可能是一种业务逻辑规则，比如订单就是“TTORDER”字符串
消息消费端接收时，就可以根据这个ID向数据库查询，如果没有插入一条，如果有则不进行接下来的逻辑操作，直接return。
问题：
由于有数据库持久化操作，高并发下会影响性能（其实不会影响太多，对于顶级公司而言）
可以跟进ID进行分库分表策略，采用一些路由算法去进行分压分流。应该保证ID通过这种算法，消息即使投递多次都落到同一个数据库分片上，这样就由单台数据库幂等变成多库的幂等。
Redis原子性保存
因为Redis性能强劲，并且自带一下原子性操作，比如setnx，也是一种解决方案。
即直接将message ID保存到Redis中，不需要在进行唯一ID或指纹码的创建，之后对于消费者而言就和上一种方案一样了，如果存在不进行操作，不存在插入并进行接下来的业务逻辑操作。
使用 redis 的原子性去实现主要需要考虑两个点
- 第一：我们是否要进行数据落库，如果落库的话，关键解决的问题是数据库和缓存如何做到原子性？即数据库和缓存异步保存，因为不同的事务，有可能出现一方存一方未存的情况。
- 第二：如果不进行落库，那么都存储到缓存中，如何设置定时同步的策略(同步到关系型数据库)？缓存又如何做到数据可靠性保障呢
关于第二个问题不落库，定时同步的策略，目前主流方案有两种
- 第一种为双缓存模式，异步写入到缓存中，也可以异步写到数据库，但是最终会有一个回调函数检查，这样能保障最终一致性，不能保证100%的实时性。
- 第二种是定时同步，比如databus同步。
最后，其实对于并发量不是特别特别高的情况下，使用第一种解决方案是比较好的，因为第二种解决方案要考虑的更加全面，实现起来更加复杂，一环没做好，高并发冲击也会出现问题。