电商项目中库存管理(问答式)

【今日话题】

电商项目的库存设计，如何不卖超，取消订单把库存加回去，不能多加 - 沈括号

1. 这个说一个之前处理并发的经验哈，情况应该是类似的，写sql的时候多加一个条件，用update tbl set col = col - num where col ≥ num,这样子吧 - 骑马爬树

2. 再加个定时任务去检查用户是否下单 没有的话 update col=col+1 - sky

3. 这种库存问题之前讨论过吧，我碰到这种库存或者并发问题都是用缓存锁解决的，屡试不爽 - lwPan

4. 事务加锁。不会卖超，所以不存在加回去的情况。 - 周志

5. 数据库锁扛不住的 - tiyee

回: 可以结合队列 - sky

6. 队列加update tbl set col = col - num where col ≥ num，已经一年多了，绝对没问题 - null

7. cache + db 吧，最保险的 - 踏雪无痕

8. 这样的问题主要还是看场景，不同量级的请求量需要不同的方案。量级小的数据库加锁，量级大的就是队列

回: 上面的说法不太赞同，队列、缓存什么的，是非常常见且性价比极高的优化手段，在不影响进度的前提下，能做到90分，为什么要拿60分来要求自己；万一有一天产品火了，这时候才吭哧吭哧的改和重构，自己累不说，还影响产品；一开始设计的全面一些，后续能更好的支撑业务发展，节省业务发展的时间成本和服务器上的资金成本 - 廖强

9. 其实控制库存扣取返回不超卖不是很大问题，问题在于经过多个系统交互后，库存一致性就出问题了 - 泉-June

10. 只要有transcation log 都不怕啊

每个replication一直apply transcation log就好了 - Ragnarok

11. 如果返回多了，就会超卖

关键是有方案控制库存的整个流向保持一致 - 泉-June

回: 处理到卖完的时候 就每次返回失败就好啦？

嗯 这个只要用分布式的文件系统就好了把。。 - 亚楠哥

回: 那要看是下单扣还是加购物车扣 - 泉-June

回: 加购物车可以分为几个transcation Lock(1) ... Buy(1) ... 之类的 只要保证数据流向正确就好了 - 亚楠哥

12. 电商不是那么简单的，前端平台也不是一家两家，比如天猫京东唯品会等等，每个平台店铺对应的仓库其实都是一个，平台和电商系统之间的延时要考虑，还有的平台，比如贝贝，付款半小时后订单才能同步到商家，这个库存同步就有半小时时差 - 徐刚

回: 这个存量应该有一个大概的估计。。。感觉后面检查库存的时候才能正式确定订单 - 亚楠哥

13. 我认为，如果有不同平台的销售，那仓库数据就应该分仓，再过段时间调整一下，卖得慢的仓库划拨卖得快的仓库，同时更新到销售平台。销售平台库存与仓库数据一致，就不怕超卖了。 - 李三 ??

14. 加购物车、确认页都会检查库存，最后提交订单时实际减扣库存。所以运气不好的话会遇到能添加购物车，但是提交订单失败的情况。提交订单是事物操作，如果失败就库存回滚；订单取消的话库存也会回退 - rao

15. 分仓会影响销售，有的平台卖的好，没货了，有的平台的仓还有货，卖不动

一般是给各个平台一个比例，平时比例和可以超一点，毕竟各平台销售情况不一样，库存报警的货比例和调小一点，个别平台遇到促销活动，提前锁定一部分货 - 徐刚

回: @徐刚 所以我才说过段时间调整，划拨仓库。又不是分完就不动了。

先按预估各平台销售情况来分配，然后再及时按实际情况调整。 - 李三 ??

回: 分仓对物流人员来讲，也是问题，多分一个就增加一倍工作量 - 徐刚

回: 逻辑分仓，不是物理分仓。

除非你各平台的物理仓库也是分开好远的，那如果要先调拨就麻烦了。 - 李三 ??

回: 那和分比例没区别 - 徐刚

回: 是没什么区别，但是不能因为比例高就可以超一点吧，万一其它平台也卖完了，你就没货了。所以还是严格按存量来卖。再根据库存报警来及时调整。 - 李三 ??

回: 看货品和个别平台活动情况了，平时基本都是超比例分配，加活动期锁仓，实践经验，供参考 - 徐刚

16. redis inc - a斌

17. 在网速特别慢的时候，多次刷新会有几率触发同订单多次减库存，取消订单时将库存加回去也会一样，如何保证库存增加减少时同一个订单只成功一次？ - 沈括号

回: 我之前做过的经验是: 在第一次进入页面生成一个唯一的token。表单提交的时候带上，校验下这个token是否已经完成，完成了就忽视，没完成就插表或者其他操作。 - 如末

18. 在缓存里面设一个标志位，每个订单号存一个，setnx成功才执行db的加减操作 - 骑马爬树

19. 电商的设计得不超卖还是很好做的吧，下订单的时候开启事务，库存减少时只需where条件中校验一下，创建订单；订单超时或者取消订单的时候，再开启事务，更新订单状态，将库存再加回去即可。下订单或者取消订单的时候，同一个订单号根据订单的状态进行处理即可

前面说在缓存里面设置标志位的方法不太好，如果标志位设置成功，但是db执行加减操作失败，会有问题 - 廖强

回: 高并发的情况下，where检查如果主从不同步及时获知主从延时过慢，还是容易导致问题，如果直接where主库，也容易带来写入性能问题，靠事务比较妥当，但是性能也是问题，使用redis设置事务锁来替代MySQL的事务锁会好些。但是如果redis不可靠，那也容易出现问题，所以我们这边redis作为重要的逻辑使用，会双写2个redis，只读一个redis，一个redis坏了，直接切到另一个redis - carlsonlin

回: Update中带where条件，不是直接select - 廖强

回: update是最恐怖的，一个update的完成得先read再write。比select还多一步。

当然了，如果不是高并发场景，一些都是浮云啊，把所有逻辑都扔数据库里面完成就行了，开发超快 - carlsonlin

回: 还更恐怖....,mysql更新前都是要拿到数据再更新。有没有where的区别不大，前提是已经主键更新了

另外，依靠redis 做mysql 的事务锁，acid很难保证，除非用mysql 的xa - 廖强

回: update前MySQL需要寻址更新节点，还是会涉及到磁盘寻址的，其实和select差不多的道理，找到之后，才写入。所以说还是蛮恐怖的。

acid只能靠程序+redis了，尽量做好进程挂掉的回退方法，不管是cgi还是redis还是其他原因

http://www.cnblogs.com/wenxiong/p/3954174.html

这篇文章大家可以看看，关于redis做分布式锁的 - carlsonlin

回: 你需要再了解一下mysql，首先，mysql的update本身就会从磁盘去拿数据，和那个where条件没有关系；其次，innodb buffer本身就把很多数据装进了内存，很多时候除了事务提交以及刷脏页以外不设计io

你说的那个文章是非常简单的分布式锁，建议你读一下mysql事务的相关文章。举个例子，一个事务中涉及2个sql语句，第一个sql语句执行成功后，第二个sql语句执行失败，第一个sql语句需要回滚，这不是redis锁能解决的 - 廖强

回: 好吧，我承认我对MySQL了解不深入，但有一些问题。1、update不需要查数据么？不然咋知道update哪个点？如果查数据不靠update的where来检索咋检索的？2、redis分布式锁不能涵盖所有场合啊，肯定不能取代DB的事务啊，比如你说的几条sql包括roll back。。 - carlsonlin

回: 嗯，你说的1这个问题，可能我们沟通理解不一致。我前面说那个更新的时候，是说在主键更新的基础上加上一个and 库存>=订单中的数据，这么一个限制条件。

用来确保不会超卖的

2. 在电商订单和库存的设计中，redis锁几乎没有作用

redis还是不错的，也不要太过否定

我们用得很多啊，feed和社交关系链都是用的redis

要会运维，redis还是有一定成本和门槛的 - 廖强

回: 首先，redis 不是个好东西，第二，redis 不适合做这个

用多了你就知道坑了

是 redis 自身的问题。通过运维修修补补不靠谱。不如直接用靠谱的东西

redis 只适合做单机临时存储 - 塔克斯

回: 我可以用redis锁来保证一个最大粒度的操作啊，包括涵盖的多个sql。比如这么个场景。1、用户因为网络问题或者服务器延迟导致多点了两下，重复下单，每个下单的操作（特别是股票，下单前的N多查询和计算，最后才能写入）。如果redis的事务锁在前期生成就能挡住这部分的下单操作的前期工程，省了不少事情。。2、还有更多的场合、、

我觉得还是看场景吧，redis我们这边用在很多过亿的访问场景 - carlsonlin

回: 第一个问题，为什么要用锁呢，你缓存里面放一个标志位就搞定了

redis不止单机的cache，很多场景下都有用，我们目前有不少redis服务器

那只能说我们对锁的理解不一致，前面他的需求是去重的功能 - 廖强

回: 锁本来就是一个标志位 - 塔克斯

回: 是啊，如果站在各自的场合就可能不太一样了

反正解决问题的方法很多 - carlsonlin

回: 锁的原语是lock和unlock，跟是不是标志位什么的，可能关系不大 - 廖强

回: 我的场合里面就需要lock和unlock，这里的标志位具体是啥意思？ - carlsonlin

回: 标志位是他自己实现了一个锁。。。 然后他还不认为那是锁。。。 - 塔克斯

20. 看你是常规销售还是秒杀

合理一些的话，可以采用队列的方式，来接受增减，确保数据一致 - 乔楚

21. 秒杀可以用缓存，每台前端机存储属于自己产品的数量，把100份产品分别分担到十台机器。前端也用缓存，把部分用户请求请求到失效的服务器（黑洞）或者在lvs时丢弃请求或返回正在抢购（未抢到）

小米的预约不就是这么干的么？我猜…预约完了就知道自己能不能抢到??如果来抢

还能光明正大的过滤掉未预约用户

最后秒杀变成取奖步骤，光读redis就能抗住

??不这么做，怎么抗住请求，谁让中国人那么多，何况还有机器刷 - Moses