php购买业务流程通用设计思路

php购买业务流程通用设计思路

• 设计表

1. 商品表

商品ID	数量	价格

2. 用户账户表

用户ID	账户

3. 用户商品表

商品ID

• 购买流程

大致流程为：商品展示，如果商品下架或者库存不足，关闭购买入口或者阻断用户进入。进入购买入口，选择相应的数量和商品，通常也会有相应的商品属性。点击购买，进入支付页面。点击支付，判断账户金额够不够，不够，中断交易。否则进行支付。支付完成触发再次检测商品库存，库存有，商品库存减1，用户商品表增加一条记录，用户账户表扣除相应金额。至此，整个购买流程结束。要注意的是，从检测商品库存开始，到购买结束。整个过程要锁表。就是说支付完成之后的整一个过程只有一个用户参与。防止超卖。

这里有个问题，有可能会出现同时登陆了同一个账号（其实在登陆的时候为了安全应该要杜绝这种情况，防止重复登陆）。所以，在支付完成更新用户账户表的时候最好也要判断下账户余额是否足够，避免用一份钱买两样商品。所以锁表过程中要判断库存和账户两个地方。整个过程中要封装成一个事务去处理。有一个地方出现错误，则整个事务回调。

目前大多数支付都不走站内的，例如微信和支付宝。支付在前面，支付完成之后通过支付服务商返回的回调结果通知进行相应的操作。由于不是站内支付。所以支付完成之后可能会出现几种结果。

1. 支付结果没有通知成功。（通常来说微信或者支付宝支付回调通知都用一定的策略，除非微信或者支付宝服务器出现问题。不然发生的概率其实很低。但是在于稳定性应该要把这种情况也考虑进去）
2. 支付结果通知成功，本地服务器出现错误。

无论是那一种情况，微信原则上没有收到服务器推送的业务完成推送都会按照一定的规则进行重发。服务端需要定时对未支付的订单进行检测。保证业务的流畅。如微信给你发送支付结果回调，但是你没有收到，你就要自发去查询支付结果。你只要保证操作支付结果的业务流程代码做好并发处理就可以。所以支付之前一定要做生成待支付订单，方便后续这种通知结果失败的时候可以根据待支付订单查询支付结果。我开始做购买业务的时候觉得没必要开始就生成这么多冗余的数据，觉得浪费数据库资源。后来被用户投诉明明支付成功，但是没有收到货。所以这个动作一定要做。如果觉得数据库冗余，可以定时清理这些无用的待支付订单。其实定时去检测待支付订单的实际支付情况的时候就可以进行清理了，把确定未支付的待支付订单删除。

另外服务器接收到回调的支付结果之后，最好是把回调数据做下日志的记录，便于日后的排查。这样你可以很方便知道你的业务流程为什么执行失败。这个动作也一定要做。

最后如果该业务由于时差导致不可挽回的地步。比如你在做一个秒杀功能。由于你的服务器刚好这时候挂了。等你修复好服务器的时候商品已经被其他人抢完了。这时候你就得采取最后的手段。退款给客人咯，不然还能怎么着。所以这时候就显现出做待支付订单的作用了吧。通常出现这种情况也是比较大的问题了。所以一定要保证服务器的稳定。因为对于好说的客人，你给他退款能解决问题还好。对于难缠的客人你可能还要赔偿别人相应的损失的或者承担相应的法律责任的。

这里又引申到另外一个问题。做秒杀功能的时候尽量避免超卖的情况用退款来进行处理。虽然这个逻辑没有问题。但是对于用户体验和业务流程来说。这都不是最理想的方法。你想想，你开一个100个库存的商品做秒杀，来了1000个人，最后有900个人都要做退款的。这显然不合理。而且这样随时可能把服务区拖垮。所以一般做秒杀功能都是用队列来处理的。像上面的例子。100个库存，我只要按照先来先到的原则把100个人放到队列里面。然后保证这100个人都有购买的资格。如果这100人中有人支付失败或者超时。则放出来待其他人去抢购。12306就是用这种模式来处理抢购火车票的。