这会导致淘宝的双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的架构是给每个库存一条单独的数据库记录,用一个字段表示“是否售出”。这样很多操作同时进来数据库,只要遍历所有库存,找一个未售出的库存上锁,然后慢慢处理即可。可以大大减少超卖的情况。

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

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