2018年，双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。你肯定会问：我们为什么要开发自己的数据库？有几个原因：我们需要一个可以全局部署的原生分布式数据库，类似于GoogleSpanner。双11场景对数据库提出了极高的要求：数据库需要在双11零点提供非常高的读写能力，数据库采用SSD存储数据，数据具有明显的冷热特性。大量的历史冷数据和线上热数据存储在一起，日积月累，占用了大量宝贵的存储空间，增加了存储成本的压力。经过仔细评估，我们发现如果在开源数据库的基础上继续改进，已经不能满足业务需求。新硬件技术的出现，如果说SSD的大规模使用和X86服务器性能的大幅提升推动了IOE的进程，那么NVM非易失性存储器、FPGA异构计算、RDMA高速网络等技术将会成为数据库技术的第二个驱动变革。伴随着每年双11的筹备，机器资源的准备是非常重要的一个环节。如何在双11期间降低机器资源成本，一直是阿里巴巴技术人员不断挑战自己的难题。第一个解决方案是使用云资源。数据库从2016年开始尝试使用高性能ECS来解决双11期间机器资源的问题，通过这几年双11的不断训练，2018年双11我们可以直接使用公有云ECS，通过VPC网络与阿里巴巴集团内部环境形成混合云，实现双11的灵活推广。第二种方案是线上和线下部门混合，让线下任务每天运行在线上（应用和数据库）的服务器上。双11提倡将线下计算资源用于线上应用。要实现这种灵活性，需要解决数据库的核心问题。一个技术问题是：存储和计算分离。存储计算分离后，数据库可以在双十一期间使用离线计算资源，从而实现极致的弹性。通过使用云资源和混合技术，可以将双十一交易高峰带来的成本降到最低。备战双十一的另一个重要技术趋势是：智能化。数据库和智能的结合也是我们一直在探索的一个方向，比如Self-drivingDatabase。2017年，我们首次使用智能技术自动优化SQL。2018年我们计划在全网推广SQL自动优化和空间自动优化，希望通过这些技术减少DBA的工作量，提高开发效率。并有效提高稳定性。相信未来会有越来越多的工作可以由机器来完成，为双11做准备。我从2012年开始参与双11的准备工作，担任过数据库的队长和技术支持的负责人部门多次。在这么多年的筹备过程中，我也经历了很多有趣的故事，在此与大家分享一些。2012年：第一次双11。2012年是我第一次双11，之前在B2B数据库组。2012年初，整个集团基建团队并入技术支持部，由振飞领衔。我之前没有参加过双11，但是第一年参加双11的时候，后羿（数据库组组长）就把队长的职责交给了我，压力可想而知。当时双11的准备工作很长，5、6月份就开始准备了。最重要的工作是识别风险并准确评估每个数据库的压力。我们需要将入口流量转化为各个业务系统的压力QPS，然后我们将业务系统的QPS转化为数据库的QPS。2012年还没有全链路压测技术，只能通过各业务系统的线下测试和各专业条线负责人的反复开会和审核来发现潜在风险。可想而知，这其中存在着巨大的不确定性。每个人都不希望自己负责的业务成为短板，机器资源往往是有限的。这个时候，就完全看船长的经验了。所以，每个队长的压力都是巨大的。记得李津是双11的队长，据说他压得睡不着觉。只能晚上开车到龙井山山顶，打开车窗小睡片刻。而我呢，因为是第一年参加双11，所以经验是零，完全处于焦急的状态。幸好当时身边有一群很靠谱的弟兄。他们刚刚经过去IOE的洗礼，长期沉浸在业务开发中，对业务架构和数据库性能非常熟悉。在他们的帮助下，我基本弄清楚了整个交易系统的结构，这对我以后的工作有很大的帮助。经过数月的紧张筹备，双11终于到来了。我们已经做了最好的准备，但一切都是那么的不确定。胆战心惊，零来的时候，最坏的情况发生了：库存数据库的压力完全超过了容量，IC（商品）数据库的网卡也被充满了。我记得很清楚，我们看数据库上的监控指标，很无奈。这里有一个小细节：由于我们根本没有预估这么大的压力，所以当时监控屏幕上数据库的压力指标显示超过100%。就在这时，总技术总监李进喊道：“大家不要慌张！”我们这才抬头一看，交易笔数不断创新高，心里才稍稍平静了下来。事实上，IC数据库网卡满载，库存数据库超出容量，都超出了我们的预期，所以最后我们也没有做任何计划，只是过了归零的高峰期。由于这些原因，2012年的双11产生了大量的超卖，给公司带来了很大的损失。那年双11后，库存、商品、退款及对应数据库的同学，为了处理超卖带来的问题，日以继夜加班两周。而且身边很多朋友都在抱怨高峰期的用户体验真的很差。我们决心在第二年的双十一期间解决这些问题。2013年：库存热点优化和不显眼的影子表2012年双十一之后，我们开始着手解决库存数据库的性能提升。库存扣减场景是一个典型的热点问题，即多个用户竞争扣减同一个商品的库存（对于数据库来说，一个商品的库存就是数据库中的一行记录），同一个商品的更新数据库中的行并发是由行锁控制的。我们发现当单线程（排队）更新一行记录时，性能非常高，但是当很多线程并发更新一行记录时，整个数据库的性能就会下降到惨不忍睹，接近于零。当时数据库内核团队做了两种不同的技术实现：一种是队列方案，一种是并发控制方案。两者各有优缺点，解决办法是把无序的打乱变成有序的排队，从而提高热点库存扣除的性能。通过不断的改进和PK，两种技术方案最终趋于成熟和稳定，满足了业务的性能需求。最终，我们将这两个方案集成到了AliSQL（阿里巴巴的MySQL分支）中，并且可以通过开关控制。终于，通过一整年的努力，我们在2013年双11解决了库存热点问题，这是库存业绩第一次出现好转。之后在2016年双11，我们又做了一次重大优化，去库存性能比2013年提升了十倍，称为第二次去库存性能优化。2013年可以说是双11历史上具有里程碑意义的一年，因为这一年出现了突破性的技术——全链路压测。真的很佩服李进，第一个提出全链路压测概念的人。他问我们：能不能在线上环境下进行全模拟测试？所有人的回答都是：不可能！当然，我认为这对于数据库来说就更不可能了。最大的烦恼是如何处理压测流量产生的数据。从来没听说过哪家公司敢对线上系统做压力测试。如果数据出现问题，后果将非常严重。严肃的。记得2013年一个炎热的下午，当我正在为存量数据库的问题苦恼时，舒彤（全链路压测技术负责人）来找我讨论全链路的技术解决方案压力测试数据库。当天下午，我们两人讨论了一个“影子表”的解决方案，即在线上系统中建立一套“影子表”来存储和处理所有的压测数据，系统保证两者的一致性表结构集。同步。但是，我们对此事一无所知。相信在双11的前几周，很少有人相信全链路压测能够落地。我们大部分的准备工作还是以人工审核+线下压测的方式进行。不过经过大家的努力，在双十一前两周有了突破，第一次全链路压测成功的时候，大家都不敢相信。最后，在双11的前几个晚上，几乎每晚都进行了一轮全链路压测，大家玩的很开心，给我留下了深刻的印象。但这个过程并非一帆风顺。我们经历过多次失败，多次写错数据，甚至影响了第二天的报告。长时间的高强度压力测试甚至影响了整机和SSD的寿命。尽管有这么多的问题，但大家还是坚定的往前走。我认为这就是阿里巴巴与众不同的地方。我们看到它是因为我们相信它。事实也证明，全链路压测已经成为备战双11最有效的利器。如今，全链路压测技术已经成为阿里云上的产品，成为服务更多企业的更具普惠性的技术。2015年：大屏幕背后的故事2015年，我从数据库的队长，成为了整个技术支持部的队长。我负责双11全领域技术设施的准备工作，包括IDC、网络、硬件、数据库、CDN、应用等技术领域。这么多的专业和技术领域对我来说还是第一次，对我来说是一个全新的挑战。然而，这一次我被一个新问题难住了：大屏幕。2015年，我们首次举办天猫双11盛典。今年首次晚会和媒体中心不设在杭州公园，而是选择在北京水立方，媒体中心26小时全球直播。全世界都在关注我们双十一的盛况，这需要北京和杭州的配合。其中的困难和挑战可想而知！媒体直播大屏最重要的两个时刻大家都知道，一个是双11零点开始，一个是24:00双11结束。整个过程中，要求媒体直播大屏上跳跃的GMV数字尽可能不延迟。当年，为了提升北京水立方的现场体验以及与杭州总指挥中心的互动，我们在午夜前进行了倒计时，连线杭州光明顶运营指挥室，逍遥子将揭开2015双十一给大家上线，然后直接切换到我们媒体大屏，所以对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。SQL的分析和处理。解决了这两个技术难题后，我们在2016年双11实现了秒级监控和SQL全量采集的业务目标。后来，这些监控数据和SQL全量成为了一个巨大的宝库，有待挖掘。通过对这些数据的分析，结合AI技术，我们推出了CloudDBA数据库智能诊断引擎。我们认为数据库的未来是Self-drivingDatabase，它具有四个特点：自诊断、自优化、自决策和自恢复。前面说了，我们在智能化的方向上取得了一些进展。现在，TSDB已经是阿里云上的产品，而CloudDBA不仅服务于阿里内部数以万计的工程师，还为用户提供云上的数据库优化服务。我们不仅吃自己的狗粮，解决自己的问题，还借助阿里巴巴的场景，不断磨练自己的技术，服务更多的云用户。这就是双11对技术的推动力。2016-2017：数据库和缓存。在双11的历史上，阿里巴巴自研缓存-Tair是一个非常重要的技术产品。正是有了Tair的帮助，数据库才能承载如此庞大的双十一数据访问量。开发者在大规模使用Tair的同时，也希望数据库能够提供高性能的KV接口，通过KV和SQL这两个接口查询到的数据是一致的，这样可以大大简化业务开发的工作量。因此，X-KV诞生了。它是X-DB的KV组件。通过绕过SQL解析过程，直接访问内存中的数据，可以获得非常高的性能和比SQL接口低数倍的响应时间。X-KV技术在2016年双十一首次应用，用户反馈非常好，QPS可达几十万级。2017年双十一，我们又搞了一个黑科技，通过中间件TDDL自动实现SQL和KV的转换。开发不再需要同时开发两套接口，只需要使用SQL访问数据库，TDDL会在后台自动将SQL转换为KV接口，进一步提高开发效率，降低数据库负载.2016年双11，Tair遇到了行业的一个技术难题：热点。大家都知道缓存系统中的一个Key永远只能分布在一台机器上。但是双11期间，热点非常集中，流量非常大，很容易超过单机的容量限制，CPU和网卡都会成为瓶颈。由于热点是不可预测的，它们可能是流量热点或频率热点。于是，2016年双11，我们就像消防员一样到处灭火。2017年，Tair团队的同学们在思考如何解决这个行业的技术难题，创新性地提出了自适应热点技术方案：智能识别技术，Tair内部采用多级LRU数据结构，通过访问不同的为数据键的频率和大小设置权重，以便将它们放在不同级别的LRU上。这样可以保证淘汰时保留权重高的那批key，最后保留的超过阈值设置的key判断为hotkey。动态哈希技术，当发现热点时，会将应用服务器和Tair服务器链接在一起，根据预设的访问模型，将热点数据动态哈希到同一节点上其他数据节点的HotZone存储区用于访问的Tair服务器。热点哈希技术在2017年双11取得了非常显着的效果，通过将热点哈希到整个集群，将所有集群的水位降低到安全线以下。如果没有这个能力，2017年双11期间很多Tair集群可能会出问题，可见数据库和缓存是一对相依为命的好伙伴。他们取长补短，取长补短，共同支撑双11海量数据的存储和访问。2016-2017：如何实现丝般顺滑的交易曲线自从有了全链路压测技术，我们希望每年双11零点的交易曲线能够顺滑如丝，但事情往往没有想象中那么顺利。2016年双11午夜后，交易曲线经历了一些波动后逐渐攀升至最高点。经过审核，我们发现主要问题是购物车等数据库归零，因为缓冲池中的数据是“冷”的。当0点10分有大量请求到达时，首先需要对数据库进行“预热”，将数据从SSD中读取到Bufferpool中。导致大量瞬时请求的响应时间变长，影响用户体验。知道问题原因后，我们在2017年提出了“预热”技术，即在双11前对各个系统进行全面“预热”，包括Tair、数据库、应用等。为此，专门开发了预热系统。预热分为数据预热和应用预热两部分。数据预热包括：数据库和缓存预热。预热系统会模拟应用访问。通过这个访问将数据加载到缓存和数据库中，保证缓存和数据库BP的命中率。应用预热包括：预建立连接和JIT预热。我们会在双十一午夜前预建立数据库连接，避免高峰期建立连接的开销。同时，由于业务非常复杂，Java代码被解释执行，如果在高峰期同时进行JIT编译，会消耗大量CPU，延长系统响应时间.JIT预热确保代码可以提前完全编译。2017年双11，由于系统全面预热，交易曲线在零点处画了一条完美的曲线。2017-2018：存储与计算分离的技术突破2017年初，组内技术高年级学生发起了一场技术讨论：是否要将存储与计算分离？这引发了一场旷日持久的讨论。包括我上王博士课的时候，也有过关于这个问题的技术辩论。由于两人意见势均力敌，最终谁也说服不了对方。对于数据库来说，存储和计算分离是一个非常敏感的技术话题。我们都知道在IOE时代，小型机和存储是通过SAN网络连接起来的，本质上是一种存储计算分离的架构。现在又要回到这个架构上，是不是技术倒退了？另外，对于数据库来说，IO的响应延迟直接影响到数据库的性能。如何解决网络延迟问题？各种问题一直困扰着我们，没有定论。那时数据库已经可以利用云ECS资源进行大规模弹性扩展，实现了容器化部署。但是，无论如何都无法回避的一个问题是，如果计算和存储绑定在一起，就无法实现极致的弹性，因为计算节点的迁移必须对数据进行“搬迁”。而且，我们研究了计算和存储能力的增长曲线，发现在双11高峰期，对计算能力的需求急剧增加。但是，对存储容量的要求没有显着变化。如果能实现存储计算分离，只需要在双十一高峰期扩容计算节点即可。综上所述，存储计算分离是华山的一条??路，必须走。2017年年中，为了验证可行性，我们选择基于开源分布式存储Ceph进行优化。与此同时，阿里巴巴自主研发的高性能分布式存储盘古2.0也在紧锣密鼓的开发中。另一方面，数据库内核团队也参与其中，通过数据库内核优化降低网络延迟对数据库性能的影响。经过大家的共同努力，终于在2017年双11上线了基于盘古2.0的计算存储分离方案，验证了使用离线头戴式共享存储的弹性方案。这次双11之后，我们证明了数据库存储和计算分离是完全可行的。存储计算分离的成功离不开一个幕后功臣：高性能低延迟的网络。2017年双11，我们用的是25GTCP网络。为了进一步降低时延，我们在2018年双11期间大规模使用了RDMA技术，大大降低了网络时延。如此大规模的RDMA应用在整个行业中绝无仅有。为了降低IO延迟，我们还在文件系统中内置了一个大杀器——DBFS，通过用户态技术，绕过Kernel，实现了I/O路径的零拷贝。通过这些技术的应用，实现了接近本地存储的延迟和吞吐量。2018年双11，随着存储计算分离技术的大规模应用，标志着数据库进入了一个新时代。综上所述，从2012年到2018年的六年间，我见证了零点交易数量的一次次攀升，见证了其背后数据库技术的突破，也见证了阿里巴巴永不言败的精神人们。从“不可能”到“可能”的过程，是阿里巴巴技术人员对技术的不懈追求。感恩十年双十一，期待更美好的十年。
