幂等性大话题
幂等性的数学表达式:f(f(f(…))) = f(x)
类型解释
-
查询的幂等性
- 查询操作,天然是幂等的,同样的数据,无论你查询多少次,都不会对数据造成改变。
-
更新的幂等性
- 更新操作,可能存在重复更新的可能性,因此需要做其他的操作来保证幂等性,可以考虑使用数据version,行锁、分布式锁等来处理。
-
新增的幂等性
- 新增操作,存在重复新增的可能性,可以在表中添加唯一索引或者联合唯一索引的方式来处理。
-
删除的幂等性
- 删除操作,本身就是幂等的,无论删除多少次,参数相同的情况下,删除结果都是相同的。
REST 中的幂等操作
GET、PUT, DELETE 都是幂等操作,而POST 不是幂等操作;
分析
GET 请求,对资源做查询多次,此实现的结果都是一样的。
PUT 请求,将A修改为B,它第一次请求值变成了B,再进行过多次此操作,最终的结果还是B,与第一次执行的结果是一样的,所以PUT也是幂等操作。
DELETE请求,同理可得,第一次将资源删除后,后面多次进行此删除请求,最终结果是一样,资源删掉。
POST请求,因为一次请求添加一份新资源,二次请求则添加了两份新资源,多次请求会产生不同的结果,因此POST 不是幂等操作。
题外话,和分布式事务相比,幂等设计的优势在于它的轻量级,容易适应异构环境,以及性能和可用性方面。在某些性能要求比较高的应用,幂等设计往往是唯一的选择。
HTTP幂等 N > 0
HTTP 协议本身是一种面向资源的应用层协议,
对HTTP协议的使用实际上存在着两种不同的方式:
**一种是Restful的,**它把HTTP当成应用层协议,比较遵守了HTTP协议的各种规范;
**另一种是SOA(面向服务架构)的,**它并没有完全把HTTP当成应用层协议,而是把HTTP协议作为了传输层协议,然后在HTTP之上建立自己的应用层协议。
无论是SOA还是RESTful的web API设计都应该考虑幂等性。
拓展了解
唯一索引,可以防止新增脏数据
比如:唯一索引或唯一组合索引来防止新增数据存在脏数据,
当表中存在唯一索引,并发时新增报错时,再查下一次就可以了,数据应该已经存在了,返回结果即可。
穷举业务场景:
账户资金记录操作,创建资金账户操作,创建存管账户操作,促销活动返现,发券操作等。
Token机制,防止页面重复提交
集群环境:采用token加redis,因为redis是单线程的,处理需要排队
单JVM环境:才有token加redis或token加jvm内存
处理流程:
1.数据提交前要向服务端申请token,然后把token放到redis或jvm内存中,设置token有效时间
2.提交后先进行校验token,同时删除token,生成新的token返回
Token feature:
要申请一次有效性,可以限流。
注意redis要用删除操作来判断token,删除成功代表token验证通过,如果用select+delete来校验token,存在并发问题,不建议使用。
悲观锁:
获取数据的时候加锁获取
select * from table where id = xxx for update; //添加行锁
注意:ID字段一定要是主键或唯一索引,不然是锁表,悲观锁使用时一般伴随事务一起使用,数据锁定时间可能会很长,根据实际情况选用。
乐观锁:
乐观锁只是在更新数据那一刻锁表,其他时间不锁表,所以相对于悲观锁,效率高。
乐观锁的实现方式多种多样可以通过version或者其他状态条件:
1.通过版本号实现
update table set name=#name#,version=version+1 where version = #version#
2.通过条件限制
update table set avail_amount = avail_amount-#tenderAmount# where avail_amount-#tenderAmount# >= 0;
或
update table set avail_product = avail_product-#buyProduct# where avail_product-#buyProduct# >= 0; //防止超卖
这个情景,只更新是做数据安全校验,适合库存模型,扣库存和回滚库存,性能更高。
注意:乐观锁的更新操作,最好用主键或唯一索引来更新,这样是行锁,否则更新时会锁表,上面两个sql应该优化成行锁。
update table set name=#name#,version=version+1 where id=#id# and version = #version#;
update table set avail_amount = avail_amount-#tenderAmount# where id=#id# and avail_amount-#tenderAmount# >= 0;
继续拓展
分布式锁:
还是拿插入数据来说,如果是分布式系统,构建全局唯一索引比较困难,例如唯一性的字段没发确定,这时候可以引入分布式锁,通过第三方系统如redis或zookeeper,在业务系统插入数据或者更新数据,获取分布式锁,然后做操作,之后释放锁,这样其实是把多线程并发锁的思路,引入多个系统,也就是分布式系统中的解决思路。
要点:某个长流程处理过程要求不能并发执行,可以在流程执行之前根据某个标志如用户mbId+后缀获取分布式锁,其他流程执行时获取锁就会失败,也就是同一时间该流程只能有一个能执行成功,执行完成后,释放分布式锁。
select + insert 方式
并发不高的后台系统,或者一些任务JOB,为了支持幂等,支持重复执行,简单的处理方式是,先查询下一些关键数据,判断是否已经执行过,在进行业务处理,就可以了。
注意:核心高并发流程不要用这种方法。
状态机幂等
在设计单据相关的业务,或者是任务相关的业务,肯定会涉及到状态机即状态变更图,就是业务单据上有个状态,在不同的情况下会发生变更,一般情况下存在有限状态机,这时候,如果状态机已经处于下一个状态,这时候来了一个上一个状态的变更,理论上是不能够变更的,这样的话,保证了有限状态机的幂等。
注意:订单等单据类业务,存在很长的状态流转,一定要深刻理解状态机,对业务系统设计能力提高有很大帮助。
业务分析
对外提供接口的api如何保证幂等
银联提供的付款接口:需要接入商户提交付款请求时附带:source来源,sequence序列号,source+sequence在数据库里面做唯一索引,防止多次付款,并发时,只能处理一个请求。
重点:对外提供接口为了支持幂等调用,接口有两个字段必须传,一个是来源source,一个是来源方序列号sequence,这两个字段在提供方系统里面做联合唯一索引,这样当第三方调用时,先在本方系统里面查询一下,是否已经处理过,返回相应处理结果;没有处理过,进行相应处理,返回结果。
注意:为了幂等,一定要先查询一下,是否处理过该笔业务,不查询直接插入业务系统,会报错,但实际上已经处理了。
SOA 重复消息幂等设计
重复消息是SOA服务实现中非常常见的问题,永远不要指望调用方每次请求消息都不一样,对于查询操作,重复消息可能无害,可对于写操作可能就是惊天大BUG。
可以通过幂等模式处理重复的消息,基本处理思路是:
- 1、调用这给消息一个唯一请求ID标识。ID标识一个工作单元,这个工作单元只应该执行一次,工作单元ID可以是Schema的一部分(个人理解请求参数),也可以是一个定制的SOAP Header(请求头Head),服务调用的约定是这个唯一请求ID标识是必传的;
- 2、接收者在执行一个工作单元必须先检验该工作单元是否已经执行过。检查是否执行的逻辑通常是根据唯一请求ID,在服务端查询请求是否有记录,是否有对应的响应信息,如果有,直接把响应信息查询后返回,如果没有,那么就当做新请求去处理。