如何实现接口的幂等性（如何保证接口的幂等性）

本篇文章给大家谈谈如何实现接口的幂等性，以及如何保证接口的幂等性对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享如何实现接口的幂等性的知识，其中也会对如何保证接口的幂等性进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、接口的幂等性
• 2、分布式系统中实现幂等性的几种方式
• 3、接口幂等问题探究
• 4、浅谈接口幂等性
• 5、什么是接口幂等性?

接口的幂等性

在数学里， 幂等 有两种主要的定义。

在计算机领域，幂等性指 多次操作 对系统产生的影响 与一次操作相同。举个例子，假设要删除用户A，无论请求多少次，操作结果都是删除用户A，而不会删除用户B。
在RESTful风格的接口中，幂等性表现在HTTP请求方法中：

无论是微服务中各个子系统相互之间的调用，还是客户端对服务端的调用，都存在网络延迟等问题，会导致重复请求接口，这时候接口就需要支持幂等性，来防止出现问题。
最经典的一个例子就是订单支付操作，假如因为网络问题等因素导致用户重复提交，这时候不可能对用户重复扣款，否则客服电话就要被打爆了。
那么服务端接口对于幂等性应该如何支持呢？有如下两个思路：

1. 逻辑判断处理
支付时对订单状态进行判断，如果该订单已支付，则不应该再次进行扣款操作。

2. 请求带ticket
异步请求获取ticket，此ticket是唯一并且一次性的，保存在页面中，每次发起支付请求都带上ticket，后端检查ticket，若支付成功则删除ticket，这样就算重复提交也不会导致重复扣款。

分布式系统中实现幂等性的几种方式

在微服务架构下，我们在完成一个订单流程时经常遇到下面的场景：

为了解决以上问题，就需要保证接口的幂等性 ，接口的幂等性实际上就是接口可重复调用，在调用方多次调用的情况下，接口最终得到的结果是一致的。 有些接口可以天然的实现幂等性 ，比如查询接口，对于查询来说，你查询一次和两次，对于系统来说，没有任何影响，查出的结果也是一样。

除了查询功能具有天然的幂等性之外，增加、更新、删除都要保证幂等性。 那么如何来保证幂等性呢？

多版本并发控制，该策略主要使用update with condition（更新带条件来防止）来保证多次外部请求调用对系统的影响是一致的。在系统设计的过程中，合理的使用乐观锁，通过version或者updateTime（timestamp）等其他条件，来做乐观锁的判断条件，这样保证更新操作即使在并发的情况下，也不会有太大的问题。例如

在更新的过程中利用version来防止，其他操作对对象的并发更新，导致更新丢失。为了避免失败，通常需要一定的重试机制。

在插入数据的时候，插入去重表，利用数据库的唯一索引特性，保证唯一的逻辑。

这种方法适用于在业务中有唯一标的插入场景中，比如在以上的支付场景中，如果一个订单只会支付一次，所以订单ID可以作为唯一标识。这时，我们就可以建一张去重表，并且把唯一标识作为唯一索引，在我们实现时，把创建支付单据和写入去去重表，放在一个事务中，如果重复创建，数据库会抛出唯一约束异常，操作就会回滚。

select for update，整个执行过程中锁定该订单对应的记录。注意：这种在DB读大于写的情况下尽量少用。

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

在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机，就是业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，这时候，如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。

这种方法适合在有状态机流转的情况下，比如就会订单的创建和付款，订单的付款肯定是在之前，这时我们可以通过在设计状态字段时，使用int类型，并且通过值类型的大小来做幂等，比如订单的创建为0，付款成功为100。付款失败为99

在做状态机更新时，我们就这可以这样控制

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

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

解决办法：

处理流程：

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

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

总结： 幂等性应该是合格程序员的一个基因，在设计系统时，是首要考虑的问题，尤其是在像支付宝，银行，互联网金融公司等涉及的都是钱的系统，既要高效，数据也要准确，所以不能出现多扣款，多打款等问题，这样会很难处理，用户体验也不好 。

如果使用全局唯一ID，就是根据业务的操作和内容生成一个全局ID，在执行操作前先根据这个全局唯一ID是否存在，来判断这个操作是否已经执行。如果不存在则把全局ID，存储到存储系统中，比如数据库、redis等。如果存在则表示该方法已经执行。

从工程的角度来说，使用全局ID做幂等可以作为一个业务的基础的微服务存在，在很多的微服务中都会用到这样的服务，在每个微服务中都完成这样的功能，会存在工作量重复。另外打造一个高可靠的幂等服务还需要考虑很多问题，比如一台机器虽然把全局ID先写入了存储，但是在写入之后挂了，这就需要引入全局ID的超时机制。

使用全局唯一ID是一个通用方案，可以支持插入、更新、删除业务操作。但是这个方案看起来很美但是实现起来比较麻烦，下面的方案适用于特定的场景，但是实现起来比较简单。

接口幂等问题探究

最近遇到一些问题，表单重复提交，导致插入重复数据到数据库，这里查询一些通用的方案，自己都实践一下，以后好回顾。

实践代码项目 Github： https://github.com/h-dj/Spring-Learning/tree/master/repeat-submit

幂等 （idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。

在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。--- 百科

简单理解：就是针对一个操作，不管做多少次，产生的效果都是一样的。

举例：

对于业务中需要考虑幂等性的地方一般都是接口的重复请求，重复请求是指同一个请求因为某些原因被多次提交。导致这个情况会有以下几种场景：

前端方面：

后台方面：

注意：

以下准备使用加入购物车为例，实现各个方案

分布式锁可以使用 Redis 和 Zookeeper ，更多关于 Redis 和 Zookeeper 的使用 请自行查阅资料。以下使用 Redis 来实现分布式锁

以上是较为常见通用的幂等方案，但实际业务可能比较个性化，需要跟业务结合进行考虑，采用合适的方法或结合使用，例如：

本文作者：JiaJianHuang

本文链接：https://www.cnblogs.com/JianJianHuang/p/15702912.html

浅谈接口幂等性

有以下场景:
系统B接口不支持幂等, A系统请求B系统支付接口进行支付. 因网络超时导致接口请求失败.

关于以上场景, A系统进行后续处理.

1.在接口方法上使用同步锁

2.分布式锁如redis

2.业务字段加唯一约束

对客户端请求排队或者单线程都可以处理并发幂等问题，需要根据具体业务选择合适的方案但必须前后端一起做，前端做了可以提升用户体验，后端则可以保证数据安全。

//TODO

如有问题,还请各位老师批评指正,谢谢~

什么是接口幂等性?

接口幂等性，一般是用在订单处理或者消费处理的场景的。使用接口幂等性是为了防止同一请求多次处理的状况。建议直接在百度中搜索接口幂等性，或者在csdn，博客园搜索下业务场景以及怎么来实现接口幂等性。希望可以帮住到你！ 关于如何实现接口的幂等性和如何保证接口的幂等性的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 如何实现接口的幂等性的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于如何保证接口的幂等性、如何实现接口的幂等性的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。