幂等性

幂等性

幂等这个词原自数学，某一元运算为幂等时，其作用在任一元素两次后会和其作用一次的结果相同。在HTTP/1.1中，对幂等性的定义是：一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外），即第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。这里的副作用是不会对结果产生破坏或者产生不可预料的结果。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。

幂等性需要关注的重点：

1. 幂等不仅仅只是一次（或多次）请求对资源没有副作用（比如查询数据库操作，没有增删改，因此没有对数据库有任何影响）。

2. 幂等还包括第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。

3. 幂等关注的是以后的多次请求是否对资源产生的副作用，而不关注结果。

4. 网络超时等问题，不是幂等的讨论范围。

幂等性是系统服务对外一种承诺（而不是实现），承诺只要调用接口成功，外部多次调用对系统的影响是一致的。声明为幂等的服务会认为外部调用失败是常态，并且失败之后必然会有重试。

幂等场景

业务开发中，经常会遇到重复提交的情况，无论是由于网络问题无法收到请求结果而重新发起请求，或是前端的操作抖动而造成重复提交情况。 在交易系统，支付系统这种重复提交造成的问题有尤其明显，比如：

1. 用户在APP上连续点击了多次提交订单，后台应该只产生一个订单；

2. 向支付宝发起支付请求，由于网络问题或系统BUG重发，支付宝应该只扣一次钱。 很显然，声明幂等的服务认为，外部调用者会存在多次调用的情况，为了防止外部多次调用对系统数据状态的发生多次改变，将服务设计成幂等。

3. 发送验证短息也应该只发一次，同样的验证短信不应该发送多次。

幂等VS防重

重复提交是在第一次请求已经成功的情况下，人为的进行多次操作，导致不满足幂等要求的服务多次改变状态。

而幂等更多使用的情况是第一次请求不知道结果（比如超时）或者失败的异常情况下，发起多次请求，目的是多次确认第一次请求成功，却不会因多次请求而出现多次的状态变化。

幂等性的实现方法

1.建立唯一索引，防止新增脏数据
这个可以限制重复插入数据，当重复时，数据库会抛异常，保证不会出现脏数据。但体验不好，并且实用场景有限制。

2.利用 token 机制，防止页面重复提交
核心思想是为每一次操作生成一个唯一性的凭证，也就是token。一个token在操作的每一个阶段只有一次执行权，一旦执行成功则保存执行结果。对重复的请求，返回同一个结果。

3.状态机幂等
在有状态的数据中可以使用，如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。如果状态是顺序的，不可逆，那么就不会出现 ABA 问题，否则会出现 ABA问题。

4.select + insert
这种情况在没有并发的系统中可以解决幂等问题，在单JVM有并发的时候可以加锁来保证幂等性，在分布式环境它是没发保证幂等的，这时候需要用到分布式锁来保证。

5.分布式锁
在进入方法时，先去获取锁，假如获取到锁，就继续后面的流程。假如没有获取到锁，就等待锁的释放直到获取到锁。当执行完方法时，释放锁。当然，锁要设个超时时间，防止意外没有释放到锁。它用来解决分布式系统的幂等性，常用的实现方案是 redis 和 zookeeper 等工具。

6.对外提供幂等的接口
通过 source来源+seq序列号来判断请求是否重复， 在并发时只能处理一个请求。其它相同并发请求要么返回请求重复，要么等待前面请求执行完成在执行。

7.查询操作
查询一次和查询多次，在数据不变的情况下，查询结果都是一样的，select是天然的幂等操作。

8.删除操作
删除操作也是幂等的，删除一次和删除多次都是把数据删除。

9.悲观锁
获取数据的时候加锁获取：
select * from table where id = '1' for update;
要注意的是，id字段一定要是主键或者唯一索引，否则会导致锁表。
悲观锁的使用一般伴随事务一起使用，数据锁定事件可能会很长，要根据实际情况慎用。

10.乐观锁
乐观锁只是在更新数据的那一刻锁表，其他时间不锁表，所以相对于悲观锁效率更高。
乐观锁的实现方式多种多样，可以通过version或者其他状态条件。

幂等性的不足

1.增加了额外控制幂等的业务逻辑，复杂化了业务功能。
2.把并行执行的功能改为串行执行，降低了执行效率。