一文搞懂幂等，什么是幂等，常见的幂等实现方案有哪些，HTTP的四种请求是否是幂等的

什么是幂等

通俗来讲：幂等就是一个操作，不论执行多少次，产生的效果和返回的结果都是一样的。

实现幂等的必要性

考虑如下场景：

1. 我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统bug重发，也应该只扣一次钱；
2. 发送消息，也应该只发一次，同样的短信发给用户，用户会哭的；
3. 创建业务订单，一次业务请求只能创建一个，创建多个就会出大问题。

可见实际业务场景中实现幂等性是非常有必要的。

幂等的实现技术有哪些

唯一索引、组合索引

比如：新建用户的时候将手机号码设置为唯一索引，那么即使你重试，也只会新建一个用户，不会因为重
试导致当前用户注册了两个用户

唯一索引或唯一组合索引来防止新增数据存在脏数据 （当表存在唯一索引，并发时新增报错时，再查询一次就可以了，数据应该已经存在了，返回结果即可）

Token机制

• 业务要求：
  页面的数据只能被点击提交一次

• 发生原因：
  由于重复点击或者网络重发，或者nginx重发等情况会导致数据被重复提交。

• 解决方法：

1. 数据提交前要向服务的申请token，token放到redis或内存，token有效时间
2. 提交后后台校验token，同时删除token，生成新的token返回

• token特点：
  要申请，一次有效性，可以限流

注意：redis要用删除操作来判断token，删除成功代表token校验通过，如果用select+delete来校验
token，存在并发问题，不建议使用

悲观锁

获取数据的时候加锁获取。如：

select * from table_xxx where id=‘xxx’ for update;

注意：id字段一定是主键或者唯一索引，不然是锁表，会死人的
悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用

乐观锁

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

1. 通过版本号实现，如：

update table_xxx set name=#name#,version=version+1 where version=#version#

分布式锁

当系统是分布式系统时，此时构建全局唯一索引比较困难，唯一性的字段无法确定。此时可以引入分布式锁，通过第三方的系统(redis或zookeeper)，在业务系统插入数据或者更新数据，首先尝试获取分布式锁，获取锁成功则执行业务，获取锁失败则重新尝试获取锁，当尝试一定次数仍然失败后不执行。

要点：某个长流程处理过程要求不能并发执行，可以在流程执行之前根据某个标志(用户ID+后缀等)获取
分布式锁，其他流程执行时获取锁就会失败，也就是同一时间该流程只能有一个能执行成功，执行完成
后，释放分布式锁(分布式锁要第三方系统提供)

Select + Insert

对于并发不高的后台系统，或者一些任务JOB，为了支持幂等，支持重复执行，简单的处理方法是，先查询下一些关键数据，判断是否已经执行过，在进行业务处理，就可以了。
注意：核心高并发流程不要用这种方法

系统对外提供的接口如何实现幂等性

如银联提供的付款接口：需要接入商户提交付款请求时附带：source来源，seq序列号
source+seq在数据库里面做唯一索引，防止多次付款，(并发时，只能处理一个请求)
重点：

对外提供接口为了支持幂等调用，接口有两个字段必须传，一个是来源source，一个是来源方序列号seq，这个两个字段在提供方系统里面做联合唯一索引，这样当第三方调用时，先在本方系统里面查询一
下，是否已经处理过，返回相应处理结果；没有处理过，进行相应处理，返回结果。注意，为了幂等友
好，一定要先查询一下，是否处理过该笔业务，不查询直接插入业务系统，会报错，但实际已经处理了。

幂等和分布式系统的关系

幂等与你是不是分布式高并发没有关系。关键是你的操作是不是幂等的。
一个幂等的操作典型如：把编号为5的记录的A字段设置为0这种操作不管执行多少次都是幂等的。
一个非幂等的操作典型如：把编号为5的记录的A字段增加1这种操作显然就不是幂等的。要做到幂等性，从接口设计上来说不设计任何非幂等的操作即可。
譬如说需求是：当用户点击赞同时，将答案的赞同数量+1。改为：当用户点击赞同时，确保答案赞同表中存在一条记录，用户、答案。赞同数量由答案赞同表统计出来。
总之幂等性应该是合格程序员的一个基因，在设计系统时，是首要考虑的问题，尤其是在像支付宝，银行，互联网金融公司等涉及的都是钱的系统，既要高效，数据也要准确，所以不能出现多扣款，多打款等问题，这样会很难处理，用户体验也不好。

HTTP的四个请求是否是幂等的

GET、PUT、DELETE

• 首先GET请求很好理解，对资源做查询多次，此实现的结果都是一样的。
• PUT请求的幂等性可以这样理解，将A修改为B，它第一次请求值变为了B，再进行多次此操作，最终的结果还是B，与一次执行的结果是一样的，所以PUT是幂等操作。
• 同理可以理解DELETE操作，第一次将资源删除后，后面多次进行此删除请求，最终结果是一样的，将资源删除掉了。

POST

POST不是幂等操作，因为一次请求添加一份新资源，二次请求则添加了两份新资源，多次请求会产生不同的结果，因此POST不是幂等操作。

使用幂等性区分POST和PUT请求

了解REST后很长一段时间不能明确区分PUT和POST的区别，在使用时很容易混淆，完全可根据idempotent（幂等性）做区分。

举一个简单的例子，假如有一个博客系统提供一个Web API，模式是这样http://superblogging/blogs/{blog-name}，很简单，将{blog-name}替换为我们的blog名字，往这个URI发送一个HTTP PUT或者POST请求，HTTP的body部分就是博文，这是一个很简单的REST API例子。

我们应该用PUT方法还是POST方法？

取决于这个REST服务的行为是否是idempotent的，假如我们发送两个http://superblogging/blogs/post/Sample请求，服务器端是什么样的行为？如果产生了两个博客帖子，那就说明这个服务不是idempotent的，因为多次使用产生了副作用了嘛；如果后一个请求把第一个请求覆盖掉了，那这个服务就是idempotent的。前一种情况，应该使用POST方法，后一种情况，应该使用PUT方法。

参考链接

https://blog.csdn.net/qq_33082731/article/details/74230813#:~:text=PUT%E8%AF%B7%E6%B1%82%E7%9A%84%E5%B9%82%E7%AD%89%E6%80%A7%E5%8F%AF