生产环境全链路压测建设历程之七： 淘宝网 2012 年双十一库存超卖问题的本质

上一篇的内容是 生产环境全链路压测建设历程之六 淘宝网 2012 年双十一的痛

上一篇的内容情况总结一下

2012 年 6 月-10 月，为了迎战双十一，淘宝网投入了近 200 人奋战 5 个多月进行容量评估，系统优化等.从财务角度来核算，一个淘宝网的工程师月均待遇是 3 万/月，则付出了将近 3000 万的人力成本。

2012.11.11 零点，大量商品库存超卖

2012.11.14 陆续有消费者和商家投诉商品超卖问题，淘宝网的交易中心系统团队、商品中心系统团队、应用运维、DBA、支付宝团队，将近 100 人陆续开始投入问题排查，但很难查到根本原因。事后总结，其中一个原因归结系统流量评估太大，超过评估标准，引发数据库网卡满，最终导致应用各种异常。

2012.11.20 过多消费者投诉，上了央视新闻。

2012.11.23 天猫 CEO 逍遥子承诺，对超卖造成的损失进行赔偿。

由于 2012 年的双十一当日成交量确实大大超出了期望，但库存超卖的问题，仍然是一个让大家耿耿于怀的事情。

在 2013 年初，为了确保后续的双十一系统稳定，天猫的架构团队开始推动把库存的信息，从淘宝网的商品中心里面剥离出来。

但对于 2013 年的双十一的巨大流量，系统能否不挂这样一个问题，其实没人能够回答。

大流量下库存超卖问题的本质原因

本质这个词的反义词是表面。

本质是指引发问题或现象发生的、隐藏于背后的真正原因。

上面有提到，在 2012 年做故障复盘的时候，把系统故障归结系统流量评估太大，超过评估标准，引发数据库网卡满，最终导致应用各种异常。

站在今天的角度来看，其实数据库网卡满，也仅仅是造成库存超卖问题的表面原因。

大流量下，库存超卖问题本质的原因，有如下两个

1.2012 年的淘宝网的系统，已经是一个超级复杂的大型系统.

2.各个子系统的容量，是靠在测试环境压测，再加上人工推断的方式来评估。这种方式存在几个问题。

一是测试集群规模相比生产集群较小，生产集群的性能是通过测试集群的压测数据简单乘以系数推算得到的，无法准确评估生产集群性能及不同模块间的资源配比。

二是测试环境的基础设施与真实的生产环境存在差异，如各种网络安全设备、带宽、系统拓扑、数据容量等。

三是测试环境进行压测的系统相互之间是独立的，即使各系统单独的性能测试已达标，但在生产环境多系统串联后往往存在“1+1<2”的情况。