接口幂等，如何保证？

今日大家来聊一聊有关插口的幂等性难题。

什么叫幂等性

说白了幂等，便是随意数次实行所造成的危害均与一次实行的危害同样。

在 restful 标准中，普遍的要求方法和插口幂等性关联以下：

怎么会造成插口幂等性难题

在计算机技术中，很有可能碰到网络抖动，临时性常见故障，或是服务项目启用不成功，尤其是分布式架构中，插口启用不成功更加普遍。为了更好地确保服务项目的一致性，大家很有可能会进行插口的再试启用，假如插口不解决幂等，很有可能系统对导致非常大的危害，因而插口的幂等设计方案特别是在至关重要。

针对业务流程中必须考虑到幂等性的地区一般全是插口的反复要求，反复要求就是指同一个要求由于一些缘故被数次递交。造成这类状况的产生有下列几类普遍的情景：

1. 前面反复递交：客户在表单提交的情况下，很有可能会因为网络不稳定沒有立即作出操作成功回应，导致客户觉得沒有取得成功递交，随后一直点提交按钮，这时候便会产生反复表单提交要求。

2. 插口请求超时再试：第三方启用插口情况下，为了更好地请求超时等异常现象导致的要求不成功，都是会加上再试体制，造成一个要求递交数次。

3. 信息反复消費：当应用 MQ 消息中间件情况下，假如产生消息中间件发生不正确未立即递交消費信息内容，造成产生反复消費。

幂等性解决方法

那大家应当能如何确保插口的幂等性呢？

能够 思索一下，第一种情景下，即然是客户反复递交造成的，那我们可以想办法让客户没法反复递交。

计划方案一：前面操纵

在前面做阻拦，例如按键点一下一次以后就置灰或是掩藏。可是通常前面并不靠谱，或是得后面解决才更安心。

计划方案二：Token体制

客户进到表格网页页面最先启用后台管理插口获得 token 并存进 redis，当客户表单提交时将 token 也做为入参，后面先删掉 redis 中的 token，删掉取得成功则储存表格数据信息，不成功则提醒客户反复递交。

这儿为什么不先分辨 redis 是不是存有这一 token 再删掉，是由于要确保实际操作的原子性，极端化状况下，第一个要求查看到 redis 中存有这一 token，还不等他删掉，第二个要求进去，也查看到 redis 中存有这一 token，那麼依然会导致反复递交的难题。

token 体制必须先要求获得 token 的插口，在有一些状况下很显著并不适合。大家绝大多数要求全是要落入数据库查询的，因此 我们可以从数据库查询下手。

计划方案三、唯一索引

这类计划方案就比较好了解了，应用唯一索引能够 防止脏数据的加上，当插进反复数据信息时数据库查询会抛出现异常，确保了数据信息的唯一性。唯一索引能够 适用插进、升级、删掉业务流程实际操作。

计划方案四、悲观锁

这儿常说的悲观锁是根据数据库查询方面的，在读取数据时开展上锁，当与此同时有好几个反复要求时，别的要求都没法开展实际操作。悲观锁只适用升级实际操作。

// 比如
select name from t_goods where id=1 for update;

留意：id 字段名一定如果外键约束或是唯一索引，要不然会锁定一整张表，这也是会死尸的。悲观锁应用时一般随着事务管理一起应用，数据信息锁住時间很有可能会较长，依据具体情况采用。

在要求量较为大的状况下，应用悲观锁显著不适合，此刻就到乐观锁出场了。

计划方案五、乐观锁

能够 根据版本信息完成，为表提升一个 version 字段名，当数据信息必须升级时，先去数据库查询里获得这时的version版本信息。

select version from t_goods where id=1

升级数据信息时最先要比照版本信息，如果不相同表明早已有别的的要求去升级数据信息了，提醒更新失败。

update t_goods set count=count 1,version=version 1 where version=#{version}

也有一种是根据状态机完成的，实际上也是开朗锁的原理。这类方式合适在有情况运转的状况下，例如订单信息的建立和支付，订单信息的建立毫无疑问是在支付以前，这时候我们可以根据在设计方案状态字段时，应用 int 种类，而且根据值种类的尺寸来完成幂等性。

update t_goods set status=#{status} where id=1 and status<#{status}

一样，乐观锁也只适用升级实际操作。

计划方案六、分布式锁

有时大家的业务流程不仅是实际操作数据库查询，也可能是发送信息、信息这些，那数据库查询方面的锁就不宜了。这类状况下就需要考虑到编码方面的锁了，而 java 的内置的锁在分布式系统群集布署的情景下并不适合，那麼就可以选用分布式锁来完成（Redis 或 Zookeeper）。

拿 Redis 分布式锁举例说明，例如一个订单信息进行付款要求，支付平台会去 Redis 缓存文件中查看是不是存有该订单编号的 Key，假如不会有，则以 Key 为订单编号向 Redis 插进。查订单是不是早已付款，要是没有则开展付款，付款进行后删掉该订单编号的Key。根据 Redis 保证了分布式锁，仅有此次订单支付要求进行，下一次要求才可以进去。自然这儿必须设定一个Key 的到期時间，在产生出现异常的情况下还需要留意删掉 Redis 的 Key。

汇总

插口的幂等性是一个很普遍的难题，必须依据实际业务场景的不一样，挑选适合的解决方法。

END

以往强烈推荐

你务必掌握的分布式事务解决方法

就这？分布式系统 ID 发号器实战演练

略知一二策略模式之工厂模式

就这？Spring 事务管理无效情景及解决方法

就这？一篇文章使你了解 Spring 事务管理