1.幂等性
在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。通俗的讲就一个数据，或者一个请求，给你重复来多次，你得确保对应的数据是不会改变的，不能出错；类似于数据库中的乐观锁机制，如果更新数据库中的一条SQL；在并发场景，为了性能和数据可靠性，会在更新时加上查询时的版本，并且更新这个版本信息。
我们可以借鉴数据库的乐观锁机制来举个例子
- 首先为表添加一个版本字段version
- 在执行更新操作前呢，会先去数据库查询这个version
- 然后执行更新语句，以version作为条件，例如：
UPDATE T_REPS SET COUNT = COUNT -1，VERSION = VERSION + 1 WHERE VERSION = 1 - 如果执行更新时有其他人先更新了这张表的数据，那么这个条件就不生效了，也就不会执行操作了，通过这种乐观锁的机制来保障幂等性。
2.消费端的幂等性保障
1，发送端MQ-client将消息发给服务端MQ-server
2，服务端MQ-server将消息落地
3，服务端MQ-server回ACK给发送端MQ-client
如果3丢失，发送端MQ-client超时后会重发消息，可能导致服务端MQ-server收到重复消息。
此时重发是MQ-client发起的，消息的处理是MQ-server，为了避免步骤2落地重复的消息，对每条消息，MQ系统内部必须生成一个inner-msg-id，作为去重和幂等的依据，这个内部消息ID的特性是：
（1）全局唯一
（2）MQ生成，具备业务无关性，对消息发送方和消息接收方屏蔽
有了这个inner-msg-id，就能保证上半场重发，也只有1条消息落到MQ-server的DB中，实现上半场幂等
在海量订单生成的业务高峰期，生产端有可能就会重复发生了消息，这时候消费端就要实现幂等性，这就意味着我们的消息永远不会被消费多次，即使我们收到了一样的消息。
业界主流的幂等性有两种操作：
1.唯一 ID + 指纹码 机制，利用数据库主键去重
为了应对用户在一瞬间的频繁操作，这个指纹码可能是我们的一些规则或者时间戳加别的服务给到的唯一信息码，它并不一定是我们系统生成的，基本都是由我们的业务规则拼接而来，但是一定要保证唯一性，然后就利用查询语句进行判断这个id是否存在数据库中。
好处就是实现简单，就一个拼接，然后查询判断是否重复。
坏处就是在高并发时，如果是单个数据库就会有写入性能瓶颈
解决方案 ：根据 ID 进行分库分表，对 id 进行算法路由，落到一个具体的数据库，然后当这个 id 第二次来又会落到这个数据库，这时候就像我单库时的查重一样了。利用算法路由把单库的幂等变成多库的幂等，分摊数据流量压力，提高性能。
2.利用redis的原子性去实现
使用 redis 的原子性去实现需要考虑两个点
一是 是否 要进行数据落库，如果落库的话，关键解决的问题是数据库和缓存如何做到原子性？ 数据库与缓存进行同步肯定要进行写操作，到底先写 redis 还是先写数据库，这是个问题，涉及到缓存更新与淘汰的问题
二是如果不落库，那么都存储到缓存中，如何设置定时同步的策略？ 不入库的话，可以使用双重缓存等策略，保障一个消息副本，具体同步可以使用类似 databus 这种同步工具。
1）比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update一下好吧
（2）比如你是写redis，那没问题了，反正每次都是set，天然幂等性
（3）比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的id，类似订单id之类的东西，然后你这里消费到了之后，先根据这个id去比如redis里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个id写redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。
还有比如基于数据库的唯一键来保证重复数据不会重复插入多条，我们之前线上系统就有这个问题，就是拿到数据的时候，每次重启可能会有重复，因为kafka消费者还没来得及提交offset，重复数据拿到了以后我们插入的时候，因为有唯一键约束了，所以重复数据只会插入报错，不会导致数据库中出现脏数据