双11天猫、淘宝网的超卖问题是如何产生
这会导致淘宝的双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的架构是给每个库存一条单独的数据库记录，用一个字段表示“是否售出”。这样很多操作同时进来数据库，只要遍历所有库存，找一个未售出的库存上锁，然后慢慢处理即可。可以大大减少超卖的情况。
淘宝的超卖。。。估计是算设计成这样还是扛不住巨大的流量吧。。。
任何算法和架构都顶不住巨量的数据这是真理。。。
