在双 11 活动中天猫、淘宝网的超卖问题是如何产生的，可以认为是系统bug吗？

这会导致淘宝的双11活动卖出的金额191亿元很水啊
情况是这样的吗？而且大多发生在零点10分以内的？
当商家的存货趋近于0的时候，大量买家共同买入，当其中交易完成时，存货减1。如果这时存货数量到达0了，可还是有大量买家没有完成付款，从而生成超卖的订单了？

子柳，淘宝打杂的 码农

有一个CAP理论，扩展性、一致性、可用性和成本之间形成了相互制约的关系，可以理解成下图的三角形边长是收益、面积是成本，如果三个边都很长的话，成本是最大的。

在双十一这种最极端的场景下，要满足三个条件，成本更是高到无法承受。那我们缩小哪一条边长呢？可用性不能缺（不能宕机）、扩展性不能缺（要支持大规模的并发访问），只能牺牲一部分一致性了。这里采用异步通知、分布式事务等操作，来保证数据尽可能多的“最终一致”，但不可避免的会产生少量数据的不一致，这是在计划中可以容忍的。

另外还有一个业务方面的逻辑问题，这可能比技术方面出现超卖的概率更加大一些。
需要解释一下交易减库存的两种方式：
一，拍下减库存
描述：下单之后，商品的库存就减一，减库存失败 下单就失败，然后再去付款
问题：恶拍，恶人会把卖家的商品都拍光，商品下架了，然后不付款
二，付款减库存
描述：下单之后不立即减库存，跳转到支付宝付款，淘宝接收到付款成功消息后，才去减商品库存
问题：超卖，热销商品尤其是秒杀商品，同时会有n多人同时付款成功，然后去减库存时，发现库存不够减了

最后，也不排除个别卖家借这个机会来推卸责任的可能性。

岳天，互联网从业者，挨踢农民工，半码农

技术方面上面@子柳已经说的很明确了，超卖再交易量很大的情况下，出于对可用性和扩展性的需要，严格控制一致性成本无法满足，所以超卖还是有小部分。
下面从影响方面说说，首先，无论国内国外的网站都有超卖的情况发生，像现在正在进行的 黑色星期五，很多商品都有超卖，而国内外网站处理超卖大部分采取 “砍单”（砍单不一定全部是因为超卖），作为海淘一族，大部分已经形成概念“低价商品砍单时正常，不砍单是走运。”，亚马逊比较少砍单，也是因为其系统支持强大，较少发生超卖，京东等B2C也有超卖砍单情况。

此次天猫居然没有像 “团购宝事件”那样 全部进行退款砍单，而是进行了 30%的补偿，也是非常不错的。
应该可以预见造成的影响 是正面大于负面。

然后说一说一致性的问题，所有网站里，一致性要求最高的当属金融类网站，再具体点就是银行的交易系统。
有知道关于银行系统的知友可以讲一讲。
刚研究了下 银行业的一些资料，发现 实时的转账汇款有个20秒的概念，分2部分，一是发起交易确认付款，而是返回交易回执，交易才算完成。没有返回交易回执，则认为汇款失败，钱退回来。
淘宝的交易系统应该借鉴这样的操作，订单下后确认付款，同时确认库存，一旦发现超卖，即刻显示付款失败。
不要等到过了好几天才告诉别人，超卖了，货发不了，很伤人的。

张磊，学生浅薄，望诸师雅正。。。

可以从产品和运营两个角度，同步操作改善这个问题。
但是在产品角度上，需要评估投入产出比，如果投入产出比较低、那么不一定会得到执行。

一、产品角度：混合减库存方案
1.设立一个库存数阙值，比如50件。
--达到阙值之前，采用付款减库存的方案。
--达到阙值之后，自动转为拍下减库存的方案。
2.当然这个阙值需要根据并发订单数、“下单未付款”状态单数、总库存数等参数（也许还有其他参数）进行配置。
--在平时，并发订单数可能只是2件，平均会有最多10单左右处于“已下单但未付款”的状态。那么，这个阙值设为10件（或者12件？还没深入思考）。
--在促销时，并发订单数可能达到50，同时处于“下单未付款”状态的可能达到500单，那么这个阙值就可以考虑设为500件。
3.考虑到商品数量、高并发下系统的响应速度等因素，这个阙值可能还要再上调一部分比例，比如10%。
4.如果这个阙值可以自动调整，那就更完善了。但是在大数据量面前，这有点科幻了。
5.如果自动切换出现异常，则系统自动弹窗提示管理员手动切换。如果弹窗也崩了，那就放弃执行，允许按付款减库存的方案销售商品直到库存为零商品下架。

二、运营角度：缩短付款等待期的时间窗长度 +超量备货或减量上架。
0.缩短时间窗长度很好理解，在系统里调整一个时间参数就可以了。
1.超量备货：如果，库存系统的数据可以与实际库存量不一致。那么在促销时，比如系统库存数是1W件，那么实际备货数量就按阙值的两倍，进行超量备货。
2.减量上架：如果，库存系统的数据与实际库存数量必须一致。那么在设置参加活动商品的数量时，比如库存是1W件，那么活动商品就设成9000件。

三、但是这两种方案并行之后，作用只能是减少超卖的规模而非杜绝。
由于网购的特点，非常受制于商品、时间、用户结构等因素，而这些因素很难在一个大型活动前进行全部的、完全精准的预估，所以很难完全杜绝超卖。

四、将开发成本、系统成本，与产品效果对比，判断投入产出比。如果投入产出比不高，就只在运营方面进行调整吧。。。

乐游，总是很想吐槽

超卖一般是秒杀系统设计得不完美。具体来说就是因为短时间内对数据库的操作过于频繁，并发的操作太多，可能有两个或以上的操作同时处理同一件库存，这样就会卖超。

因为秒杀活动的环境跟一般出售商品不同，减库存这种方法是不能依赖的，所以现在设计的秒杀系统基本都不会像上边两位说的靠减库存（这样的话几乎全部会卖超）。一些B2C的秒杀架构是给每个库存一条单独的数据库记录，用一个字段表示“是否售出”。这样很多操作同时进来数据库，只要遍历所有库存，找一个未售出的库存上锁，然后慢慢处理即可。可以大大减少超卖的情况。

淘宝的超卖。。。估计是就算设计成这样还是扛不住巨大的流量吧。。。

任何算法和架构都顶不住巨量的数据这是真理。。。