幂等性是什么？
简单来说就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的。
我们可以借鉴数据库的乐观锁机制来举个例子
- 首先为表添加一个版本字段version
- 在执行更新操作前呢，会先去数据库查询这个version
- 然后执行更新语句，以version作为条件，例如：
UPDATE T_REPS SET COUNT = COUNT -1，VERSION = VERSION + 1 WHERE VERSION = 1 - 如果执行更新时有其他人先更新了这张表的数据，那么这个条件就不生效了，也就不会执行操作了，通过这种乐观锁的机制来保障幂等性。
消费端-幂等性保障
什么情况下会出现重复消费？
当消费者消费完消息时，在给生产端返回ack时由于网络中断，导致生产端未收到确认信息，该条消息会重新发送并被消费者消费，但实际上该消费者已成功消费了该条消息，这就是重复消费问题。
如何避免消息的重复消费问题？
消费端实现幂等性，就意味着，我们的消息永远不会消费多次，即使我们收到了多条一样的消息
业界主流的幂等性操作：
- 唯一ID + 指纹码机制，利用数据库主键去重
- 利用Redis的原子性去实现
唯一ID+指纹码机制
- 唯一ID + 指纹码机制，利用数据库主键去重
- SELECT COUNT(1) FROM T_ORDER WHERE ID = 唯一ID +指纹码
- 好处：实现简单
- 坏处：高并发下有数据库写入的性能瓶颈
- 解决方案：跟进ID进行分库分表进行算法路由
整个思路就是首先我们需要根据消息生成一个全局唯一的ID，然后还需要加上一个指纹码。这个指纹码它并不一定是系统去生成的，而是一些外部的规则或者内部的业务规则去拼接，它的目的就是为了保障这次操作是绝对唯一的。
将ID + 指纹码拼接好的值作为数据库主键，就可以进行去重了。即在消费消息前呢，先去数据库查询这条消息的指纹码标识是否存在，没有就执行insert操作，如果有就代表已经被消费了，就不需要管了。
对于高并发下的数据库性能瓶颈，可以跟进ID进行分库分表策略，采用一些路由算法去进行分压分流。应该保证ID通过这种算法，消息即使投递多次都落到同一个数据库分片上，这样就由单台数据库幂等变成多库的幂等。
利用Redis的原子性去实现
我们都知道redis是单线程的，并且性能也非常好，提供了很多原子性的命令。比如可以使用 setnx 命令。
在接收到消息后将消息ID作为key执行 setnx 命令，如果执行成功就表示没有处理过这条消息，可以进行消费了，执行失败表示消息已经被消费了。
使用 redis 的原子性去实现主要需要考虑两个点
- 第一：我们是否要进行数据落库，如果落库的话，关键解决的问题是数据库和缓存如何做到原子性？
- 第二：如果不进行落库，那么都存储到缓存中，如何设置定时同步的策略(同步到关系型数据库)？缓存又如何做到数据可靠性保障呢
关于不落库，定时同步的策略，目前主流方案有两种，第一种为双缓存模式，异步写入到缓存中，也可以异步写到数据库，但是最终会有一个回调函数检查，这样能保障最终一致性，不能保证100%的实时性。第二种是定时同步，比如databus同步。
