#防重复处理总结
##背景
在业务开发中,我们常会面对防止重复请求的问题。当服务端对于请求的响应涉及数据的修改,或状态的变更时,可能会造成极大的危害。重复请求的后果在交易系统、售后维权,以及支付系统中尤其严重。
前台操作的抖动,快速操作,网络通信或者后端响应慢,都会增加后端重复处理的概率。
前台操作去抖动和防快速操作的措施,我们首先会想到在前端做一层控制。当前端触发操作时,或弹出确认界面,或disable入口并倒计时等等,此处不细表。
但前端的限制仅能解决少部分问题,且不够彻底,后端自有的防重复处理措施必不可少,义不容辞。
在接口实现中,我们常要求接口要满足幂等性,来保证多次重复请求时只有一次有效。
查询类的接口几乎总是幂等的,但在包含诸如数据插入,多模块数据更新时,达到幂等性会比较难,尤其是高并发时的幂等性要求。比如第三方支付前台回调和后台回调,第三方支付批量回调,慢性能业务逻辑(如用户提交退款申请,商家同意退货/退款等)或慢网络环境时,是重复处理的高发场景。
##尝试
这里针对“用户提交退款申请”的例子,说明一下尝试过的防重复处理方法的效果。
后端防重复处理的方式,我们先后尝试了三种:
####1)基于DB中退款订单状态的验证
这种方式简单直观,从DB查询出来的退款详情(包括状态)往往还可以用在后续逻辑中,没有花额外的工作专门应对重复请求的问题。
这种查询状态后进行验证的逻辑,从代码上线后就一直存在于所有含状态的业务逻辑处理中,必不可少。但对于防重复处理效果并不好:在前端添加防重复提交前,每周平均在25笔;前端优化后,每周降到7笔。这个数量占总退款申请数的3%%,一个仍然无法接受的比例。
理论上,任意次请求只要在数据状态更新之前都完成了查询操作,则业务逻辑的重复处理就会发生。如下图所示。优化的方向是减少查询到更新之间业务处理时间,可降低空档期的并发影响。极致情况下如果查询和更新变成了原子操作,则就不存在我们当前的问题。
####2)基于缓存数据状态的验证
Redis存储查询轻量快速。在request进来的时候,可以先记录在缓存中。后续进来的request每次进行验证。整个流程处理完成,清除缓存。以退款为例子:
I. 每次退款发起申请,读取缓存中是否有以orderId为key的值
II. 没有,则往缓存中写入以orderId为key的value
III.有,则说明有该订单的退款正在进行。
IV. 操作完清缓存,或者缓存存值的时候设置生命周期
与1)的发放相比,数据库换成响应更快的缓存。但是仍然不是原子操作。插入和读取缓存还是有时间间隔。在极致的情况下还是存在重复操作的情况。
此方法优化后,每周1笔重复操作。
####3)利用唯一索引机制的验证
需要原子性操作,想到了数据库的唯一索引。
新建一个TradeLock表:
CREATE TABLE `TradeLock` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`type` int(11) NOT NULL COMMENT '锁类型',
`lockId` int(11) NOT NULL DEFAULT '0' COMMENT '业务ID',
`status` int(11) NOT NULL DEFAULT '0' COMMENT '锁状态',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='Trade锁机制';
每次request进来则往表里面插入数据:
——成功,则可以继续操作(相当于获取锁);
——失败,则说明有操作在进行。
操作完成后,删除此条记录。(相当于释放锁)
目前已经上线,等待下周的数据统计。
####4)基于缓存的计数器验证:
由于数据库的操作比较消耗性能,了解到redis的计数器也是原子性操作。果断采用计数器。既可以提高性能,还不用存储,而且能提升qps的峰值。
还是以订单退款为例子:
每次request进来则新建一个以orderId为key的计数器,然后+1。
如果>1(不能获得锁): 说明有操作在进行,删除。
如果=1(获得锁): 可以操作。
操作结束(删除锁):删除这个计数器。
要了解计数器,可以参考:
##总结:
PHP语言自身没有提供进程互斥和锁定机制。因此才有了我们上面的尝试。
网上也有文件锁机制,但是考虑到我们的分布式部署,建议还是用缓存。
在大并发的情况下,程序各种情况的发生。特别是涉及到金额操作,不能有一分一毫的差距。所以在大并发要互斥的情况下可以考虑3、4两种方案。
爱迪生尝试了1600多种材料选择了钨丝发明了灯泡,实践出真知。遇到问题,和问题斗争,最后解决问题是一个最大提升自我的过程,不但加宽自己的知识广度,更加深了自己的技能深度。达到目标之后的成就感更是不言而喻。
- 作者:蘑菇街商家平台资金团队工程师 @木照
相关推荐
springboot2.1+redis+拦截器 防止表单重复提交详细完整介绍,所用到的文件都上传了,下载即可使用。自己花了半天整理,并且测试通过,使用在实际项目中的,希望对每一个下载的朋友有帮助。
在整个供应链系统中,会有很多种单据(采购单、入库单、到货单、运单等等),在涉及写单据数据的接口时(增删改操作),即使前端做了相关限制,还是有可能因为网络或异常操作产生并发重复调用的情况,导致对相同单据...
项目开发过程中接口面对防止重复请求、前台操作的抖动、快速操作、网络通信或者后端响应慢等等
Java-Base64算法_创新_防止表单重复提交 JAVA企业级基础课题(HashMap那些事) 企业架构师必备技能(JAVA核心技术反射) JavaWeb之基础(手写实现Tomcat服务器) java多线程编程 纯手写实现SpringIOC实现过程 JEE企业级...
问题描述: 快速点击会出现,重复触发事件,像后台发起多次请求,此时后台极端=短时间内多次请求,会出现并发问题,数据脏读 2.问题分析 :查看layerUI的API发现,系统的confirm是线程阻塞的,而layer.confirm是非...
有防止用户重复提交的功能; 有加速渲染前端界面的设计。 2.2 后端管理端功能 使用Vue + ElementUI实现管理后台各个功能界面; 界面简洁,主题统一; 管理员账号管理模块; 使用Spring Security安全框架实现认证、...
3,token机制:由于重复点击或者网络重发,或者nginx重发等情况会导致数据被重复提交。前端 在数据提交前要向后端服务的申请token,token放到 Redis 或 JVM 内存,token有效时间。提交后 后台校验token,同时删除...
2.2 防止重复提交2.1中如果是在并发的情况下,在支付成功但是并未开始修改为已成功的状态的时候,再有请求过来,这时候可能会造成重复支付的可能性,所以为了解决这个问题,可以把查询和变更状态操作进行加锁,将...
• 并发事务之间相互干扰,可能导致事务出现读脏,不可重复度,幻读等问题 • InnoDB实现了SQL92标准中的四种隔离级别 (1)读未提交:select不加锁,可能出现读脏; (2)读提交(RC):普通select快照读,锁select /...
1 说明 前段时间面试的时候,一直被问到如何设计...-防止并发产生超抢/超卖 2 流程设计 3 代码 3.1 服务端代码 class MiaoSha{ const MSG_REPEAT_USER = '请勿重复参与'; const MSG_EMPTY_STOCK = '库存不足'; con
事务控制语言(Transactional Control Language,TCL),用于维护数据的一致性,包括COMMIT(提交事务)、ROLLBACK(回滚事务)和SAVEPOINT(设置保存点)3条语句 二、 Oracle的数据类型 类型 参数 描述 字符类型...
线程安全,并发的知识有加深认知;当然,现在用过的东西并不是代表以后还能娴熟的使用,做好笔记非常重要; 1:必须明白为什么要使用线程池:(这点很重要) a:手上项目所需,因为项目主要的目的是实现多线程的...
作业平均周转时间=∑(作业完成时刻i-作业提交时刻i)/n个作业 (2)最短作业优先:在作业内容参差很不均衡时有合理性 (3)“响应比”最高的优先 “响应(系数)比”:作业响应时间(等待和运行)/...
SubmitOncePage:解决刷新页面造成的数据重复提交问题 SharpRewriter:javascript + xml技术利用#实现url重定向 采用XHTML和CSS设计可重用可换肤的WEB站点 asp.net的网址重定向方法的比较:面向搜索引擎友好 也谈 ...
另外他对我上一集中说Microsoft越来越不要脸也极为生气,因为相比之下,Sun也不怎么样,微软已经将C#提交设在日内瓦的ECMA(European Computer Manufacturers' Association,国际标准化机构欧洲电子计算机工业会)并...
C#编程经验技巧宝典源代码,目录如下: 第1章 开发环境 1 <br>1.1 Visual Studio开发环境安装与配置 2 <br>0001 安装Visual Studio 2005开发环境须知 2 <br>0002 配置合适的Visual Studio 2005...