您当前的位置:
电商系统订单问题请教
各位大拿好，我们目前在做库存相关的系统，主要就是对接订单系统的库存锁定。有个问题想跟大家探讨一下：就是对同一个商品，怎么保证不能被超卖了。举个极端的例子，一款手机，库存只剩一个了，在高并发的场景下订单系统过来调用的时候，怎么保证不超卖？如果web服务又是集群的呢？希望有经验的多讨论讨论，谢谢啦！
------解决思路----------------------
可以考虑库存管理这块用专门的服务器处理。
另外可以看看这个对你有没有点帮助：http://blog.csdn.net/ldh911/article/details/43196859
------解决思路----------------------
你可以把商品根据单品编号（每一个商品给一个编号，例如原来的商品编号是 349722，单品管理之后就是 349722AA0001、349722AA0002、.......，然后把单品放到内存中的数组中，只有一个“原子”的操作可以“获取并删除”一个编号。其中AA表示是第几次促销，后边的是流水号。
这样做，把这个操作跟你的库存系统分开了，你的库存系统就不需要跟这个业务发生直接关联。当此业务有极高的并发时，可以保证先异步地给每一个前端用户反馈——他抢到了一件商品，而后你的系统再把这个编号放到用户的购物车里，慢慢去做结算。抢购活动不需要写库存，进行了最简单的读写分离。
------解决思路----------------------
一般来说，传统的零售业，并不纠结“不超买”的问题。
传统的商品本来就有单品管理的功能。例如卖汽车、卖珠宝、卖精品服装等等，从入库环节起就应该是单品管理的，每一件商品都可以追踪整个生命期，顾客拿来一件衣服就能查出来是哪一个专卖店的哪一个营业员卖出去的。
如果你需要极端地管理商品，就应该单品管理。并且为抢购单独建库（表），让抢购库跟普通的店内仓库分离开。防止与其它业务发生事务冲突。
如果要求非常高的性能，那么这个表应该在内存中操作，而不“落地”。
大致就是这个逻辑。过多纠结技术术语没用，还是要找到业务原型你才能把流程设计清楚。
------解决思路----------------------
其实如果真的是高并发的话，那么服务器上大量时间消耗在一些和比较低级的事情上了，比如说根据一大堆介绍文字和图片而动态生成网页，这时你的CPU就是瓶颈了，你可以把负载分配到不同的服务器上去，这些服务器各自有自己的缓存。
对于流程中靠前的关键操作，其实应该跟后台数据库想分离，独立成尽量傻瓜化（但是海量数据）的SOA服务。把前一两个业务操作撑住，后边的异步处理即使慢一些，只要不丢数据，用户也能接受、也不会流失，特别是可以通过前端网页的一些ajax之类的异步处理流程来提高用户体验、给用造成系统“不快但是很流程”的错觉。
如果你满脑子就是那么一个后台数据库，什么操作都从它出发去拼凑业务流程，那么缺乏业务设计的想象力（而仅仅靠与业务无关的技术手段去解决），系统也容易遇到一个个瓶颈。
------解决思路----------------------
传统的零售业一般是针对“品项”进行管理的。从入库、销售、服务等环节都是。比如说某个型号的手机，可能管理到型号就行了。只有个别要求服务精细化（以产生特殊价值）的商品才做到单品管理。
单品管理有好处，就是容易跟踪整个业务链条。每一个业务都以这个单品的编号为key，这样就比较细致。反之如果要从品项、采购批次记录、下订单、付款、提货等等环节去“猜测”单品是不是在某一个销售工作流中，就显得非常不靠谱了，稍有不慎似乎就查不清楚来龙去脉了，于是产生了许多过分考虑数据安全性的事务系统
单品管理使得计算机成本增加了，但是其实在大数据处理能力支持下业务系统变得更简单、更少的事务锁、更离散化了，
------解决思路----------------------
资源上锁就好了
------解决思路----------------------
这个用乐观锁就可以解决
------解决思路----------------------
你可以参考一下 使用redis或者zookeeper实现的分布式锁（网络锁）,如果合适的话可以细聊
------解决思路----------------------
用memcached等内存数据库来控制并发，搭配必要的写入数据库
------解决思路----------------------
ＢＢ 专家 balabala说了一大堆废话
我就一句话，乐观锁
update table set stock = newStock where stock = oldStock and pid = 100
更新失败就返回失败，是不是有点像java的CAS？