职业技术讨论:帐号余额,单订单优惠券提交订单时该实时减掉(冻结)。

金拱门 发布于 2015/07/21 00:08
阅读 1K+
收藏 4

为什么发在职业生涯呢?因为我觉得这是对我三年电商的一个总结。今天我发了一个动弹,就是吐槽公司某个网站余额减掉的方案愚蠢。结果引来一推人冷嘲热讽说:我网购过吗? 详情:http://my.oschina.net/Felldeadbird/tweet/6088277 

今天我们来认真讨论一下这个问题:

首先,作为电商理论上都会有帐号余额功能。主要用于退款后,钱优先打到用户帐号上,用于刺激用户消费。其次还有优惠券啊,积分等吸引用户消费的功能。而优惠券等可能会分单订单,多订单使用的情况。而我下午发的动弹,讨论的都是以单订单使用为大前提的。那么问题来了,帐号的余额、优惠券该实时减吗?(注:实时减,亦为冻结意思。下文不再详细叙述,感谢@刘禹星  的提点,可能我所实时减和大家理解的不一样

在思考答案之前,需要先考虑好,实时减余额和支付成功再减会带来什么样的影响呢:

提交订单,实时减余额、优惠券:用户当前账面有50元的余额,用户订单的货款金额为100元。用户提交后,程序即马上对用户的余额减掉,即用户实际支付金额为:100 - 50元。 当用户超过系统的有效支付时间而未支付后,系统自动还原被减掉的50元。

从上面可知,程序开发仅需要确保两点则可:1.用户提交订单时,只需要将抵消货款金额的余额、优惠券之类实时减掉,并告知用户最终支付金额则可。 2.将超过有效支付时间而未支付的订单中,抵消了部分货款的余额,优惠券之类返回给对应的帐号则可。

提交订单,不实时减余额,优惠券。在进行支付成功才减:

1.用户账面有50元余额,用户下订单001A(同为100元)。查看订单显示支付金额为 50元,但用户没有马上支付。 用户又下了一订单002B(100元)。订单显示支付金额为50元。这时候用户发现异常了,我不马上支付,怎样下单都是显示50元。聪明的用户选择了,点击A订单,跳转到支付宝去,先不支付。接着打开B页面,跳到支付宝。这时候在支付宝显示两张订单该支付的都是50元。用户支付成功后,在程序方面,肯定只有一张订单是可以正确修改支付状态。而另外一张的订单,由于余额不够抵消,支付状态会成为待审核。

2.同上的案例,但用户只下了订单A。然后网站显示用户要支付50元。用户跑来店面现金支付。在用户到店面后,客服打开后台,查看该订单显示应支付50元。就在用户给现金的那一刻,仓库QC对该用户前几天申请的退款进行了审核,于是乎,用户帐号多了30元。即一共80元。当客服收钱后,点击改订单状态为已支付时。程序马上扣掉了客人的80元余额。当然,这里客服是不知道程序已经多扣了客人30元。

上面的案例,程序需要考虑几方面:1.跳到支付接口前,需要实时计算一次用户该支付金额。2.由于是支付成功后才减余额的,因此支付接口回调时需要严格的判断。 3.对于后台改变订单状态的扣款也要同步修改。 4.程序员还要告诉客服,网站余额不是实时减的,收客人钱是要记得刷新页面。

---------

上面说了一推废话,可以看到后者对于开发的维护成本增大。而且稍不留神,就会扣多款,产生不必要的人力成本。当然,后者也一样可以走,只是按照正常的流程,肯定选第一种是最省事的。越复杂,越容易出问题。

就像以前公司经常出现库存负数的情况,于是乎聪明的领导想出了加入购物车实时减库存的好注意。可是,功能上线后,网站很快就被人恶意减库存了。然后。。肯定是恢复原版了。 当然,也没说实时减库存不好。而是要看适用范围,如:抢购。

说了这么多,我原本只是吐槽一下公司某个网站的设计问题,只是没想到招来这样的冷嘲热讽,实在看不过眼,特发此贴。最后,希望回复的人,别回复什么呵呵,有卵用这种屁话。是个程序员,就拿出你的例子来论证我的错误。

以下是话题补充:

@金拱门:本帖不再作回复,到此打住。 (2015/07/22 09:54)
加载中
0
java9
java9
火钳留名
金拱门
金拱门
别留这种无用的东西,这个是一个讨论技术的帖子
0
方棱
方棱
谁让你用白痴设定”、“屁话”这种词汇,这就是请大家来骂你的节奏啊。所以大家是在满足你的愿望而已。
方棱
方棱
回复 @首席撸破皮 : 你这个事儿从根上说,就是“业务规则作主导”还是“技术方案作主导”的问题。 但觉得你看不懂我说的,所以之前就用了觉得你看得懂的语言回帖咯。
金拱门
金拱门
我用什么形容词来描述问题是我决定的。而且我都说了是吐槽懂吗?你不讨论技术就别唧唧歪歪,一副自己很懂的样子,又不拿出例子来论证。纯粹是找骂。
0
朱坤朋
朱坤朋
你的第一种方法最少要做两次事务(扣余额,扣现金/退余额),第二种通用方法只需要做一次(充到钱包扣总额)。你觉得对程序员来说那种方案最优?
金拱门
金拱门
这个倒没所谓,事务开启一次就行了。后面只要出错就回滚。这是很好的机制。正如第二种方法,确实是不优雅的做法。我在京东下单,他们都是马上减掉的。
0
九阁网趣
九阁网趣
-..-订单提交使用了这些东西就要,记录在案自然不能用啦。
0
西红柿幽幽子
西红柿幽幽子
我就想问,你们订单确认页面进到支付页面,是不进行审核的吗?
金拱门
金拱门
回复 @西红柿幽幽子 : 不好意思,我理解错了
西红柿幽幽子
西红柿幽幽子
回复 @首席撸破皮 : 我说的审核不是人工审核,是验证实时可用的余额、优惠卷等,比如你第一个例子,点击A订单进了支付,然后点击B订单的时候,就应当提示优惠卷已占用
金拱门
金拱门
回复 @justintung : 看来你是一个小白用户。你去赚客吧 搜一下 14年 大概 4月份的 易迅的帖子。 当时易迅搞了一个可乐活动。有一个逻辑漏洞。用户下单可以免运费,免费拿可乐,纸巾。。。有不少恶意下单,被系统列入人工审核的流程了。
justintung
justintung
回复 @首席撸破皮 : 别瞎说,自己去试一试吧。怎么可能在这一步中有人工审核
金拱门
金拱门
回复 @justintung : 有!易迅。
下一页
0
打怪兽的汪
打怪兽的汪
在进入支付页面时,A打开后,B再打开是50块的状态应该已经是占用状态,这是付钱时最基本的排他性
金拱门
金拱门
嗯,又学到新东西了。排他性。 其实我上面说了这么多。都是废话。哈哈,你们总结的言辞太精准了。
0
懶蟲
懶蟲

费用计算全部交由一个应用去处理采用队列或者是在计算费用时锁定(比较耗内存)。

建议有空看一下关于银行支付系统方面的资料。

金拱门
金拱门
你这个高端太多了。
0
Credo-Zhao
Credo-Zhao
好多字,不看了,遁了...
0
Ethan丶Lee
Ethan丶Lee

订单生成与支付宝订单生成概念应该不一样。下单,但支付宝订单未生成,余额还是空闲状态,支付宝订单生成后,则余额被占用。

实体店支付与货到付款应该类似,预付当前可用余额,余下到实体店后支付,完成整个订单支付过程。退款回来的余额不会占用。

没做过这东西,只是个人理解。

金拱门
金拱门
是。我估计很多拿支付宝的余额来说我不懂。
0
小文大哥哥
小文大哥哥

i am coming

我不多说,就事论事吧

我就照着原帖你的槽点来一步步解答。虽然我没做过电商,但是我网购花了也有10多w了吧。

1:用户的网站帐号余额下订单时竟然不实时减

我从来没有在哪一个电商网站下订单的时候就会扣除我的账户余额。难道不会收到一条短信提示“亲爱的用户,你的订单已经提交,我们已经把你的钱扣了,以后出现什么问题我们再退给你吧!”。我觉得我的呵呵哒,描述的很准确。我至今没见过这样的设计,而且以后也不会见到吧?除非你当了哪家电商的cto+pm+ceo+coder

2:等订单支付了才减。这种白痴设定不知道谁想出来的

存在即合理,请你这样评论别人的时候自己多想想

3:但要是用户帐号余额发生变化,整体代码没控制好,带来的后果是灾难性的数据不一致

确定支付,扣钱。余额才会发生变化,你所谓的发生变化带来灾难性的结果,是你主观强加在你的思维里,因为你一直认为是下订单会扣钱,所以余额会发生变化,所以你会认为余额好像在哪里都变化,其实很简单就只是支付成功才会变啊。整体代码需要控制吗?明显不需要啊。只需确定支付-扣款-订单完成一切都是这样简单合理。技术源自于生活。

4:实时减的话,只要控制好下单就完成了。越复杂,越容易出问题。

你有没有想过事实减是在确定支付的时候,为什么非要提前到下订单呢?一切本来就是正常的,你非要让他混乱。我一直是一个崇尚简单的人。所以我理解你所说的其实也很简单。

5:还有你最后为了挽回面子找出来的优惠券

还是呵呵哒开头,优惠券你订单使用的时候只是标记该优惠券已被使用,如果订单过期再把优惠券的状态改回来。但是优惠券是商家的,想怎么玩就怎么玩,可是钱是用户的啊。你想抢啊?


现在该你了。

小文大哥哥
小文大哥哥
回复 @西红柿幽幽子 : 没关系我就是一土包子。但是我不乱喷,人也挺好。
西红柿幽幽子
西红柿幽幽子
分析的不错,不过你最好去了解一下“存在即合理”是啥意思,不懂的词语乱用会显得没文化的
当前问题已关闭评论
返回顶部
顶部