扫码关注官方订阅号
例如一个产品订单金额为100元,3个人来为这张订单买单,每个人可以随意的支付自己想支付的金额,我的思路是每秒请求服务器中该订单剩余的支付金额,然后刷新显示给各个用户,但是这样会出现一种情况,就是在某一秒上,a和b同时看到剩余支付金额为30元,然后两人都去支付这个30元,就会导致超出,请问怎么在前端避免这种情况?
闭关修行中......
在支付前校验一遍,就是去支付平台的跳转之前,校验支付
在前端肯定避免不了这种情况的,你也不用每秒都去请求一次。
前端能做的就是在支付之前,向服务器请求一次剩余金额进行一次比较。但是由于支付流程比较多,因此这种比较没办法应付你说的情况。还需要后端在支付成功的前一刻进行校验,并且增加支付失败的机制。
前端其实是没办法完美的解决这个问题的。后端可以用队列的形式解决这个问题:每个买单的人都进行排队,每进来一个买单的,就用(总金额-买单金额),如果大于等于零,就下一个,如果小于零,就告诉前端现在的剩余价格是多少。
缓存打天下,支付提交先缓存,超过了不能支付。。。缓存一般不会有性能问题。。后面进入支付又未支付的再把钱数补回来
这种情况无法避免的,你想极端点,一个人付款的时候还剩90,结果他输表单输了两天,最后余额0.跟你遇到的情况类似。只能在提交表单的时候再验证一次。
由于用户支付的过程不可控,支付的花费时间不可控,因此一定会存在多个用户同时支付额超过待支付额的情况。
建议:
1.给用户设计一个叫【余额】的属性。
2.扣款时,按系统实际收到银行或第三方款项的时间戳进行排序,依次扣款。万一遇到小概率事件,比如同一个时间戳有两笔款项,那么就随机抽签决定顺序吧。
3.多用户同时支付造成的多余金额,按照原则【2】进行扣款后,把多余的钱退到用户余额里。
比如,某物品待付款为10元。
用户A支付后,银行或第三方在2000-01-01 00:00:01回调说成功支付5元,此时该物品待付款为5元。
用户B支付后,银行或第三方在2000-01-01 00:00:02回调说成功支付7元,此时该物品待付款为0元,且多出2元,退给B。此时用户B的余额为2元。
前端是没有办法解决的,建议采用任务队列,服务器每次只处理一个付款请求,这样就能减少复杂逻辑导致的不确定因素
微信扫码关注PHP中文网服务号
QQ扫码加入技术交流群
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
PHP学习
技术支持
返回顶部
在支付前校验一遍,就是去支付平台的跳转之前,校验支付
在前端肯定避免不了这种情况的,你也不用每秒都去请求一次。
前端能做的就是在支付之前,向服务器请求一次剩余金额进行一次比较。但是由于支付流程比较多,因此这种比较没办法应付你说的情况。还需要后端在支付成功的前一刻进行校验,并且增加支付失败的机制。
前端其实是没办法完美的解决这个问题的。
后端可以用队列的形式解决这个问题:每个买单的人都进行排队,每进来一个买单的,就用(总金额-买单金额),如果大于等于零,就下一个,如果小于零,就告诉前端现在的剩余价格是多少。
缓存打天下,支付提交先缓存,超过了不能支付。。。缓存一般不会有性能问题。。后面进入支付又未支付的再把钱数补回来
这种情况无法避免的,你想极端点,一个人付款的时候还剩90,结果他输表单输了两天,最后余额0.跟你遇到的情况类似。只能在提交表单的时候再验证一次。
由于用户支付的过程不可控,支付的花费时间不可控,因此一定会存在多个用户同时支付额超过待支付额的情况。
建议:
1.给用户设计一个叫【余额】的属性。
2.扣款时,按系统实际收到银行或第三方款项的时间戳进行排序,依次扣款。万一遇到小概率事件,比如同一个时间戳有两笔款项,那么就随机抽签决定顺序吧。
3.多用户同时支付造成的多余金额,按照原则【2】进行扣款后,把多余的钱退到用户余额里。
比如,某物品待付款为10元。
用户A支付后,银行或第三方在2000-01-01 00:00:01回调说成功支付5元,此时该物品待付款为5元。
用户B支付后,银行或第三方在2000-01-01 00:00:02回调说成功支付7元,此时该物品待付款为0元,且多出2元,退给B。此时用户B的余额为2元。
前端是没有办法解决的,建议采用任务队列,服务器每次只处理一个付款请求,这样就能减少复杂逻辑导致的不确定因素