一个阿里技术男经历的六年“双11”：技术改变阿里

虎嗅注：首先，这不是一个软文，强调这一点对我们来说很重要，尽管写作者是阿里内部人士。

恰因为他内部人士的身份给了我们完全不一样的视角和内幕。这正是媒体所无法真正触及的地方。想了解他们是怎么应对“双11”突然涌入的海量访问量、订单量、支付笔数等等问题，这篇文章或能解惑。每一个技术背后都经历了什么，本文提供了一手的资料。

本文作者张瑞，系阿里集团数据库技术团队负责人，双十一数据库技术总负责人，曾两次担任双十一技术保障总负责人。

我们即将迎来第十个“双11”。

过去十年，阿里巴巴技术体系的角色发生了转变，从“双11”推动技术的发展，变成了技术创造新商业。很多技术通过云计算开始对外输出，变成了普惠的技术，服务于各个行业，真正做到了推动社会生产力的发展。

这十年，阿里巴巴数据库团队一直有一个使命：推动中国数据库技术变革。从商业数据库到开源数据库再到自研数据库，我们一直在为这个使命而努力奋斗。

如果将阿里数据库发展历史分为三个阶段的话，分别是：第一阶段（2005~2009）商业数据库时代、第二阶段（2010~2015）开源数据库时代、第三阶段（2016年至今）自研数据库时代。

商业数据库时代就是大家所熟知的IOE时代，后来发生了一件大事就是“去IOE”：通过分布式数据库中间件TDDL、开源数据库AliSQL（阿里巴巴的MySQL分支）、高性能X86服务器和SSD，并通过DBA和业务开发同学的共同努力，成功地替换了商业数据库Oracle、IBM小型机和EMC高端存储，从此进入了开源数据库时代。

去IOE带来了三个重大的意义：

第一是解决了扩展性的问题，让数据库具备了横向扩展（弹性）的能力，为未来很多年双11零点交易峰值打下了很好的基础；

第二是自主可控，我们在AliSQL中加入了大量的特性，比如：库存热点补丁，SQL限流保护，线程池等等，很多特性都是来源于双11对于数据库的技术要求，这在商业数据库时代是完全不可能的；

第三是稳定性，原来在商业数据库时代，就如同把所有的鸡蛋放在一个篮子里（小型机），去IOE之后不仅仅解决了单机故障，更是通过异地多活的架构升级让数据库跨出了城市的限制，可以实现数据库城市间的多活和容灾，大大提升了系统的可用性。

进入2016年，我们开始自研数据库，代号X-DB。大家一定会问：为什么要自研数据库？有以下几个原因：

第一，我们需要一个能够全球部署的原生分布式数据库，类似于Google Spanner；

第二是双11的场景对数据库提出了极高的要求，第一是性能，在双11零点需要数据库提供非常高的读写能力；第二是存储成本，数据库使用SSD来存储数据，而数据存在明显的冷热特性，大量冷的历史数据和热的在线数据存放在一起，日积月累，占用了大量宝贵的存储空间，存储成本的压力越来越大。我们经过认真评估后发现，如果继续在开源数据库基础上进行改进已经无法满足业务需求；

第三是新的硬件技术的出现，如果说SSD的大规模使用和X86服务器性能的极大提升推动了去IOE的进程，那么NVM非易失内存，FPGA异构计算，RDMA高速网络等技术将第二次推动数据库技术的变革。

伴随着每一年的双11备战工作，机器资源的准备都是非常重要的一个环节。如何降低双11的机器资源成本一直是阿里技术人不断挑战自我的一个难题。第一个解决方案就是使用云资源，数据库从2016年初开始就尝试使用高性能ECS来解决双11的机器资源问题。通过这几年的双11的不断磨练，2018年双11，我们可以直接使用了公有云ECS，并通过VPC网络与阿里巴巴集团内部环境组成混合云，实现了双11的弹性大促。

第二个方案就是在线离线混部，日常让离线任务跑在在线（应用和数据库）的服务器上，双11大促在线应用使用离线的计算资源，要实现这种弹性能力，数据库最核心要解决一个技术问题就是：存储计算分离。存储计算分离后，数据库可以在双11使用离线的计算资源，从而实现极致的弹性能力。通过使用云资源和混部技术，可以最大程度降低双11交易峰值带来的成本。

双11备战中另外一个重要的技术趋势就是：智能化。数据库和智能化相结合也是我们一直在探索的一个方向，比如Self-driving Database等。2017年，我们第一次使用智能化的技术对SQL进行自动优化，2018年，我们计划全网推广SQL自动优化和空间自动优化，希望可以使用这些技术降低DBA的工作负担，提升开发人员效率，并有效提升稳定性。相信未来，在双11的备战工作中，会有越来越多的工作可以交给机器来完成。

我从2012年开始参加双11的备战工作，多次作为数据库的队长和技术保障部总队长，在这么多年的备战工作中，我也经历了很多有意思的故事，在这里分享一些给大家。

2012年：我的第一次双11

2012年是我的第一次双11，在此之前，我在B2B的数据库团队。2012年初，整个集团的基础设施团队都合并到了技术保障部，由振飞带领。

我之前从来没有参加过双11，第一年参加双11后羿（数据库团队的负责人）就把队长的职责给了我，压力可想而知。那时候备战双11的工作非常长，大概从五六月份就开始准备了，最重要的工作就是识别风险，并准确评估出每个数据库的压力。

我们需要把入口的流量转换为每个业务系统的压力QPS，然后我们根据业务系统的QPS转换为数据库的QPS，2012年还没有全链路压测的技术，只能靠每个业务系统的线下测试，以及每个专业线队长一次又一次的开会review来发现潜在的风险。

可想而知，这里面存在巨大的不确定性，每个人都不想自己负责的业务成为短板，而机器资源往往是有限的。这时，就完全靠队长的经验了，所以，每个队长所承担的压力都非常巨大。我记得当年双11的大队长是李津，据说他当时的压力大到无法入睡，只能在晚上开车去龙井山顶，打开车窗才能小憩一会。

而我，由于是第一年参加双11，经验为零，完全处于焦虑到死的状态，幸好当年有一群很靠谱的兄弟和我在一起，他们刚刚经历了去IOE的洗礼，并且长期与业务开发浸淫在一起，对业务架构和数据库性能如数家珍，了如指掌。通过他们的帮助，我基本摸清了交易整套系统的架构，这对我未来的工作帮助非常大。

经过几个月紧张的准备，双11那天终于到来了，我们做好了最充分的准备，但是一切都是那么地不确定，我们怀着忐忑不安的心情，当零点到来的时候，最坏的情况还是发生了：库存数据库的压力完全超过了容量，同时IC（商品）数据库的网卡也被打满了。我记得很清楚，当时我们看着数据库的上的监控指标，束手无策。这里有一个小细节：由于我们根本没有估算到这么大的压力，当时监控屏幕上数据库的压力指标显示超过了100%。

正在这时，技术总指挥李津大喊一声：“大家都别慌！”

这时我们才抬头看到交易的数字不断冲上新高，心里才稍微平静下来。事实上，对于IC数据库网卡被打满，库存数据库超过容量，都超出了我们的预期，所以最终我们什么预案也没做，就这样度过了零点的高峰。

因为这些原因，2012年的的双11产生了大量的超卖，给公司带来了很大的损失。那一年的双11后，库存、商品、退款和相应数据库的同学，为了处理超卖导致的问题，没日没夜加了两周的班。而且，我周围很多朋友，都在抱怨高峰时的用户体验实在太糟糕了。我们下决心要在第二年的双11解决这些问题。

2013年：库存热点优化和不起眼的影子表

2012年的双11结束后，我们就开始着手解决库存数据库的性能提升。库存扣减场景是一个典型的热点问题，即多个用户去争抢扣减同一个商品的库存（对数据库来说，一个商品的库存就是数据库内的一行记录），数据库内对同一行的更新由行锁来控制并发。我们发现当单线程（排队）去更新一行记录时，性能非常高，但是当非常多的线程去并发更新一行记录时，整个数据库的性能会跌到惨不忍睹，趋近于零。

当时数据库内核团队做了两个不同的技术实现：一个是排队方案，另一个并发控制方案。两者各有优劣，解决的思路都是要把无序的争抢变为有序的排队，从而提升热点库存扣减的性能问题。两个技术方案通过不断的完善和PK，最终都做到了成熟稳定，满足业务的性能要求，最终为了万无一失，我们把两个方案都集成到了AliSQL（阿里巴巴的MySQL分支）中，并且可以通过开关控制。最终，我们通过一整年的努力，在2013年的双11解决了库存热点的问题，这是第一次库存的性能提升。在这之后的2016年双11，我们又做了一次重大的优化，把库存扣减性能在2013年的基础上又提升了十倍，称为第二次库存性能优化。

2013年堪称双11历史上里程碑式的一年，因为这一年出现了一个突破性的技术：全链路压测。我非常佩服第一次提出全链路压测理念的人：李津，他当时问我们：有没有可能在线上环境进行全仿真的测试？所有人的回答都是：不可能！当然，我认为这对于数据库是更加不可能的，最大的担心是压测流量产生的数据该如何处理，从来没听说过哪家公司敢在线上系统做压测，万一数据出现问题，这个后果将会非常严重。

我记得在2013年某天一个炎热的下午，我正在库存数据库的问题中焦头烂额的时候，叔同（全链路压测技术负责人）来找我商量全链路压测数据库的技术方案。就在那个下午，我们两个人讨论出了一个“影子表”的方案，即在线上系统中建立一套“影子表”来存储和处理所有的压测数据，并且由系统保证两套表结构的同步。

我们对这件事心里都没底，我相信在双11的前几周，没有几个人相信全链路压测能够落地，我们大部分的准备工作还是按照人工review+线下压测的方式进行。但是，经过所有人的努力，这件事竟然在双11前两周取得了突破性进展，当第一次全链路压测成功的时候，所有人都觉得不敢相信。

最后，双11的前几个晚上，几乎每天晚上都会做一轮全链路压测，每个人都乐此不疲，给我留下的印象实在太深刻了。但这个过程，也并不是一帆风顺，我们压出了很多次故障，多次写错了数据，甚至影响了第二天的报表，长时间高压力的压测甚至影响了机器和SSD的寿命。即便出现了如此多的问题，大家依然坚定地往前走，我觉得这就是阿里巴巴与众不同的地方，因为我们相信所以看见。事实也证明，全链路压测变成了双11备战中最有效的大杀器。

现在全链路压测技术已经不是秘密，它已经成为阿里云上的一个产品，变成了更加普惠的技术服务更多企业。

2015年：大屏背后的故事

2015年，我从数据库的队长成为整个技术保障部的总队长，负责整个技术设施领域的双11备战工作，包括IDC、网络、硬件、数据库、CDN应用等所有技术领域，我第一次面对如此多的专业技术领域，对我又是一次全新的挑战。

但是，这一次我却被一个新问题难倒了：大屏。

2015年，我们第一次举办天猫双11晚会，这一年晚会和媒体中心第一次不在杭州园区，而是选择在北京水立方，媒体中心全球26小时直播，全球都在关注我们双11当天的盛况，需要北京杭州两地协同作战，困难和挑战可想而知。

大家都知道对媒体直播大屏来说最最重要的两个时刻，一个是双11零点开始的时刻，一个是双11二十四点结束的时刻，全程要求媒体直播大屏上跳动的GMV数字尽可能的不延迟，那一年我们为了提升北京水立方现场的体验及和杭州总指挥中心的互动，在零点前有一个倒计时环节，连线杭州光明顶作战指挥室，逍遥子会为大家揭幕2015双11启动，然后直接切换到我们的媒体大屏，所以对GMV数字的要求基本上是零延迟，这个挑战有多大不言而喻。

然而，第一次全链路压测时却非常不尽人意，延时在几十秒以上，当时的总指挥振飞坚决地说：GMV第一个数字跳动必须要在5秒内，既要求5秒内就拿到实时的交易数字，又要求这个数字必须是准确的，所有人都觉得这是不可能完成的任务。当时，导演组也提了另外一个预案，可以在双11零点后，先显示一个数字跳动的特效（不是真实的数字），等我们准备好之后，再切换到真实的交易数字，但对媒体大屏来说所有屏上的数据都必须是真实且正确的（这是阿里人的价值观），所以我们不可能用这个兜底的方案，所有人想得都是如何把延迟做到5秒内。

当天晚上，所有相关的团队就成立一个大屏技术攻关组，开始封闭技术攻关，别看一个小小的数字，背后涉及应用和数据库日志的实时计算、存储和展示等全链路所有环节，是真正的跨团队技术攻关，最终不负众望，我们双11零点GMV第一个数字跳动是在3秒，严格控制在5秒内，是非常非常不容易的！不仅如此，为了保证整个大屏展示万无一失，我们做了双链路冗余，类似于飞机双发动机，两条链路同时计算，并可实时切换。

我想大家一定不了解大屏上一个小小的数字，背后还有如此多的故事和技术挑战吧。双11就是如此，由无数小的环节组成，背后凝聚了每个阿里人的付出。

2016年：吃自己的狗粮

做过大规模系统的人都知道，监控系统就如同我们的眼睛一样，如果没有它，系统发生什么状况我们都不知道。我们数据库也有一套监控系统，通过部署在主机上的agent，定期采集主机和数据库的关键指标，包括：CPU和IO利用率，数据库QPS、TPS和响应时间，慢SQL日志等等，并把这些指标存储在数据库中，进行分析和展示，最初这个数据库也是MySQL。

随着阿里巴巴数据库规模越来越大，整个监控系统就成为了瓶颈，比如：采集精度，受限于系统能力，最初我们只能做到1分钟，后来经过历年的优化，我们把采集精度提升到10秒。但是，最让人感到尴尬的是：每一年双11零点前，我们通常都有一个预案：对监控系统进行降级操作，比如降低采集精度，关闭某些监控项等等。这是因为高峰期的压力太大，不得已而为之。

另外一个业务挑战来自安全部，他们对我们提出一个要求，希望能够采集到每一条在数据库上运行的SQL，并能实时送到大数据计算平台进行分析。这个要求对我们更是不可能完成的任务，因为每一个时刻运行的SQL是非常巨大的，通常的做法只能做到采样，现在要求是一条不漏的记录下来，并且能够进行分析，挑战非常大。

2016年双11，我们启动了一个项目：对我们整个监控系统进行了重新设计。目标：具备秒级监控能力和全量SQL的采集计算能力，且双11峰值不降级。

第一是要解决海量监控数据的存储和计算问题，我们选择了阿里巴巴自研的时序数据库TSDB，它是专门针对IOT和APM等场景下的海量时序数据而设计的数据库。第二是要解决全量SQL的采集和计算的问题，我们在AliSQL内置了一个实时SQL采集接口，SQL执行后不需要写日志就直接通过消息队列传输到流计算平台上进行实时处理，实现了全量SQL的分析与处理。解决了这两个技术难题后，2016年双11，我们达到了秒级监控和全量SQL采集的业务目标。

后来，这些监控数据和全量SQL成为了一个巨大的待挖掘的宝库，通过对这些数据的分析，并与AI技术相结合，我们推出了CloudDBA数据库智能化诊断引擎。我们相信数据库的未来是Self-drving database，它有四个特性：自诊断、自优化、自决策和自恢复。如前文所述，目前我们在智能化方向上已经取得了一些进展。

现在，TSDB已经是阿里云上的一个产品，而CloudDBA除了服务阿里巴巴内部数万工程师，也已经在云上为用户提供数据库优化服务。我们不仅吃自己的狗粮，解决自己的问题，同时也用阿里巴巴的场景不断磨练技术，服务更多的云上用户。这就是双11对技术的推动作用。

2016~2017年：数据库和缓存那点儿事

在双11的历史上，阿里巴巴自研缓存-Tair是非常重要的技术产品，数据库正是因为有了Tair的帮助，才扛起了双11如此巨大的数据访问量。在大规模使用Tair的同时，开发同学也希望数据库可以提供高性能的KV接口，并且通过KV和SQL两个接口查询的数据是一致的，这样可以大大简化业务开发的工作量， X-KV因此因用而生，它是X-DB的KV组件，通过绕过SQL解析的过程，直接访问内存中的数据，可以实现非常高的性能以及比SQL接口低数倍的响应时间。X-KV技术在2016年双11第一次得到了应用，用户反馈非常好，QPS可以做到数十万级别。

在2017年双11，我们又做了一个技术，通过中间件TDDL自动来实现SQL和KV的转换，开发不再需要同时开发两套接口，只需要用SQL访问数据库，TDDL会自动在后台把SQL自动转换为KV接口，进一步提升了开发的效率，降低了数据库的负载。

2016年双11，Tair碰到了一个业界技术难题：热点。大家都知道缓存系统中一个key永远只能分布在一台机器上，但是双11时，热点非常集中，加上访问量非常大，很容易就超出了单机的容量限制，CPU和网卡都会成为瓶颈。由于热点无法预测，可能是流量热点，也可能是频率热点，造成2016年双11我们就像消防队员一样四处灭火，疲于奔命。2017年，Tair团队的同学就在思考如何解决这个业界的技术难题，并且创新性地提出了一种自适应热点的技术方案：第一是智能识别技术， Tair内部采用多级LRU的数据结构，通过将访问数据Key的频率和大小设定不同权值，从而放到不同层级的LRU上，这样淘汰时可以确保权值高的那批Key得到保留。最终保留下来且超过阈值设定的就会判断为热点Key。第二是动态散列技术，当发现热点后，应用服务器和Tair服务端就会联动起来，根据预先设定好的访问模型，将热点数据动态散列到Tair服务端其它数据节点的HotZone存储区域去访问。

热点散列技术在2017年双11中取得了非常显著的效果，通过将热点散列到整个集群，所有集群的水位均降低到了安全线下。如果没有这个能力，那么2017年双11很多Tair集群都可能出现问题。

可以看出，数据库和缓存是一对互相依赖的好伙伴，他们互相借鉴，取长补短，共同撑起了双11海量数据存储和访问的一片天。

2016~2017年：如丝般顺滑的交易曲线是如何做到的

自从有了全链路压测这项技术后，阿里巴巴技术保障部负责人周明就提出了一个新的目标：希望每一年双11零点的交易曲线都能“如丝般顺滑”。这个目标对技术提出了非常高的要求。2016年双11零点后，交易曲线出现了一些波动，才攀逐步升到最高点。事后复盘时，我们发现主要的问题是购物车等数据库在零点的一刹那，由于Buffer pool中的数据是“冷”的，当大量请求在零点一瞬间到来时，数据库需要先“热”起来，需要把数据从SSD读取到Buffer pool中，这就导致瞬间大量请求的响应时间变长，影响了用户的体验。

知道了问题原因后，2017年我们提出了“预热””技术，即在双11前，让各个系统充分“热”起来，包括Tair，数据库，应用等等。为此专门研发了一套预热系统，预热分为数据预热和应用预热两大部分，数据预热包括：数据库和缓存预热，预热系统会模拟应用的访问，通过这种访问将数据加载到缓存和数据库中，保证缓存和数据库BP的命中率。应用预热包括：预建连接和JIT预热，我们会在双11零点前预先建立好数据库连接，防止在高峰时建立连接的开销。同时，因为业务非常复杂，而JAVA代码是解释执行的，如果在高峰时同时做JIT编译，会消耗了大量的CPU，系统响应时间会拉长，通过JIT预热，保证代码可以提前充分编译。

2017年双11，因为系统有了充分的预热，交易曲线在零点时划出了一道完美的曲线。

2017～2018年：存储计算分离的技术突破

2017年初，集团高年级技术同学们发起了一个技术讨论：到底要不要做存储计算分离？由此引发了一场扩日持久的大讨论。包括我在王坚博士的班上课时，针对这个问题也进行了一次技术辩论，由于两方观点势均力敌，最终谁也没有说服谁。

对于数据库来说，存储计算分离更加是一个非常敏感的技术话题，大家都知道在IOE时代，小型机和存储之间通过SAN网络连接，本质上就是属于存储计算分离架构。现在我们又要回到这个架构上，是不是技术的倒退？另外，对于数据库来说，IO的响应延时直接影响了数据库的性能，如何解决网络延时的问题？各种各样的问题一直困扰着我们，没有任何结论。

当时，数据库已经可以使用云ECS资源来进行大促弹性扩容，并且已经实现了容器化部署。但是，我们无论如何也无法回避的一个问题就是：如果计算和存储绑定在一起，就无法实现极致的弹性，因为计算节点的迁移必须“搬迁”数据。而且，我们研究了计算和存储的能力的增长曲线，我们发现在双11高峰时，对于计算能力的要求陡增，但是对于存储能力的要求并没有发生显著变化，如果可以实现存储计算分离，双11高峰我们只需要扩容计算节点就可以了。综上所述，存储计算分离是华山一条路，必须搞定。

2017年中，为了验证可行性，我们选择在开源分布式存储Ceph的基础上进行优化，与此同时，阿里巴巴自研高性能分布式存储盘古2.0也在紧锣密鼓的开发中。另外一方面，数据库内核团队也参与其中，通过数据库内核优化减少网络延迟对数据库性能的影响。经过大家的共同努力，最终基于盘古2.0的计算存储分离方案都在2017年双11落地，并且验证了使用离线机头挂载共享存储的弹性方案。经过这次双11，我们证明了数据库存储计算分离是完全可行的。

存储计算分离的成功离不开一位幕后英雄：高性能和低延迟网络，2017年双11我们使用了25G的TCP网络，为了进一步降低延迟，2018年双11我们大规模使用了RDMA技术，大幅度降低了网络延迟，这么大规模的RDMA应用在整个业界都是独一无二的。为了降低IO延迟，我们在文件系统这个环节也做了一个大杀器-DBFS，通过用户态技术，旁路kernel，实现I/O路径的Zero copy。通过这些技术的应用，达到了接近于本存储地的延时和吞吐。 

2018年双11，随着存储计算分离技术的大规模使用，标志着数据库进入了一个新的时代。

总结

在2012年到2018年的这六年，我见证了零点交易数字的一次次提升，见证了背后数据库技术的一次次突破，更见证了阿里人那种永不言败的精神，每一次化“不可能”为“可能”的过程都是阿里技术人对技术的不懈追求。