例如一个产品订单金额为100元,3个人来为这张订单买单,每个人可以随意的支付自己想支付的金额,我的思路是每秒请求服务器中该订单剩余的支付金额,然后刷新显示给各个用户,但是这样会出现一种情况,就是在某一秒上,a和b同时看到剩余支付金额为30元,然后两人都去支付这个30元,就会导致超出,请问怎么在前端避免这种情况?
例如一个产品订单金额为100元,3个人来为这张订单买单,每个人可以随意的支付自己想支付的金额,我的思路是每秒请求服务器中该订单剩余的支付金额,然后刷新显示给各个用户,但是这样会出现一种情况,就是在某一秒上,a和b同时看到剩余支付金额为30元,然后两人都去支付这个30元,就会导致超出,请问怎么在前端避免这种情况?
在前端肯定避免不了这种情况的,你也不用每秒都去请求一次。
前端能做的就是在支付之前,向服务器请求一次剩余金额进行一次比较。但是由于支付流程比较多,因此这种比较没办法应付你说的情况。还需要后端在支付成功的前一刻进行校验,并且增加支付失败的机制。
前端其实是没办法完美的解决这个问题的。
后端可以用队列的形式解决这个问题:每个买单的人都进行排队,每进来一个买单的,就用(总金额-买单金额),如果大于等于零,就下一个,如果小于零,就告诉前端现在的剩余价格是多少。
由于用户支付的过程不可控,支付的花费时间不可控,因此一定会存在多个用户同时支付额超过待支付额的情况。
建议:
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元。
10 回答11.1k 阅读
6 回答3k 阅读
5 回答4.8k 阅读✓ 已解决
4 回答3k 阅读✓ 已解决
2 回答2.6k 阅读✓ 已解决
3 回答5.1k 阅读✓ 已解决
5 回答1.9k 阅读
在支付前校验一遍,就是去支付平台的跳转之前,校验支付