接口的幂等性

http://blog.csdn.net/fbysss/article/details/8024748

[原创链接: http://www.smithfox.com/?e=16 转载请保留此声明, 谢谢]

绝大部分网络上对幂等性的解释类似于:

"幂等性是指重复使用同样的参数调用同一方法时总能获得同样的结果。比如对同一资源的GET请求访问结果都是一样的。"

我认为这种解释是非常错误的, 幂等性强调的是外界通过接口对系统内部的影响, 外界怎么看系统和幂等性没有关系. 就上面这种解释, System.getCPULoad(), 这两次调用返回能一样吗? 但因为是只读接口, 对系统内部状态没有影响, 所以这个函数还是幂等性的.

首先了解一下什么是幂等性,如果你没有兴趣可以直接跳过这段代数概念解释 :)

幂等(idempotence)是来自于高等代数中的概念。

定义如下(加入了自己理解):

单目运算, x为某集合内的任意数, f为运算子如果满足f(x)=f(f(x)), 那么我们称f运算为具有幂等性(idempotent)

比如在实数集中,绝对值运算就是一个例子: abs(a)=abs(abs(a))

双目运算,x为某集合内的任意数, f为运算子如果满足f(x,x)=x, f运算的前提是两个参数都同为x, 那么我们也称f运算为具有幂等性

比如在实数集中,求两个数的最大值的函数: max(x,x) = x, 还有布尔代数中,逻辑运算 "与", "或" 也都是幂等运算, 因为他们符合AND(0,0) = 0, AND(1,1) = 1, OR(0,0) = 0, OR(1,1) = 1

在将幂等性应用到软件开发中,需要一些更深的理解. 我的理解如下:

数学处理的是运算和数值, 程序开发中往往处理的是对象和函数. 但是我们不能简单地理解为数学幂等中的运算就是函数,而数值就是对象!!

比如有Person对象有两个属性weight和age,但是所有的function只能对其中一个属性操作. 所以从这个层面我们可以理解为: 函数只对该函数所操作的对象某个属性具有幂等性, 而不是说对整个对象有运算幂等性.

[java] view plaincopy

  1. Person {
  2. private int weight;
  3. private int age;
  4. //是幂等函数
  5. public void setAge(int v){
  6. this.age = v;
  7. }
  8. //不是幂等函数
  9. public void increaseAge(){
  10. this.age++;
  11. }
  12. //是幂等函数
  13. public void setWeight(int v){
  14. this.weight=v+10;//故意加10斤!!
  15. }
  16. }

还有一点必须要澄清的是: 幂等性所表达的概念关注的是数学层面的运算和数值, 并没有提及到数值的安全性问题.

比如上面的Person的setAge函数, 有两种case不是幂等性所关心的, 但程序开发却又必须要关心的:

1. 两个线程同时调用

2. 因为age从业务上讲不可能递减, 如果前一次调用设置是30岁, 后一次调用变成了10岁或是更离谱的 -1 岁

所以RESTful设计中将幂等性和安全性是作为两个不同的指标来衡量POST,PUT,GET,DELETE操作的:

重要方法 安全? 幂等?
GET
DELETE
PUT
POST

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

就象cache有cache基本实现范式一样, 幂等也有自己的固定外部调用范式

cache实现范式:

[java] view plaincopy

  1. value getValue(key){
  2. value = getValueFromCache(key);
  3. if( value == null ){
  4. value = readFromPersistence(key);
  5. saveValueIntoCache(key,value);
  6. }
  7. return value;
  8. }

幂等外部调用范式

[java] view plaincopy

  1. client.age = 30;
  2. while(一些退出条件){
  3. try{
  4. if(socket.setPersonAge(person,client.age) == FAILED){
  5. int newAge = socket.getPersonAge();
  6. //处理冲突问题: 因为age只可能越来越大,所以将client的age更新为server端更大的age
  7. if(newAge>30){
  8. client.age = newAge;
  9. break;
  10. } else{
  11. <span style="white-space: pre; ">   </span>//无法进行冲突解决,再次尝试
  12. }
  13. } else return;
  14. } catch(Exception){
  15. //发生网络异常, 再次尝试
  16. }
  17. }

幂等接口的内部实现需要有对内保护机制, 一般情况是用类似于乐观锁的版本机制.版本重点是体现时间的先后.

[原创链接: http://www.smithfox.com/?e=16 转载请保留此声明, 谢谢]

时间: 2024-10-12 20:05:31

接口的幂等性的相关文章

接口的幂等性原则

接口调用存在的问题 现如今我们的系统大多拆分为分布式SOA,或者微服务,一套系统中包含了多个子系统服务,而一个子系统服务往往会去调用另一个服务,而服务调用服务无非就是使用RPC通信或者restful,既然是通信,那么就有可能在服务器处理完毕后返回结果的时候挂掉,这个时候用户端发现很久没有反应,那么就会多次点击按钮,这样请求有多次,那么处理数据的结果是否要统一呢?那是肯定的!尤其在支付场景.什么是接口幂等性 接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点击而

分布式系统中接口的幂等性(转)

业务场景 公司有个借贷的项目,具体业务类似于阿里的蚂蚁借呗,用户在平台上借款,然后规定一个到期时间,在该时间内用户需将借款还清并收取一定的手续费,如果规定时间逾期未还上,则会产生滞纳金. 用户发起借款因此会产生一笔借款订单,用户可通过支付宝或在系统中绑定银行卡到期自动扣款等方式进行还款.还款流程都走支付系统,因此用户还款是否逾期以及逾期天数.逾期费等都通过系统来计算. 但是在做订单系统的时候,遇到这样一个业务场景,由于业务原因允许用户通过线下支付宝还款,即我们提供一个公司官方的支付宝二维码,用户

如何保证接口的幂等性。。。。。

在微服务架构下,我们在完成一个订单流程时经常遇到下面的场景: 一个订单创建接口,第一次调用超时了,然后调用方重试了一次 在订单创建时,我们需要去扣减库存,这时接口发生了超时,调用方重试了一次 当这笔订单开始支付,在支付请求发出之后,在服务端发生了扣钱操作,接口响应超时了,调用方重试了一次 一个订单状态更新接口,调用方连续发送了两个消息,一个是已创建,一个是已付款.但是你先接收到已付款,然后又接收到了已创建 在支付完成订单之后,需要发送一条短信,当一台机器接收到短信发送的消息之后,处理较慢.消息中

分布式服务接口的幂等性如何设计

面试官心理分析 从这个问题开始,面试官就已经进入了实际的生产问题的面试了. 一个分布式系统中的某个接口,该如何保证幂等性?这个事儿其实是你做分布式系统的时候必须要考虑的一个生产环境的技术问题.啥意思呢? 你看,假如你有个服务提供一些接口供外部调用,这个服务部署在了 5 台机器上,接着有个接口就是付款接口.然后人家用户在前端上操作的时候,不知道为啥,总之就是一个订单不小心发起了两次支付请求,然后这俩请求分散在了这个服务部署的不同的机器上,好了,结果一个订单扣款扣两次. 或者是订单系统调用支付系统进

分布式事务解决(5):可靠消息的最终一致性方案-消息重复发送问题与业务接口的幂等性设计

一.消息消费流程的异常分析与处理 1.1.消息消费流程的异常点 1.2.消息消费流程的异常处理 方法:对于未确认的消息,采用按规则重新投递的方式进行处理. 问题:消息的重复发送会导致业务处理接口出现重复调用的问题. 未完,待续....

分布式高并发系统如何保证对外接口的幂等性?

详细请参考知乎上面的回答:http://www.zhihu.com/question/27744795 我觉得回答的比较好的,原文如下: 重复消息是SOA服务实现中非常常见的问题,你永远不要指望调用方每次请求消息不一样,对于读操作,重复消息可能无害,可对于写操作很可能就是灾难.可以通过幂等(Idempotent)模式处理重复的消息,基本处理思路是:1.调用者给消息一个唯一请求ID标识.ID标识一个工作单元,这个工作单元只应执行一次,工作单元ID可以是Schema的一部分,也可以是一个定制的SOA

micro-service(3):分布式事务和接口幂等性

分布式服务需要满足CAP原则,Consistency(一致性). Availability(可用性).Partition tolerance(分区容错性),但三者不可得兼:一般都会优先保证可用性和分区容错性,并且保证最终一致性.BASE理论是对CAP原则的补充,Basically Available,Soft state,Eventually Consistent,也就是当CAP三者不能兼得的时候,可以做到最终一致性. 大型应用一般需要做业务分拆以便于提升业务的可维护性和扩展性,但由于业务分布于

分布式接口幂等性

https://www.cnblogs.com/huaixiaonian/p/9577567.html 最近跟朋友聊起这个话题,想深入了解下,于是学习总结,记录下来,此文章参考以下博客综合而来表示感谢: http://blog.brucefeng.info/post/api-idempotent http://825635381.iteye.com/blog/2276077 https://www.cnblogs.com/leechenxiang/p/6626629.html 1. 接口调用存在

保证接口幂等性的解决方案(后台)

假如有个服务提供一个接口(服务部署在多个服务机器),接着有个接口是付款接口.用户在前端上操作的时候,一个订单不小心发起了两次支付请求,然后这两个请求分散在了这个服务部署的不同的机器上,结果一个订单扣款扣两次.这样的场景,就是接口没有保证幂等性的结果. 保证幂等性的核心 1.对于每个请求必须有一个唯一的标识. 2.每次处理完请求之后,必须有一个记录标识这个请求处理过了. 3.每次接收请求需要进行判断之前是否处理过的逻辑处理. 常见解决方案 1.业务表内唯一索引 如果要对创建销售出库单的接口保证幂等