一、幂等定义
在编程中，一个幂等操作的特点是其任意屡次执行所产生的影响均与一次执行的影响雷同。
二、幂等分类
1. 请示层面的幂等，产生的起因是申请重试。没有重试则没有申请层解决。
从架构层面
只有数据拜访层须要做幂等，那么数据拜访层对外提供的接口能够如下分类
insert 自增主键，不幂等
业务主键幂等采纳业务主键幂等
select 幂等
update age=11 幂等 绝对值
age++ 不幂等 相对值
1. 减少条件 and age =10（乐观锁形式，版本控制 + 自旋）2.age =11 改成绝对值
delete where id=1 幂等 绝对值
where id in bottom 10 不幂等 相对值
反复提交
2. 业务层面
第一次申请不晓得后果（比方超时）或者失败的异常情况下，发动屡次申请，目标是屡次确认第一次申请胜利，却不会因屡次申请而呈现屡次的状态变动。
比方：同一用户只能同类商品下一笔订单
商品超卖：
MQ 生产端去重
共享状态，比方订单 id
解决文案：分布式锁
三、分布式事务中的幂等
在没有 ACID 的状况下解决数据一致性的常见技巧是应用弥补。这种办法与 ACID 事务不同，你能够具备不统一的中间状态。在业务解决中通常能够忍耐这些临时的不统一，只有能确保最终清理它们并使零碎复原到统一状态。这称为最终一致性，这是分布式系统中的一个重要概念。
最终的一致性通常会产生更好的性能，更简略的操作和更好的可伸缩性，同时帮忙程序员了解更简单的数据模型。
在实现最终一致性时会呈现音讯反复发送问题。理论利用状况是，在分布式系统中确切地保障消息传递是不可能的。实现一次精确的消息传递齐全基于音讯生成者从音讯使用者那里接管到确认音讯。然而，ACK 自身是不牢靠的，因为它也将通过网络流传。在解决音讯后，因为网络问题或消费者解体，很可能会失落 ACK。
任何通过网络进行通信，都可能会呈现三种故障情景：
- 该申请尚未达到服务提供商
- 申请已达到服务提供商，但在解决期间出现异常
- 服务提供程序处理了申请，但响应失落了
那么如何能力实现精确的消息传递？它的答案是幂等性！你必须使你的消费者操作具备幂等性。幂等性 就是用户对于同一操作发动的一次申请或者屡次申请的后果是统一的，不会因为屡次点击而产生了副作用。举个最简略的例子，用户购买商品后领取，领取扣款胜利，然而返回后果的时候网络异样，此时钱曾经扣了，用户再次点击按钮，此时不应该进行第二次扣款。
也就是说用幂等来保障分布式事务。