注解实现接口幂等性（实现接口幂等性方法）

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

本文目录一览：

• 1、接口的幂等性
• 2、什么是接口幂等性?
• 3、接口幂等问题探究
• 4、细说Restful API之幂等性
• 5、如何保证服务幂等性？
• 6、理解幂等性

接口的幂等性

在数学里注解实现接口幂等性， 幂等 有两种主要的定义。

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

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

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

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

什么是接口幂等性?

接口幂等性，一般是用在订单处理或者消费处理的场景的。使用接口幂等性是为了防止同一请求多次处理的状况。建议直接在百度中搜索接口幂等性，或者在csdn，博客园搜索下业务场景以及怎么来实现接口幂等性。希望可以帮住到你！

接口幂等问题探究

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

实践代码项目 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

细说Restful API之幂等性

幂等性原本是数学中的含义，表达的是N次变换与1次变换的结果相同。

而RESTFul API中的幂等性是指调用某个接口1次或N次，对所访问的资源产生的影响结果都是相同的，需要特别注意的是：这里幂等性指的是对资源产生的影响结果，而非调用HTTP请求的返回结果。

举个例子，RESTFul API中的GET方法是查询资源信息，不会对资源产生影响，所以它是符合幂等性的，但是每次调用GET方法返回的结果有可能不同（可能资源的某个属性在调用GET方法之前已经被其他方法修改了，例如在多次访问期间，接口返回对象的update_time字段被别的请求更新，但GET本身是幂等性的）。

实际上，在分布式架构中的API幂等性不仅仅针对RESTFul接口，而是对所有类型的接口适用，目的是为了确保调用1次或N次接口时对资源的影响结果都是相同的。

接口的幂等性确保了无论调用1次还是N次对资源的影响都是相同的，这在某些场合下是非常有用的。

举个业务场景：用户下单，银行从用户账户扣款。

有这样一个接口方法：pay(long account, int money)，该方法用于银行卡扣款支付，参数account为账户ID，money为需要扣除的钱数。

当用户从网页上点击支付按钮时，在该方法的实现逻辑中需要从指定账户中扣除对应的商品价钱。如果支付操作已经成功执行，但是响应消息因为某种原因未能及时返回给客户端，这时候给用户的体验是可能是未支付成功，如果此时再次点击支付按钮，那么将再一次执行该方法，结果可能会导致用户只买了一件商品却扣减了双份的钱，这当然是不合理的。整个流程如下图所示：

当然，就上述例子的场景，为了避免用户重复支付，是可以通过别的方式解决的，比如：分布式事务；或者根据支付状态提示给予用户进行提示等等。

但是，如果引入了分布式事务，那么将带来实现上的复杂性，而且会影响到接口性能；而采取提示信息的方式并不能百分之百确保用户不会重复支付，存在一定的风险。

而如果接口符合幂等性，即：对同一个订单无论是执行一次支付还是多次支付，在服务端都确保只会扣一次款，那么既不需要引入分布式事务的复杂性，也能从根本上解决重复支付的问题，这也就是接口符合幂等性的价值所在。

总而言之，接口符合幂等性在可以降低系统实现的复杂性，并能保证资源状态的一致性。

RESTFul风格的接口设计本质上使用的是HTTP协议的请求方法，因此，RESTFul接口方法的幂等性指的就是HTTP方法的幂等性。

常用的HTTP方法有：

那么，这些HTTP方法的幂等性又是什么样的呢？除了幂等性之外，HTTP方法的安全性是指不对资源产生修改。
如下是常用HTTP方法的幂等性和安全性总结：

从上述表格中可以看出，HTTP方法的幂等性和安全性并不是同一个概念，如下是对个各个方法的幂等性和安全性解释：

设计幂等性接口的关键在于保证接口不论是被调用1次还是N次，它对资源所产生的影响都是相同的。
从上述HTTP方法的幂等性总结中可以得知，HTTP协议的POST和PATCH方法都不是幂等性的（但是我们却经常会在RESTFul接口中使用到它们），那是否就意味中无法将POST和PATCH方法设计为幂等性接口了呢？答案显然是否定的。在上述例子中，可以将订单ID也作为方法参数之一，如：pay(long account, int money, long order)，这样在服务端确保一个订单只会被支付一次（订单号是全局唯一的），那么无论该方法被调用1次还是N次结果都是一样的，也就保证了接口的幂等性。当然，在哪些没有订单号的场景，可以为接口操作生成一个全局唯一的处理号ID，并把该处理号ID作为方法参数之一，这样在服务端确保一个处理号ID只会被执行一次就保证了接口的幂等性。
符合幂等性的接口调用流程描述如下图所示：

虽然说设计符合幂等性的接口在某些场合可以降低系统的复杂性（如：可以不用引入分布式事务），但是并非在所有场合的问题都能通过幂等性接口解决，在必要的时候依然需要引入分布式事务处理这样的框架。我们不要也不能把接口幂等性作为万能的解决办法，但是，我们在设计接口时尽量考虑符合幂等性处理是非常有价值的。

【参考】

如何保证服务幂等性？

1、概念:接口的幂等性实际上就是接口可重复调用，在调用方多次调用的情况下，接口最终得到的结果是-致的。有些接口可以天然的实现幂等性，比如查询接口，对于查询来说，你查询一次和两次，对于系统来说，没有任何影响，查出的结果也是一样。
2、GET幂等:值得注意，幂等性指的是作用于结果而非资源本身。怎么理解呢?例如，这个HTTP GET方法可能会每次得到不同的返回内容，但并不影响资源。
3、POST非幂等:因为它会对资源本身产生影响，每次调用都会有新的资源产生，因此不满足幂等性。

理解幂等性

一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外）。

也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。换种说法，就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

举个最简单的例子，那就是支付，用户购买商品使用支付，此时多次触发支付，只会支付一次，而不会多扣钱。

1. 幂等需要关注的几个重点:

（1）幂等不仅仅只是一次（或多次）请求对资源没有副作用。
（2）幂等还包括第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。
（3）幂等关注的是以后的多次请求是否对资源产生的副作用，而不关注结果。
（4）网络超时等问题，不是幂等的讨论范围。

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

2. 幂等与防重的区别：

（1）重复提交是在 第一次请求已经成功的情况下 ，人为的进行多次操作，导致不满足幂等要求的服务多次改变状态。
（2）幂等更多使用的情况是 第一次请求不知道结果（比如超时）或者失败的异常情况下 ，发起多次请求，目的是多次确认第一次请求成功，却不会因多次请求而出现多次的状态变化。（ 重点重点重点！！！ ）

业务开发中，经常会遇到重复提交的情况，无论是由于网络问题无法收到请求结果而重新发起请求，或是前端的操作抖动而造成重复提交情况。

在交易系统，支付系统这种重复提交造成的问题有尤其明显，比如：

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

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

以SQL为例，有下面三种场景，只有第三种场景需要开发人员使用其他策略保证幂等性：

幂等可以使得客户端逻辑处理变得简单，但是却以服务逻辑变得复杂为代价。 满足幂等服务的需要在逻辑中至少包含两点：

（1）首先去查询上一次的执行状态，如果没有则认为是第一次请求。
（2）在服务改变状态的业务逻辑前，保证防重复提交的逻辑。

幂等是为了简化客户端逻辑处理，却增加了服务提供者的逻辑和成本，是否有必要，需要根据具体场景具体分析，因此除了业务上的特殊要求外，尽量不提供幂等的接口。

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

幂等需要通过唯一的业务单号来保证。也就是说相同的业务单号，认为是同一笔业务。使用这个唯一的业务单号来确保，后面多次的相同的业务单号的处理逻辑和执行效果是一致的。

下面以支付为例， 在不考虑并发的情况下，实现幂等很简单：

① 先查询一下订单是否已经支付过；
② 如果已经支付过，则返回支付成功；如果没有支付，进行支付流程，修改订单状态为‘已支付’。

上述的保证幂等方案是分成两步的，第②步依赖第①步的查询结果，无法保证原子性的。在高并发下就会出现下面的情况：第二次请求在第一次请求第②步订单状态还没有修改为‘已支付状态’的情况下到来。

既然得出了这个结论，余下的问题也就变得简单： 把查询和变更状态操作加锁，将并行操作改为串行操作。

（1）乐观锁

如果只是更新已有的数据，没有必要对业务进行加锁，设计表结构时使用乐观锁，一般通过version来做乐观锁，这样既能保证执行效率，又能保证幂等。

例如： UPDATE tab1 SET col1=1,version=version+1 WHERE version=#version# 不过，乐观锁存在失效的情况，就是常说的ABA问题，不过如果version版本一直是自增的就不会出现ABA的情况。

（2）悲观锁

select * from xx for update;

悲观锁和乐观锁的区别:

使用订单号orderNo做为去重表的唯一索引，每次请求都根据订单号向去重表中插入一条数据。

第一次请求查询订单支付状态，当然订单没有支付，进行支付操作，无论成功与否，执行完后更新订单状态为成功或失败，删除去重表中的数据。

后续的订单因为表中唯一索引而插入失败，则返回操作失败，直到第一次的请求完成（成功或失败）。可以看出防重表作用是加锁的功能。

订单发起支付请求，支付系统会去Redis缓存中查询是否存在该订单号的Key，如果不存在，则向Redis增加Key为订单号。

查询订单支付已经支付，如果没有则进行支付，支付完成后删除该订单号的Key。通过Redis做到了分布式锁，只有这次订单订单支付请求完成，下次请求才能进来。

相比去重表，将放并发做到了缓存中，较为高效。思路相同，同一时间只能完成一次支付请求。

这种方式分成两个阶段：申请token阶段和支付阶段。

第一阶段，在进入到提交订单页面之前，需要订单系统根据用户信息向支付系统发起一次申请token的请求，支付系统将token保存到Redis缓存中，为第二阶段支付使用。

第二阶段，订单系统拿着申请到的token发起支付请求，支付系统会检查Redis中是否存在该token，如果存在，表示第一次发起支付请求，删除缓存中token后开始支付逻辑处理；如果缓存中不存在，表示非法请求。

实际上这里的token是一个信物，支付系统根据token确认是否是非法请求。不足是需要系统间交互两次，流程较上述方法复杂。

把订单的支付请求都快速地接下来，一个快速接单的缓冲管道。后续使用异步任务处理管道中的数据，过滤掉重复的待支付订单。优点是同步转异步，高吞吐。不足是不能及时地返回支付结果，需要后续监听支付结果的异步返回。

关于注解实现接口幂等性和实现接口幂等性方法的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 注解实现接口幂等性的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于实现接口幂等性方法、注解实现接口幂等性的信息别忘了在本站进行查找喔。

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