文章目录
- 一：什么是幂等性问题
- 二：什么原因导致幂等性问题？
- 三 ：幂等性解决办法
一：什么是幂等性问题
幂等性是对于写操作来说的，一个写操作，不论重复执行多少次，结果总是一致的，例如：
一个接口如果幂等，不管被调多少次，只要参数不变，结果也不变。
一个MQ消息，不论收到多少次，只有一个消息能执行，结果也是不变的。
二：什么原因导致幂等性问题？
-
底层
网络阻塞和延迟的问题：- 网络原因导致客户端这里不能及时收到服务端的响应，这时候用户会重复点击、重复请求
- MQ中，客户端也有重试机制，如果投递失败或者超时，则会重新投递，对于服务端来说就会收到重复发过来的消息。RPC调用也是同理，都有重试机制。
-
用户层面的重复操作：- 用户点击下单按键，在没有收到服务端响应之前，用户还可以重复去点击
- 用户人工强制退出或者App闪退，之后重新打开重新下单。
三 ：幂等性解决办法
无非增删改查操作，一下分析基于接口幂等做出的分析。
-
全局唯一ID（通用方案）
根据业务的操作和内容生成一个全局ID，在执行操作前先根据这个全局唯一ID是否存在，来判断这个操作是否已经执行。
如果不存在则把全局ID，存储到Redis。如果存在则表示该方法已经执行，在redis层面实现拦截。
题外话：全局ID，保证唯一性即可。例如：uuid、雪花算法、业务字段+时间戳、业务本身的唯一约束。像接口的幂等：唯一ID可以选择方法名啊参数啊业务字段啊这些拼接形成，只要能唯一标识是*** 调用 ***接口即可。像MQ消息的唯一ID：可以选择唯一的业务字段啊等等来唯一标识此条消息即可。 -
去重表（唯一索引）：针对
insert
这种情况是针对有唯一字段的插入操作，不如：一个订单只会支付一次，订单ID可以作为唯一标识，这时候可以去增加一张去重表，并且吧唯一标识作为唯一索引，实现上：在创建支付单据时将订单ID也写入去重表，放在一个事务中，如果重复创建，数据库会抛唯一索引异常，操作就会回滚，也就是一个订单只会支付一次。 -
插入或者更新（
InsertOrUpdate）
这种方法插入并且有唯一索引的情况，比如我们要关联商品品类，其中商品的ID和品类的ID可以构成唯一索引，并且在数据表中也增加了唯一索引。这时就可以使用InsertOrUpdate操作。 -
版本号（
update）
这种方法适合在更新的场景中，比如我们要更新商品的名字，这时我们就可以在更新的接口中增加一个版本号，来做幂等：
boolean updateGoodsName(int id,String newName,int version);
实现上：
update goods set name=#{newName},version=#{version} where id=#{id} and version<${version}
- 状态机控制（
update）
这种方法适合在有状态机流转的情况下，比如就会订单的创建和付款，订单的付款肯定是在之后，这时可以通过在设计状态字段时，使用int类型，并且通过值类型的大小来做幂等，比如订单的创建为0，付款成功为2，付款失败为1。付款成功可以修改未付款的或者付款失败的，付款失败只能修改未付款的
update goods_order set status=#{status} where id=#{id} and status<#{status}
