阿里数据库十年变迁，那些你不知道的二三事

摘要： 第十个双11即未来临之际，阿里技术推出《十年牧码记》系列，邀请参与历年双11备战的核心技术大牛，一块儿回顾阿里技术的变迁。 今天，阿里数据库事业部研究员张瑞，将为你讲述双11数据库技术鲜为人知的故事。在零点交易数字一次次提高的背后，既是数据库技术的一次次突破，也见证了阿里技术人永不言败的精神，每一次化“不可能”为“可能”的过程都是阿里技术人对技术的不懈追求。

第十个双11即未来临之际，阿里技术推出《十年牧码记》系列，邀请参与历年双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的工做很是长，大概从五、6月份就开始准备了，最重要的工做就是识别风险，并准确评估出每一个数据库的压力。

咱们须要把入口的流量转换为每一个业务系统的压力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-drvingdatabase，它有四个特性：自诊断、自优化、自决策和自恢复。如前文所述，目前咱们在智能化方向上已经取得了一些进展。

如今，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年的这六年，我见证了零点交易数字的一次次提高，见证了背后数据库技术的一次次突破，更见证了阿里人那种永不言败的精神，每一次化“不可能”为“可能”的过程都是阿里技术人对技术的不懈追求。

原文连接