第三方接口,安全机制
今天面试遇到的问题发现我们项目里边关于事务,自己做了支付宝接口,我们自己是一个区块链商城,好像在提现过程中我们只做了邮件认证,没有考虑到事务的问题,面试官给我说的一个机制幂等性,希望在以后工作中能不要忘了,总结一下
什么是幂等性?
抄用一段数学上的定义:f(f(x)) = f(x)。x被函数f作用一次和作用无限次的结果是一样的。幂等性应用在软件系统中,我把它简单定义为:某个函数或者某个接口使用相同参数调用一次或者无限次,其造成的后果是一样的,在实际应用中一般针对于接口进行幂等性设计。举个栗子,在系统中,调用方A调用系统B的接口进行用户的扣费操作时,由于网络不稳定,A重试了N次该请求,那么不管B是否接收到多少次请求,都应该保证只会扣除该用户一次费用。
幂等性一般应用于一些协议之上,简单点说,在一个业务流程处理中,我们需要一个不重复的业务流水号,保证幂等性。举个例子来说:
一个用户在网页上发起一笔充值请求,浏览器引导用户去用银行账户支付,成功后系统会给用户充值,从协议上,我们通过全局唯一的订单号贯穿整个业务流程,我们列举在银行支付成功后回调系统,进行充值的步骤进行说明
- func pay_notify(orderid,value,state){//有问题的实现
- order = db.query("select * from payorder where orderid=$orderid");
- check(order,orderid,value,state);//判断支付金额是否与订单金额一致,判断是否是支付成功回调。
- if(order.state=='未支付'){
- db.update("update payorder set state='已支付' where orderid=$orderid");
- charge(order.username,value);//执行充值
- }else{
- return result("订单已处理")//返回订单已处理,或者返回处理成功
- }
- }
问题在于,当回调出现并发时,order.state已经是脏读数据了,有可能重复充值,该实现并不能100%保证幂等。
三种改进方式
1、悲观锁,select for update 整个执行过程中锁定盖顶打对应的记录
2、乐观锁,affectrows = db.update(update payorder set state = '已支付' where order=orderid and state='未支付'),如果affectrows=1,执行充值,否者失败返回 已处理。
3、定义notifylog表,orderid为unique key或者primary key,执行前,先insert,若insert成功则执行充值,否则返回已处理。以上简单例子用以说明幂等性常用应用实现,在SOA化系统中,可能很多原子功能都被拆分到不同的进程里,如charge充值这个函数,可能在另一个进程中,那么整个业务的链路就会更长,可能回调成功了,但是充值失败。同理,只要充值接口保证幂等性,对于已经回调过但是充值结果未返回的请求,回调接收程序,应当重复发起充值请求。更深入更复杂的应用场景,在数据一致性中再细讲。
4、总结
以上文章有的是摘要别人的写法,不过讲的很透彻,大家可以把这个思想记下来,为遇到这样的问题有一个解决的方向。