酷应用

何登成13年开发缩影与阿里数据库内核锤炼之路

百家作者：聊聊架构 2017-12-07 05:04:34

嘉宾：何登成

编辑：薛梁

数据库技术，不管何时何地，不管是互联网公司还是传统企业，都对数据库技术有着较高的需求和要求。除了要支撑业务发展之外，还要不断地考虑如何在数据库自身性能上有质的突变。

在 12 月北京 ArchSummit 全球架构师峰会上，设置了数据库架构专题，主要围绕高并发业务模式环境下，探讨对数据库从架构到体系进行优化的技术实战。

在峰会召开之前，很荣幸能采访到本专题出品人——何登成老师，他有超过 13 年的数据库内核研发经验，也曾多次担任阿里双 11 购物狂欢节的数据库总负责人，目前是阿里巴巴数据库内核研发团队负责人，带领团队打造集高性能、低成本、分布式、持续可用于一体的下一代数据库系统，为阿里的内外部业务发展赋能。在数据库的内核研发、性能优化、整体架构设计上有着丰富的经验。一起来听听他的数据库锤炼之路。（以下是采访整理）

不神秘，但神奇的数据库内核团队

何登成目前负责的阿里巴巴数据库内核研发团队，隶属于阿里巴巴平台技术事业群 - 数据库事业部。阿里巴巴数据库内核研发团队组建于 2010 年，成立初期的目标就是去 IOE，早期的产品是开源 MySQL 的阿里巴巴分支 AliSQL。使用 AliSQL，团队顺利达成了去 IOE 的使命，同时也支持了过去多年的双 11 购物节。而随着阿里业务的飞速发展，以及硬件的更新换代，数据库技术无论是在学术界还是工业界都焕发出蓬勃的生命力，面临着全新的挑战。

双 11 给我带来的收获和成就感

何登成很自豪的说，刚刚过去的 2017 年双 11，数据库内核团队在技术上交出了一份比较完美的答卷，秒级 32.5 万的交易峰值，双 11 高峰期的平滑交易曲线，都预示着团队真正做到了双 11 前 CTO 定下的“喝着茶过双 11”的基调，值班的技术同学也很快的进入了买买买的剁手行列之中。但罗马城不是一天就建成的，双 11 能走到今天，何登成个人认为技术上经历了两个比较重大的突破是不可忽视的：

从未知到已知

2009 年，当阿里提出双 11 的概念并开始做双 11 购物节时，无论是业务上还是技术上，没有人能够真正明白双 11 到底意味着什么，这是一个巨大的未知。对数据库团队来说，并不知道每个集群的压力在双 11 零点峰值会有多大？哪个数据库集群会最先碰到瓶颈？每个集群需要扩容多少机器？

所有的未知积累在一起，导致早期的双 11 经常会顾此失彼，没能给用户提供更好的使用体验。当然，作为技术人员，最不能容忍的就是光天化日、朗朗乾坤之下，竟然有黑暗的存在。为了将未知转化为已知，也诞生出了目前阿里几个重量级的产品：EagleEye（鹰眼）分布式调用跟踪系统，基于真实线上部署的全链路压测平台。

而在数据库方面，做到了所有的 SQL 打标、采集、追踪和智能化分析（CloudDBA）；数据库监控也从早期的分钟级一路进化到现在的秒级（DBPaaS，秒级监控，能够发现毫秒级的抖动）；创立并维护了阿里巴巴自己的 MySQL 分支 AliSQL，对 MySQL 在性能、功能和可运维性等方面，做了大量的改进。

所有的这些，使得团队在技术上达成了一个目标，将双 11 从技术上的一个未知问题转变为一个已知问题，然后每年对这个已知问题进行求解。双 11 经历早期的阵痛之后，逐渐进入了一个良性循环的状态。

从已知到追求极致

做技术不是解一次方程，只有一个确切的解。为了达成同样的一个业务目标，不同的技术同学，不同技术深度和技术视野的同学，往往会给出不同的技术解决方案。

何登成说，这也许就是做技术的魅力所在。当团队将未知问题转化为已知问题之后，就在不断地思考：现有的解决方案是否是最优方案，在技术上是否有改进的空间。双 11 备战时间过长，能不能缩短？双 11 参与的技术人员过多，能不能减少？双 11 的硬件资源开销过大，能不能降低？有了新的问题和挑战，技术人员也有了新的舞台和方向。同样以数据库为例，近几年何登成团队在以下的几个方面不断突破自我：

1、 分布式数据库 X-DB。结合 AliSQL 和自研的高性能分布式一致性算法 X-Paxos，团队推出的分布式数据库 X-DB，全面兼容 MySQL 生态，数据强同步，自动选主，一跃成为一个达到金融级别可靠性和可用性的数据库。在今年的双 11 核心集群上大规模部署，提供给了业务和用户更好的可靠性和可用性体验，而且业务零改造成本。

2、 数据库计算存储分离。相对于无状态的业务系统，数据库是一个强状态系统。无状态系统可以做到快速的弹性，但是数据库系统的弹性伸缩一直是一个巨大的挑战。

数据库的计算存储分离本身不难，难的是计算存储分离之后，访问存储层数据的延时增加对性能的负面影响，在阿里双 11 的高性能诉求下，计算存储分离一定不能以牺牲性能为代价。

在今年双 11 前，团队在数据库内核上做了计算存储分离的技术优化，事务处理性能相对于优化前提升了 100% 以上，数据库计算存储分离也顺利在双 11 核心集群落地，数据库也具备了等同于业务系统的弹性能力，资源快速伸缩。

3、 智能化的双 11 备战。双 11 备战早期是一个人力密集型的工作，何登成一直在思考，如何以技术来解决备战问题。前段时间，亚马逊在其博客上公开的 OtterTune：通过机器学习自动优化 DBMS 文章，引发了一波数据库领域人与人工智能的大探讨。

而阿里数据库团队从更早就开始探索这条路，研发了 CloudDBA 平台，通过全量的数据收集，辅以机器学习的算法，今年的双 11 人力投入，相对于之前有了极大的降低。

从未知到已知，从已知到追求极致，阿里巴巴的数据库技术，将在追求极致的路上不断探索。

不计其数的经历中，印象最深刻的技术选型案例

何登成作为数据库总负责人，参与过多次阿里巴巴的双 11 备战。中间也经历过很多故事，到现在都记忆深刻，一一罗列需要巨大的篇幅。在此举一个小技术改进带来巨大业务价值的例子：X-KV，KV 接口直接访问数据库中的数据。

“问题的起源，来自于阿里的几个数据库核心集群在双 11 的读压力非常大，传统的解决方案：在数据库前端搭建缓存。但是，我们的集群数据更新非常频繁，增加缓存会带来数据一致性问题，而且维护缓存的数据更新也会给系统带来极大的复杂性。

我们解决这个问题的方式比较有意思：将缓存和数据库融合在一起，通过 KV 接口直接访问数据库存储引擎中的数据，一来消除了数据一致性问题，二来绕过了整个数据库的 SQL 层，极大地提升了数据库的读能力。经过验证，通过 KV 接口直接读取数据库，在我们某一个数据库核心集群上，相对于 SQL 接口有着近 5 倍的性能提升。

基于验证的数据，X-KV 技术顺利在阿里巴巴的数据库核心集群上落地，取得了非常大的性能提升和业务收益。同时，这也是一份数据，多种计算能力的一种探索，未来除了 SQL 接口、KV 接口，数据库还可以以更为丰富的接口给用户提供更大的便利性。

类似的大大小小的技术优化还有很多，除了这里提到的 X-KV，小的还包括热点更新优化、线程池优化、Redo Buffer 优化，大的包括分布式数据库、计算存储分离、智能化诊断等。双 11 巨大的业务挑战，对数据库在各方面的技术实现都提出了极致的需求。”

现代硬件体系架构和数据库内核优化之间的互推

何登成说，硬件的发展对软件的促进这个话题可以展开为一篇非常好的综述性论文。在这里想简单表述的是数据库团队如何看待硬件发展对数据库技术带来的影响，以及应对策略。

硬件的发展究竟对数据库有什么影响？早在 2008 年，图灵奖获得者 Michael Stonebraker 教授就做过相关的研究，并在当年的 SIGMOD 会议上发表了著名的 Paper：《OLTP Through the Looking Glass, and What We Found There》，摘录其 Paper Abstract 第一段话：

Online Transaction Processing (OLTP) databases include a suite of features — disk-resident B-trees and heap files, locking-based concurrency control, support for multi-threading — that were optimized for computer technology of the late 1970’s. Advances in modern processors, memories, and networks mean that today’s computers are vastly different from those of 30 years ago, such that many OLTP databases will now fit in main memory, and most OLTP transactions can be processed in milliseconds or less. Yet database architecture has changed little.

这篇 Paper 展示出的数据在当年还是震惊了整个数据库界，传统架构下的数据库系统，只有 6.8% 的 CPU 资源做的是有用功，而绝大部分的 CPU 都消耗在了 2B3L 上（2B：B+Tree，Buffer Pool；3L：Logging，Locking，Latching）。

在这篇 Paper 之后，一系列新型的高性能数据库应运而生，包括但不限于 Stonebraker 老爷子自己的 H-Store（后面商业化为 VoltDB）、微软的 Hekaton、SAP HANA、以及慕尼黑工业大学的 HyPer。

前面提到的是研究领域对新硬件对数据库技术带来的影响，而另一个则是何登成的亲身体验：AliSQL 从 2010 年开始到现在，基于 MySQL（InnoDB）做了大量的性能优化，但是随着硬件的发展，团队却发现软件的性能提升越来越赶不上硬件的更新换代，软件系统内部的并发瓶颈极大的限制了系统在多核上的扩展性，往往一台主机上需要部署多个数据库实例，才能将硬件的资源耗尽。换句话说，数据库团队真正意识到在实际环境中碰到了 Stonebraker 老爷子在 2008 年 Paper 中提出的问题。

看到了问题，那该如何应对？答案是：基于团队对 MySQL 数据库内核深入的掌控，基于 MySQL SQL 层和引擎层分离的特性，基于对数据库新技术发展方向的理解，在 100% 兼容 MySQL 生态的前提下，解决现有 MySQL InnoDB 存储引擎架构带来的 2B3L 问题，面向软硬件 Co-Design 的理念，自研高性能低成本存储引擎 X-Engine。

打破常规的存储引擎 X-Engine 所具备的高性能特征

何登成说，X-Engine 是阿里数据库立足于当前硬件架构的飞速发展，面向业务高性能和低成本的需求，在软硬件 Co-Design 的理念下对整个软件架构进行颠覆性重构的系统。X-Engine 的设计理念是设计更亲和现代硬件的软件架构来释放硬件的效率，让每个 CPU 的周期，每个内外存的 bit，每个网卡的 IO 都产生业务价值。基于这个设计理念，X-Engine 在多个层面都进行了颠覆性的创新：

在整体架构上，X-Engine 放弃了经典 ARIES 架构，借鉴了 LSM 的分层思想和内存数据库的技术，在此基础上针对内存，以及多种外存的特性分别设计更亲和其硬件特性的数据结构和算法，充分提高多种硬件的效率。例如：在内存和 CPU 缓存层面，X-Engine 实现了非常亲和 CPU 缓存的内存索引结构；在外存层面，X-Engine 对 NVRAM、SSD、HDD 等多种外存硬件采用分层存储，不同的存储层根据硬件特征保存不同数据格式和业务意义的数据，提升存储效率。

在计算架构上，X-Engine 实现了统一的异步调度架构，无锁数据结构，轻量级锁，乐观并发控制实现来减少上下文的切换，进而减少 CPU 的 stall，提升 CPU 的计算效率；同时引入 FPGA 等异构计算芯片，将 X-Engine 中的 compression、compaction 等矢量计算逻辑下沉到异构计算，实现计算分层，提升整体计算效率。

在分布式架构上，X-Engine 将 DPDK、RDMA、用户态协议栈等下一代网络架构融合到自身的分布式层中，提升分布式一致性、分布式存储、分布式事务的效率。

在存储架构上，X-Engine 放弃了传统数据库内外存采用单一数据结构，内存只是外存缓存的老思想；根据内存及多种外存的硬件特性，针对性的设计实现了多种高效的数据结构与不同的存储层亲和，大幅提高多层存储的效率。

在标准的 Sysbench 纯写、纯读测试场景下，32-Core（64-HyperThread），基于 X-Engine 的 X-DB 数据库，单实例能够做到近 65 万的 TPS 和 150 万 + 的 QPS，同机型下相对于 MySQL（InnoDB）有着巨大的性能优势，也进一步佐证了 X-Engine 设计理念的正确性和前瞻性。

X-DB 在阿里内部获得了巨大成功的关键

X-DB 是数据库团队自研的新一代分布式关系型数据库，是对传统关系型数据库的传承和革新。X-DB 不仅在高可能、强一致、高性能、低成本、高伸缩等多个方面作出了划时代的变革，更是传承了传统数据库强大的 SQL 接口，系统管理能力。

NoSQL 的衰弱和 NewSQL 的兴起，恰恰证明了这一点：一个新的分布式数据库，如果没有传承，而是自建一个新的生态，将会极大的提高用户的学习和使用成本，整个工具和支持配套也将面临很大的困难。

因此，X-DB 作为一个新一代分布式关系型数据库，设计之初就选了业界相对开放和成熟的 MySQL 开源生态作为自己的基础。这样不仅可以让 MySQL 生态中的用户零成本的切换到 X-DB 中，快速赋予业务分布式数据库所带来的多种能力；同时可以让 MySQL 生态中的各种周边工具和 DBA 等生态的参与者平滑的切换到分布式时代，赋予其支撑分布式数据库的能力。

继承关系型数据库系统的优点，融合 NewSQL 和研究领域最新的创新，X-DB 在以下几个方面展现出了独特的竞争力：

通过软硬件结合的设计理念，自研高性能低成本存储引擎 X-Engine，引入多种创新的研究和算法，使得 X-DB 在性能和成本上，有了极强的优势。
通过一体化的设计理念，作为分布式数据库的 X-DB，没有任何第三方的外部组件依赖，对业务实现了透明化的数据 Sharding 能力以及跨 AZ（同城多机房）、Region（跨城部署）甚至是全球化部署的能力，5 个 9 以上的持续可用率。
通过存储计算分离的设计理念，X-DB 彻底将数据库从一个重量级的有状态系统转化为一个轻量级的无状态系统，具备了快速的弹性扩展和伸缩能力。
而达成上述所有这些，都基于着兼容成熟生态的理念。兼容成熟、开放的 MySQL 生态，无论是业务还是数据库运维、管控，都跟原有的 MySQL 生态无缝兼容，践行科技以人为本。

事实证明 X-DB 选择的这条路是非常正确的。在阿里集团及生态下的子公司内部，X-DB 在短短的几个月内、在非常少的人力参与下，迅速的完成了对大量传统 MySQL/AliSQL 集群的换代升级，使得阿里数据库整体进入了分布式时代，整个过程业务几乎零参与。

同时 X-DB 对 MySQL 生态下的运维系统 / 工具、知识体系也实现了兼容，整个 MySQL 时代的支撑平台，支撑人员都可以平滑的过度到分布式数据库时代，拥有了支撑下一代数据库的能力，这个是非常难得的。

“创新”“变革”之我见

何登成说，这个问题让他想起之前在跟入职阿里新同学做的一个师兄分享上，一个阿里新同学问他一个问题：“师兄，你在数据库领域工作了这么多年，为什么仍旧能够保持这样的专注度和激情？”

“虽然我在数据库内核研发领域已经 13 年了，但从我最早读博阶段在神通做国产 OSCAR 数据库开发，到后来在网易杭州研究院做 TNT 引擎，再到现在在阿里做下一代高性能低成本分布式关系型数据库 X-DB，从事数据库研发的工作从未发生变化，但是所遇到的问题一直都在变化，所关注和研究的技术也有了很大的区别。

早期做 OSCAR 的时候，更多的是在解决传统关系型数据的优化上；到现在 X-DB 的研发，需要重新设计整个软硬件 Co-Design 的架构，需要做针对新硬件的指令集优化，需要不停的关注国际上 TOP 会议中最新发布的技术方案。技术在不停的创新，挑战也在不停的提升，正是这个驱动我保持极大的热情，持续关注最新的，最前沿的技术，来解决技术和业务的挑战。”

捣鼓技术，才是真爱好

数据库系统是一个技术的集大成者，实现一个数据库系统涉及到几乎所有的后端技术。要实现一个优秀的数据库系统，需要在各个技术层面都有深入的研究，特别是底层技术方面尤为重要。

这么多年的积累下来，何登成在这方面有不少的经历和沉淀，特别是 C/C++ 底层语言级别的一些优化经历，有很多的心得和好玩的事情，去年还受邀参加了 C++ 及系统软件技术大会，做了题为《高性能 C/C++ 系统性能优化》的分享，把自己的一些心得分享给大家。

这里举一个小例子。大家可能听说过当代 CPU 为了追求更高的性能，可能会对程序中的某些指令乱序执行，但大部分人都觉得 CPU 乱序和自己很远，平时 coding 中在一个赋值或者读变量的时候会想一下这会不会有乱序呢？最早的时候也没有，然后就遇到了问题。

我在网易开发 TNT 引擎的时候，遇到过一个十分诡异的性能问题。引擎在高负载下会出现诡异的性能抖动，个别系统 mutex 偶尔会出现调度异常。在开发数据库引擎的时候，为了追求更高的效率，一般都会自己实现 mutex，但是多位同学都 Review 了加锁和释放锁的代码，逻辑均没有异常。

排查陷入了僵局，既然逻辑没问题，那就只可能是执行的问题了，我那时候刚做过 CPU 架构的分享，突然就想到 X86 CPU 虽然很少乱序，但也是有 LoadStore 乱序的可能性的。我就带着这个可能重新 Review 了代码，发现了在 unlock 的实现逻辑中对于 lockword 的写和 waiters 的读有可能存在乱序，导致没有调用唤醒落地，从而出现 mutex 调度异常。

这件事情对我的启发很大，第一次发现原来和 CPU 架构是如此的接近，之后我再写代码，做架构设计的时候特别关注：这段代码，这个架构是否能让 CPU 正确、高效的执行，能不能有对 CPU 缓存、体系更友好的优化？一直到现在我都是这样要求团队的同学的，要关注 CPU、内存、外存、网络的实现架构，要用软硬件 Co-Design 的思维来指导架构设计和开发，这也是 X-DB 高性能的源泉。

结束语

总的来说，在互联网快速发展，硬件更新换代的大背景下，各个公司在最基础的数据库技术上，都面临着极大地挑战，也都取得了巨大的创新成果。作为本届《ArchSummit 全球架构师峰会》数据库架构专场的出品人，我很荣幸邀请到了来自 Google、腾讯、阿里的数据库专家们，带来他们在数据库上的最佳实践，每一个议题都是精挑细选，希望对参会的同学们有所帮助。此外，由于个人原因很遗憾不能到场跟大家现场分享和交流探讨，希望在不久的将来，还有这么好的分享和交流的机会。

我们是否需要通用C++软件包管理器?

怎么让不可靠的UDP可靠？

一起来聊聊架构

我的另外一个身份

再次推荐明天（12 月 8 日）开幕的 ArchSummit 全球架构师峰会，此次我作为数据库架构专场的出品人，很荣幸邀请到来自 Google、阿里巴巴和腾讯的同行们，每一个 Topic 都是经过精挑细选，干货满满。

数据库架构专场明早会跟主会场（和王坚博士等人的演讲）同步进行，这是一种认可，更是巨大的挑战，希望朋友们现场支持，绝对让您不虚此行，我的专场演讲列表如下：