状态机实现接口幂等性（接口的幂等性）

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

本文目录一览：

• 1、接口的幂等性
• 2、分布式系统中实现幂等性的几种方式
• 3、如何保证服务幂等性？
• 4、什么是接口幂等性?

接口的幂等性

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

在计算机领域，幂等性指 多次操作 对系统产生的影响 与一次操作相同。举个例子，假设要删除用户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是一个通用方案，可以支持插入、更新、删除业务操作。但是这个方案看起来很美但是实现起来比较麻烦，下面的方案适用于特定的场景，但是实现起来比较简单。

如何保证服务幂等性？

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

什么是接口幂等性?

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

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