- 一、概述
- 1.1、什么是幂等
- 1.2、为什么需要幂等？
- 二、幂等如何设计
- 实现幂等的8 种方案
- select+insert+主键/唯一索引冲突
- 状态机幂等
- 抽取防重表
- token令牌
- 悲观锁(如select for update)
- 乐观锁
- 分布式锁
- 三、HTTP的幂等
一、概述
在分布式系统和微服务架构中，确保操作的安全性和可靠性至关重要。幂等性（Idempotency）是实现这一目标的重要概念。本文将探讨幂等性的基本原理、应用场景以及设计幂等操作的方法。
在工作中，做幂等的场景蛮多的，恰逢阿里云网盘事件爆发，能够访问到陌生人的图片，那么在幂等上肯定就存在着问题。
所以针对幂等性针对要来做一个总结说明。
1.1、什么是幂等
幂等性是指一个操作无论执行多少次，其结果都是相同的。在数学上，函数 f(x)f(x)f(x) 满足幂等性是指 f(f(x))=f(x)f(f(x)) = f(x)f(f(x))=f(x)。在计算机科学中，幂等操作的一个典型例子是HTTP GET请求，不管你发送多少次GET请求，服务器返回的资源状态都是一致的。
1.2、为什么需要幂等？
在某些提交表单的场景，如果用户一直重复点击，可能会产生两条一样的数据，这种是前端重复提交的场景。还有就是转账场景，出现网络超时，有可能请求到，或者出现网络丢包的情况，这种情况导致重复请求的情况，这种情况如果重试，那么就是需要做好幂等，否则的话就会出现转账多转的情况。
二、幂等如何设计
唯一请求标识符：使用唯一请求ID（如UUID）来标识每个操作。服务器可以使用这个ID来跟踪和记录请求，确保每个请求只执行一次。
一般会生成一个全局性的唯一 id，全局唯一 id 有许多种生成方式，如以下方式
-
UUID：UUID的缺点比较明显，它字符串占用的空间比较大，生成的ID过于随机，可读性差，而且没有递增。
-
分布式 id:经典分布式 id 就是使用雪花算法来生成唯一 id。
分布式 id 生成算法雪花算法是一种生成分布式全局唯一ID的算法，生成的ID称为Snowflake IDs。这种算法由Twitter创建，并用于推文的ID。一个Snowflake ID有64位。
第1位：Java中long的最高位是符号位代表正负，正数是0，负数是1，一般生成ID都为正数，所以默认为0。
接下来前41位是时间戳，表示了自选定的时期以来的毫秒数。接下来的10位代表计算机ID，防止冲突。
其余12位代表每台机器上生成ID的序列号，这允许在同一毫秒内创建多个Snowflake ID。
当然，全局唯一性的ID，还可以使用百度的Uidgenerator，或者美团的Leaf。
实现幂等的8 种方案
如果你调用下游接口超时了，是不是要考虑重试，如果重试的话，下游接口就需要支持幂等。
实现幂等一般有以下方案:
- select+insert+主键/唯一索引冲突
- 直接insert + 主键/唯一索引冲突
- 状态机幂等
- 抽取防重表
- token令牌
- 悲观锁(如select for update，很少用)
- 乐观锁
- 分布式锁
select+insert+主键/唯一索引冲突
日常开发中，为了实现交易接口幂等，我是这样实现的：
交易请求过来，我会先根据请求的唯一流水号 reqNo字段+userId字段，先select一下数据库的流水表
-
如果数据已经存在，就拦截是重复请求，直接返回成功；
-
如果数据不存在，就执行
insert插入，如果insert成功，则直接返回成功，如果insert产生主键冲突异常，则捕获异常，开始来做一些补偿处理。
状态机幂等
很多业务表，都是有状态的，比如转账流水表，就会有0-待处理，1-处理中、2-成功、3-失败状态。转账流水更新的时候，都会涉及流水状态更新，即涉及状态机 (即状态变更图)。我们可以利用状态机实现幂等，一起来看下它是怎么实现的。
比如转账成功后，把处理中的转账流水更新为成功状态，SQL这么写：
很多业务表，都是有状态的，比如转账流水表，就会有0-待处理，1-处理中、2-成功、3-失败状态。转账流水更新的时候，都会涉及流水状态更新，即涉及状态机 (即状态变更图)。我们可以利用状态机实现幂等，一起来看下它是怎么实现的。
比如转账成功后，把处理中的转账流水更新为成功状态，SQL这么写：
update transfr_flow set status=2 where biz_seq=‘666’ and status=1;
如下是伪代码
Rsp idempotentTransfer（Request req）{String bizSeq = req.getBizSeq();int rows= "update transfr_flow set status=2 where biz_seq=#{bizSeq} and status=1;"if(rows==1){log.info(“更新成功,可以处理该请求”);//其他业务逻辑处理return rsp;}else if(rows==0){log.info(“更新不成功，不处理该请求”);//不处理，直接返回return rsp;}log.warn("数据异常")return rsp：
}
Java
Copy
抽取防重表
很多时候，我们业务表唯一流水号希望后端系统生成，又或者我们希望防重功能与业务表分隔开来，这时候我们可以单独搞个防重表。当然防重表也是利用主键/索引的唯一性，如果插入防重表冲突即直接返回成功，如果插入成功，即去处理请求。
token令牌
token 令牌方案一般包括两个请求阶段：
-
客户端请求申请获取token，服务端生成token返回
-
客户端带着token请求，服务端校验token
- 客户端发起请求，申请获取token。
- 服务端生成全局唯一的token，保存到redis中（一般会设置一个过期时间），然后返回给客户端。
- 客户端带着token，发起请求。
- 服务端去redis确认token是否存在，一般用
redis.del(token)的方式，如果存在会删除成功，即处理业务逻辑，如果删除失败不处理业务逻辑，直接返回结果。
悲观锁(如select for update)
什么是悲观锁？
通俗点讲就是很悲观，每次去操作数据时，都觉得别人中途会修改，所以每次在拿数据的时候都会上锁。官方点讲就是，共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。
悲观锁如何控制幂等的呢？就是加锁呀，一般配合事务来实现。
举个更新订单的业务场景：
假设先查出订单，如果查到的是处理中状态，就处理完业务，再然后更新订单状态为完成。如果查到订单，并且不是处理中的状态，则直接返回
整体的伪代码如下：
begin; # 1.开始事务
select * from order where order_id='666' # 查询订单，判断状态
if（status !=处理中）{//非处理中状态，直接返回；return ;
}
## 处理业务逻辑
update order set status='完成' where order_id='666' # 更新完成
commit; # 5.提交事务
-
这里面order_id需要是索引或主键哈，要锁住这条记录就好，如果不是索引或者主键，会锁表的！
-
悲观锁在同一事务操作过程中，锁住了一行数据。别的请求过来只能等待，如果当前事务耗时比较长，就很影响接口性能。所以一般不建议用悲观锁做这个事情。
除了会导致事务过长之外，还会导致大量的锁循环检测，导致CPU飙升，一般来说不会利用数据库来热点数据更新。
可以采用的方案有：
- 如果使用的是阿里云的数据库，可以使用到hit机制；
- Redis+MQ，利用Redis来抗住压力，然后将压力减小，利用MQ来进行消费，然后来对其进行更新；
乐观锁
悲观锁有性能问题，可以试下乐观锁。
什么是乐观锁？
乐观锁在操作数据时,则非常乐观，认为别人不会同时在修改数据，因此乐观锁不会上锁。只是在执行更新的时候判断一下，在此期间别人是否修改了数据。
怎样实现乐观锁呢？
就是给表的加多一列version版本号，每次更新记录version都升级一下（version=version+1）。具体流程就是先查出当前的版本号version，然后去更新修改数据时，确认下是不是刚刚查出的版本号，如果是才执行更新
比如，我们更新前，先查下数据，查出的版本号是version =1
select order_id，version from order where order_id='666'；
然后使用version =1和订单Id一起作为条件，再去更新
update order set version = version +1，status='P' where order_id='666' and version =1
最后更新成功，才可以处理业务逻辑，如果更新失败，默认为重复请求，直接返回。
流程图如下：
为什么版本号建议自增的呢？
因为乐观锁存在ABA的问题，如果version版本一直是自增的就不会出现ABA的情况啦。
分布式锁
分布式锁实现幂等性的逻辑就是，请求过来时，先去尝试获得分布式锁，如果获得成功，就执行业务逻辑，反之获取失败的话，就舍弃请求直接返回成功。执行流程如下图所示：
三、HTTP的幂等
我们的接口，一般都是基于http的，所以我们再来聊聊Http的幂等吧。HTTP 请求方法主要有以下这几种，我们看下各个接口是否都是幂等的。
-
GET方法
-
HEAD方法
-
OPTIONS方法
-
DELETE方法
-
POST 方法
-
PUT方法
GET 方法
HTTP 的GET方法用于获取资源，可以类比于数据库的select查询，不应该有副作用，所以是幂等的。它不会改变资源的状态，不论你调用一次还是调用多次，效果一样的，都没有副作用。
如果你的GET方法是获取最近最新的新闻，不同时间点调用，返回的资源内容虽然不一样，但是最终对资源本质是没有影响的哈，所以还是幂等的。
HEAD 方法
HTTP HEAD和GET有点像，主要区别是HEAD不含有呈现数据，而仅仅是HTTP的头信息，所以它也是幂等的。如果想判断某个资源是否存在，很多人会使用GET，实际上用HEAD则更加恰当。即HEAD方法通常用来做探活使用。
OPTIONS方法
HTTP OPTIONS 主要用于获取当前URL所支持的方法，也是有点像查询，因此也是幂等的。
DELETE方法
HTTP DELETE 方法用于删除资源，它是的幂等的。比如我们要删除id=666的帖子，一次执行和多次执行，影响的效果是一样的呢。
POST 方法
HTTP POST 方法用于创建资源，可以类比于提交信息，显然一次和多次提交是有副作用，执行效果是不一样的，不满足幂等性。
比如：POST 的语义是创建一篇帖子，HTTP 响应中应包含帖子的创建状态以及帖子的 URI。两次相同的POST请求会在服务器端创建两份资源，它们具有不同的 URI；所以，POST方法不具备幂等性。
PUT 方法
HTTP PUT 方法用于创建或更新操作，所对应的URI是要创建或更新的资源本身，有副作用，它应该满足幂等性。
比如：PUT的语义是创建或更新 ID 为666的帖子。对同一 URI 进行多次 PUT 的副作用和一次 PUT 是相同的；因此，PUT 方法具有幂等性。
