幂等性解决办法

一：什么是幂等性问题

幂等性是对于写操作来说的，一个写操作，不论重复执行多少次，结果总是一致的，例如：
一个接口如果幂等，不管被调多少次，只要参数不变，结果也不变。
一个MQ消息，不论收到多少次，只有一个消息能执行，结果也是不变的。

二：什么原因导致幂等性问题？

• 底层网络阻塞和延迟的问题：

  • 网络原因导致客户端这里不能及时收到服务端的响应，这时候用户会重复点击、重复请求
  • MQ中，客户端也有重试机制，如果投递失败或者超时，则会重新投递，对于服务端来说就会收到重复发过来的消息。RPC调用也是同理，都有重试机制。

• 用户层面的重复操作：

  • 用户点击下单按键，在没有收到服务端响应之前，用户还可以重复去点击
  • 用户人工强制退出或者App闪退，之后重新打开重新下单。

三 ：幂等性解决办法

无非增删改查操作，一下分析基于接口幂等做出的分析。

1. 全局唯一ID（通用方案）
   根据业务的操作和内容生成一个全局ID，在执行操作前先根据这个全局唯一ID是否存在，来判断这个操作是否已经执行。
   如果不存在则把全局ID，存储到Redis。如果存在则表示该方法已经执行，在redis层面实现拦截。
   题外话：全局ID，保证唯一性即可。例如：uuid、雪花算法、业务字段+时间戳、业务本身的唯一约束。像接口的幂等：唯一ID可以选择方法名啊参数啊业务字段啊这些拼接形成，只要能唯一标识是*** 调用 ***接口即可。像MQ消息的唯一ID：可以选择唯一的业务字段啊等等来唯一标识此条消息即可。

2. 去重表（唯一索引）：针对insert
   这种情况是针对有唯一字段的插入操作，不如：一个订单只会支付一次，订单ID可以作为唯一标识，这时候可以去增加一张去重表，并且吧唯一标识作为唯一索引，实现上：在创建支付单据时将订单ID也写入去重表，放在一个事务中，如果重复创建，数据库会抛唯一索引异常，操作就会回滚，也就是一个订单只会支付一次。

3. 插入或者更新（InsertOrUpdate）
   这种方法插入并且有唯一索引的情况，比如我们要关联商品品类，其中商品的ID和品类的ID可以构成唯一索引，并且在数据表中也增加了唯一索引。这时就可以使用InsertOrUpdate操作。

4. 版本号（update）
   这种方法适合在更新的场景中，比如我们要更新商品的名字，这时我们就可以在更新的接口中增加一个版本号，来做幂等：

boolean updateGoodsName(int id,String newName,int version);

实现上：

update goods set name=#{newName},version=#{version} where id=#{id} and version<${version}

5. 状态机控制（update）
   这种方法适合在有状态机流转的情况下，比如就会订单的创建和付款，订单的付款肯定是在之后，这时可以通过在设计状态字段时，使用int类型，并且通过值类型的大小来做幂等，比如订单的创建为0，付款成功为2，付款失败为1。付款成功可以修改未付款的或者付款失败的，付款失败只能修改未付款的

update goods_order set status=#{status} where id=#{id} and status<#{status}