美文网首页
接口设计-幂等性

接口设计-幂等性

作者: mysimplebook | 来源:发表于2019-11-08 14:38 被阅读0次

    根据网络资料整理

    幂等(idempotent、idempotence)是一个数学与计算机学概念,常见于抽象代数中。 在数学中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。编程中的幂等函数或幂等方法,是指可以使用相同参数即相同请求(identical request)重复执行多次,而执行一次和后续多次所带来的副作用(side-effects)是一样的。

    下面就用增、删、改、查来举例一下吧!

    (1)查询操作

    查询操作并不会产生或变更新的数据,因此查询是天然具备幂等性。

    (2)删除操作

    这里分为物理删除和逻辑删除

    物理删除:删除只会进行一次,无论执行几次delete操作,造成的效果是一样的!是幂等性操作

    逻辑删除:这类删除,是用update修改字段而已,这种操作无论update几次,造成的效果是一样的!是幂等性操作

    (3)增加操作

    这里要看这张表是否带唯一索引。

    带唯一索引Insert:此时如果重复插入操作,是会插入失败的!该操作是幂等性操作

    不带唯一索引Insert:这种情况是非幂等性操作。

    (4)修改操作

    要看修改了啥

    计算式Update:这类操作是指UPDATE table SET

    number=number-1 WHERE id=1,这类SQL的操作,是非幂等性操作!

    非计算式Update:这类操作是指UPDATE table SET

    number=3 WHERE id=1,这类SQL操作,这种修改是属于幂等性的操作

    接口要设计成具有幂等特性,这是因为客户端请求“重试”引起的。因为在应用程序接口互调中,有成功、失败和超时状态。一个服务调用另一个服务时,如果发生了任何一种状态,调用方都可能会发起重试。

           分布式系统中,重试可能引起不一致现象。如一套系统中包含了多个子系统服务,而一个子系统服务往往会去调用另一个服务,而服务调用服务无非就是使用RPC通信或者restful,既然是通信,那么就有可能在服务器处理完毕后返回结果的时候挂掉,这个时候用户端发现很久没有反应,那么就会多次点击按钮,这样请求有多次。如一个网上下单系统,当用户使用我们的系统下单时,我们就需要对该订单进行发货处理,我们的网上下单系统会调用发货系统进行发货,假如下单系统调用发货系统时网络延迟造成前端没响应,用户又点了几次,这样就会造成重复下单的问题。

           解决这种尴尬场景的最常见的方法就是调用方实现合理的重试策略,被调用方实现应对重试的幂等策略。

    PRG模式

            在Web应用中,采用POST提交信息是非常常见的,然而如果目标页面打开得太慢,用户就可能会刷新页面,这时候之前已经提交过的信息就会被重复提交。采用PRG模式,可以有效防止表单重复提交。

    去重表+唯一索引

            这种方法适用于在业务中有唯一标识的插入场景中,比如在支付场景中,如果一个订单只会支付一次,所以订单ID可以作为唯一标识。这时,我们就可以建一张去重表,将订单号orderId设为去重表的唯一索引,每次请求支付都根据订单号向去重表中插入一条数据,只有插入成功才继续执行支付操作,相当于在事务的开始阶段加锁。

    在我们实现时,把创建支付单据写入去重表,放在一个事务中,如果重复创建,数据库会抛出唯一约束异常,操作就会回滚。因此,在插入业务前一般先执行select。缺点是每个业务库都要维护一张去重表。

    全局ID

            如果使用全局唯一ID(如token),就是根据业务的操作(业务类型)和内容生成一个全局ID,在执行操作前先根据这个全局唯一ID是否存在,来判断这个操作是否已经执行。如果不存在则把全局ID,存储到存储系统中,比如数据库、redis等。如果存在则表示该方法已经执行,这个全局ID有时效性。特别地,对外提供接口的api如银联提供的付款接口:需要接入商户提交付款请求时附带:source来源,seq序列号 ,source+seq在数据库里面做唯一索引,防止多次付款,(并发时,只能处理一个请求) 。

    相关文章

      网友评论

          本文标题:接口设计-幂等性

          本文链接:https://www.haomeiwen.com/subject/vonibctx.html