【10-20】电商项目的库存设计，如何不卖超，取消订单把库存加回去，不能多加
【今日话题】
电商项目的库存设计，如何不卖超，取消订单把库存加回去，不能多加 - 沈括号
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
【分享链接】
1. 干货 | 亿级Web系统搭建：单机到分布式集群 http://mp.weixin.qq.com/s?__biz=MzA3NDM1NjUwMQ==&mid=400074334&idx=2&sn=3293e8377aa372bf44cfef23908b5f22 - 黑夜路人
2. MySQL 5.7 GA版本发布！！！ http://mp.weixin.qq.com/s?__biz=MjM5MjIxNDA4NA==&mid=400037986&idx=1&sn=17f46988da045c976b0d6f993456a9c8 - 黑夜路人
3. 当我们谈性能的时候，我们实际上在谈什么？ http://www.infoq.com/cn/news/2015/10/pragmatic-performance - smarteng
4. 创业泡沫的「军功章」，高薪低能的程序员要分走一半 http://mp.weixin.qq.com/s?__biz=MzA5NDYwOTk4Mg==&mid=400027180&idx=1&sn=f41080c48c7055e8ff73dd4813f738a7 - ning
5. 某邮箱过亿数据泄漏（涉及邮箱账号/密码/用户密保等） http://wooyun.org/bugs/wooyun-2015-0147763 - 雷澍
6. Uber 背后的架构揭秘 http://mp.weixin.qq.com/s?__biz=MjM5NTg2NTU0Ng==&mid=400055785&idx=3&sn=9c6411a2f51dcd1b6f876a46eb798d52 - 黑夜路人
7. 现在写 PHP，你应该知道这些 http://mp.weixin.qq.com/s?__biz=MjM5NTg2NTU0Ng==&mid=214930065&idx=2&sn=fbadb4369f85c7f4d1a9e850d2fbc491 - 黑夜路人
8. 淘宝内部分享：怎么跳出MySQL的10个大坑（上） http://mp.weixin.qq.com/s?__biz=MjM5NTg2NTU0Ng==&mid=214841768&idx=3&sn=37ff007d89c99bc16e019354a76b2e32 - 黑夜路人
9. 淘宝内部分享：怎么跳出MySQL的10个大坑（下） http://mp.weixin.qq.com/s?__biz=MjM5NTg2NTU0Ng==&mid=400268645&idx=4&sn=9921a5886c2f1f04cd02ac48100f6217 - 黑夜路人
10. 百度宣布即日起停止社招，想进去得李彦宏特批 http://m.huxiu.com/article/128728/1.html - carl