幂等性

老婆问了个问题,什么是“幂等性”?这个问题,从现象上好解释,例如今儿是618大促,购物车添加了丰富的商品,满心欢喜地点击了支付按钮,支付成 功了,但是返回的时候网络异常,不知道是不是扣款成功了,实际上在服务端货款已经扣了,此时再点击支付按钮,如果第二次扣款成功,则就是多扣钱了,如果第 二次扣款不成功,符合我们的预期,说明这个支付的功能,满足“幂等性”。


从理论上讲,HTTP/1.1中对幂等性的定义是:一次和多次请求某一个资源对于资源本身应该具有同样的结果(网络超时等问题除外)。也就是说,其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。


从上面定义看,关注以下几个点:

1.幂等不仅仅只是一次(或多次)请求对资源没有副作用。

2.幂等还包括第一次请求的时候对资源产生了副作用,但是以后的多次请求都不会再对资源产生副作用。

3.幂等关注的是以后的多次请求是否对资源产生的副作用,而不关注结果。

4.网络超时等问题,不是幂等的讨论范围。


在分布式环境下,系统之间不同服务的相互调用,需要关注幂等性的设计,幂等性是系统服务对外一种承诺(而不是实现),承诺只要调用接口成功,外部多次调用对系统的影响是一致的,声明为幂等的服务会认为外部调用失败是常态,并且失败之后必然会有重试。


在 概念上,幂等和防重,还是有些区别。重复提交是在第一次请求已经成功的情况下,人为的进行多次操作,导致不满足幂等要求的服务多次改变状态。而幂等更多使 用的情况是第一次请求不知道结果(例如网络异常)或者失败的异常情况下,发起多次请求,目的是多次确认第一次请求成功,却不会因多次请求而出现多次的状态 变化。听着有些绕口,关键是他们的初衷不同,防重是明知成功还要做,幂等是未知结果还要做。


对于数据库增删改查的操作,不同的操作,不同的场景,对于幂等性,会是不同的满足,

1. 查询操作,是天然的幂等,例如select a from t where c=1,无论执行多少次都不会改变状态。

2. 删除操作,一般情况下,多次请求的结果,是相同的,只会删除一次。

3. 修改操作,不同场景,结果可能不多,

例如update t set c=2 where d=1,无论执行多少次,状态都是一致的,符合幂等性。

例如update t set c=c+1 where d=1,每次执行的结果,都会发生变化,这是非幂等的。

4. 插入操作,重复提交,如果业务逻辑上未作判断,则会插入多条,不符合幂等性。


如果服务端符合幂等性,其实是增加了服务端的设计复杂度,简化了客户端的处理逻辑。满足幂等服务的,毕竟需要查询上一次的执行状态,如果没有则认为是第一次请求,并且在服务改变状态的业务逻辑前,存在保证防重复提交的逻辑。


关于幂等性设计的实现,有不少的方法,例如乐观锁、分布式锁、token令牌等,各位可以从网络上得到借鉴,此处不再赘述。


作为吃瓜群众,尤其像支付场景,必须支持幂等,否则先崩溃的可能不是系统,而是我们自己。

640?wx_fmt=png

展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客
应支付0元
点击重新获取
扫码支付

支付成功即可阅读