抢购业务中 库存锁应该加在哪个步骤？

[Quiet_a]

如题。
在抢购业务中，应该在哪一步加锁减库存？ 下单？ 支付？
下单减库存：下单后不支付如何处理,（5-10分钟）订单过期？ 会不会影响抢购业务，引起少卖？
支付减库存：（锁应该加在哪里）点击支付？ 同上会不支付，还会引起加解锁问题。支付完成？会引起超卖吧？

请教别人给的一种解决方案：下单减库存（订单过期）。在抢购页面提示未支付数量。

各位大大，还有其他解决方案么。大家一般是怎么处理的。

[tlzjff]

我觉得你的问题设计到业务问题，也设计到技术问题 下单减库存：下单后不支付如何处理,（5-10分钟）订单过期？ 会不会影响抢购业务，引起少卖？ 我认为这个是业务问题，如果设计成10分钟不付款过期的话，应该把原有的可购买库存数量更新回去，使得整体库存可被消化干净 支付减库存：（锁应该加在哪里）点击支付？ 同上会不支付，还会引起加解锁问题。支付完成？会引起超卖吧？ 支付时，可以加一个锁（具体不同的系统可能枷锁的地方不一样，如果是单数据库的话，可找一个具有产品购买信息的产品行锁，至于性能问题，就不在这里过多讨论了，优化方案需根据具体情况再分析），之后可以用可靠的消息队列，只要进入消息队列，就返回成功，最好先落地流水，再执行付款，再进后续任务记录队列，为最差情况做数据超时回滚用，如果过程发生意外，则提示用户执行过程出现意外，请留意订单状态信息，后续需要做库存系统和购买流水记录的状态检查，如果存在流水，队列中不存在，则超过时间后，需要回滚用户，如流水表不存在，则用户扣款也未发生，无须回滚。 当用户支付成功，消息也进入了任务队列，后续的业务，就按照消费一条数据，同时减去一个库存的方式来做，做好事务和重试，并且最好也做好流水记录表，并且要做好幂等设计，如果出现意外，也需要单独回滚，因为用户已经支付成功了，这里无论如何即使人工接入，也要保证业务的成功，否则回滚代价太高，需要实现退款逻辑。

[青年卫大师]

最好使用缓存

[zc_levi]

秒杀之类的应用场景一般都是用缓存数据库redis实现，具体可以参考http://www.cnblogs.com/0201zcr/p/5942748.html

[tianfang]

1 并发请求内部排队下单（串行化），基本不用锁表，库存 2 支付才减库存。 3 超卖一定比例，但是要换个说法，比如Amazon用排队。抢购成功的超时未支付，超卖（排队）的人才能支付

[以专业开发人员为伍]

抢购就不应该（实时）减库存。 在抢购开始之前： 1. 可以先按照单品id生成n个抢购商品，它们都指向相同的商品资料。因为抢购结果需要跟踪有没有作弊，所以此方法最科学。 2. 也可以在一个独立的内存数组里管理模拟的内存数量，而并不与真实的库存数量同步。