mysql 减库存并发问题

[kikione]

减库存数量为 num

update mytable set inventory = inventory-num WHERE id= 1 and inventory >=num

这样减库存不用加乐观锁和悲观锁，也可以是吧

但是有什么弊端吗

[kikione]

@mazyi 并发不超过十个，所以没有缓存也可以吧

[leafre]

@kikione 不是高并发性能没问题，字段再上个 unsigned int 保底

[as9567585]

乐观锁

[encro]

应该没有问题，
如果不相信可以用`select balance from user for update`这样的，
性能也没有任何问题。

[bucketcheng]

read commit 模式以上都没有问题，主要是看你事务大小，你如果事务时间比较耗时，而且并发比较高的话，可能话等锁超时，就看并发量

[bucketcheng]

都是操作这条库存行的前提

[gosidealone]

@bucketcheng 对的，我公司和楼主也是一模一样的处理方法，然后事务耗时，并发高，就出问题了。有什么好的解决方法吗

[bucketcheng]

@gosidealone 比较简单方式是 把更新这个冲突最频繁的放在最后更新，减少行锁时间，其次是减少事务粒度，及合并更新，在就架构上做改造，改动就比较大了，我们在这方面做了挺多工作的，

[sujin190]

sql 没问题，但是实际业务中意义及用处不大，正常的订单中不可能只买一件商品，以及下单过程中还有优惠折扣促销处理等等的流程，这样即意味着大量的回滚流程且开事务时间过长，效率不会很高，而且多件下单的时候很容易导致死锁问题

[gosidealone]

@bucketcheng 那我想问下，放在最后更新为什么能减少行锁时间？因为事务没提交完就一直锁着吗

[sujin190]

@gosidealone #30 必然的啊，否则事务用来干嘛的，所以实际业务中多件商品下单这种操作如果不排序，分分钟死锁

[xuanbg]

sql 没问题，扯东扯西各种问题的，大概都是在 show 自己懂得多吧，好为人师果然是一种人性。好吧，我从业务角度来说我对减库存的理解。

其实，除了特殊商品，一般来说就是数量有限，譬如车票、二手货等不能超卖，正常的商品谁管你超卖多少啊。生产 /采购部门自然会把你卖掉的货生产出来 /采购回来补上库存缺口。

[myd]

没问题，不会超卖。

[xe2vforesu]

没问题，不会多卖，也不会少卖。但是高并发场景下存在锁竞争，死锁检测等性能问题，进而导致系统处理能力降低。

[Chad0000]

我的方案是直接使用 queue ，一个消费者负责增减库存。库存在 Redis 中，带版本号。读从 Redis 中，写同时写。版本号在写时加入判断可确保不会有脏数据。

queue 性能还可以，一般你的系统不会一秒上万修改库存请求。

以上方案已在生产环境使用

[love2020]

你需要考虑并发修改为负数、ABA 问题（版本），幂等性。 通常可以采用 SELECT & SET & CAS 解决。

[jorneyr]

没问题，MySQL 有行锁

[sujin190]

@Chad0000 #35 那你这如何和下单流程的事务做绑定呢，先减库存的话，万一你这下单最后又失败了，你这库存如何恢复，后减库存的话，中间有时间差，也不能保证不超卖吧

[Chad0000]

@sujin190 支付前可以 Lock 库存。支付成功后出库失败，则订单需要自己处理取消逻辑，达到最终一致即可。

[sujin190]

@Chad0000 #39 不，我说的只是下单失败的情况，按这个逻辑，Lock 库存需要在商品有效性检查的库存校验时就要完成，而实际业务中下单后续商品还有其它校验流程，接着还有地址检查，优惠券营销促销折扣，风控校验等等一系列过程，这些都是要做一致性绑定的，更不要说后面的支付流程了