求助关于同时支付一个订单的问题

例如一个产品订单金额为100元,3个人来为这张订单买单,每个人可以随意的支付自己想支付的金额,我的思路是每秒请求服务器中该订单剩余的支付金额,然后刷新显示给各个用户,但是这样会出现一种情况,就是在某一秒上,a和b同时看到剩余支付金额为30元,然后两人都去支付这个30元,就会导致超出,请问怎么在前端避免这种情况?

阅读 4.9k
7 个回答

在支付前校验一遍,就是去支付平台的跳转之前,校验支付

在前端肯定避免不了这种情况的,你也不用每秒都去请求一次。

前端能做的就是在支付之前,向服务器请求一次剩余金额进行一次比较。但是由于支付流程比较多,因此这种比较没办法应付你说的情况。还需要后端在支付成功的前一刻进行校验,并且增加支付失败的机制。

前端其实是没办法完美的解决这个问题的。
后端可以用队列的形式解决这个问题:每个买单的人都进行排队,每进来一个买单的,就用(总金额-买单金额),如果大于等于零,就下一个,如果小于零,就告诉前端现在的剩余价格是多少。

缓存打天下,支付提交先缓存,超过了不能支付。。。缓存一般不会有性能问题。。后面进入支付又未支付的再把钱数补回来

这种情况无法避免的,你想极端点,一个人付款的时候还剩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元。

前端是没有办法解决的,建议采用任务队列,服务器每次只处理一个付款请求,这样就能减少复杂逻辑导致的不确定因素

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题