云时代的分布式数据库：阿里分布式数据库服务DRDS

发表于 2015-07-15 21:47| 10943次阅读| 来源《程序员》杂志| 27 条评论| 做者王晶昱

《程序员》杂志 数据库 DRDS 分布式 沈询

摘要：伴随着系统性能、成本及扩展性的新时代须要，以HBase、MongoDB为表明的NoSQL数据库和以阿里DRDS、VoltDB、ScaleBase为表明的分布式NewSQL数据库如雨后春笋般不断涌现出来。本文详细介绍了阿里分布式数据库服务DRDS。

随着互联网时代的到来，计算机要管理的数据量呈指数级别地飞速上涨，而咱们却彻底没法对用户数作出准确预估。咱们的系统所须要支持的用户 数，极可能在短短的一个月内忽然爆发式地增加几千倍，数据也极可能快速地从原来的几百GB飞速上涨到了几百个TB。若是在这爆发的关键时刻，系统不稳定或 没法访问，那么对于业务将会是毁灭性的打击。

伴随着这种对于系统性能、成本以及扩展性的新须要，以HBase、MongoDB为表明的NoSQL数据库和以阿里DRDS、VoltDB、ScaleBase为表明的分布式NewSQL数据库如雨后春笋般不断涌现出来。

本文将会介绍阿里DRDS的技术理念、发展历程、技术特性等内容。

DRDS设计理念

从20世纪70年代关系数据库创立开始，其实你们在数据库上的追求就从未发生过变化：更快的存取数据，能够按需扩缩以承载更大的访问量和更大的数据量，开发容易，硬件成本低，咱们能够把这叫作数据库领域的圣杯。

为 了支撑更大的访问量和数据量，咱们必然须要分布式数据库系统，然而分布式系统又必然会面对强一致性所带来的延迟提升的问题，由于网络通讯自己比单机内通讯 代价高不少，这种通讯的代价就会直接增长系统单次提交的延迟。延迟提升会致使数据库锁持有时间变长，使得高冲突条件下分布式事务的性能不升反降（这个具体 能够了解一下Amdahl定律），甚至性能距离单机数据库都还有明显的差距。

从上面的说明，咱们能够发现，问题的关键并非分布式事务作不 出来，而是作出来了却由于性能太差而没有什么卵用。数据库领域的高手们努力了40年，但至今仍然没有人可以很好地解决这个问题，Google Spanner的开发负责人就常常在他的Blog上谈论延迟的问题，相信也是饱受这个问题的困扰。

面对这个难题，传统的关系数据库选择了放 弃分布式的方案，由于在20世纪70~80年代，咱们的数据库主要被用来处理企业内的各种数据，面对的用户不过几千人，而数据量最多也就是TB级别。用单 台机器来处理事务，用个磁盘阵列处理一下磁盘容量不够的问题，基本上就能解决一切问题了。

然而，信息化和互联网的浪潮改变了这一切，咱们突 然发现，咱们服务的对象发生了根本性变化，从原来的几千人，变成了如今的几亿人，数据量也从TB级别到了PB级别甚至更多。存在单点的单机系统不管如何努 力，都会面对系统处理能力的天花板。原来的这条路，看起来是走不下去了，咱们必须想办法换一条路来走。

但是，分布式数据库所面对的强一致性难题却像一座高山，人们努力了无数个日日夜夜，但能翻越这座山的日子看来仍然遥遥无期。

于 是，有一群人认为，强一致性这件事看来不怎么靠谱，那完全绕开这个问题是否是个更好的选择？他们发现确实有那么一些场景是不须要强一致事务的，甚至连 SQL均可以不要，最典型的就是日志流水的记录与分析这类场景。而去掉了事务和SQL，接口简单了，性能就更容易获得提高，扩展性也更容易实现，这就是 NoSQL系统的起源。

虽然NoSQL解决了性能和扩展性问题，但这种绕开问题的方法给用户带来了不少困扰，系统的开发成本也大大提高。这 时候就有另一群人，他们以为用户须要SQL，以为用户也须要事务，问题的关键在于咱们要努力地往圣杯的方向不断前进。在保持系统的扩展性和性能的前提 下，付出尽量小的代价来知足业务对数据库的须要。这就是NewSQL这个理念的由来。

DRDS也是一个NewSQL的系统，它与ScaleBase、VoltDB等系统相似，都但愿可以找到一条既能保持系统的高扩展性和高性能，又能尽量保持传统数据库的ACID事务和SQL特性的分布式数据库系统。

DRDS发展历程

在一开始，TDDL的主要功能就是作数据库切分，一个或一组SQL请求提交到TDDL，TDDL进行规则运算后得知SQL应该被分发到哪一个机器，直接将SQL转发到对应机器便可（如图1）。

图1 TDDL数据库切分

开始的时候，这种简单的路由策略可以知足用户的须要，咱们开始的那些应用，就是经过这样很是简单的方式完成了他全部的应用请求。咱们也认为，这种方案简单可靠，已经足够好用了。

然而，当咱们服务的应用从十几个增加到几百个的时候，大量的中小应用加入，你们纷纷表示，原来的方案限制太大，不少应用其实只是但愿作个读写分离，但愿能有更好的SQL兼容性。

因而，咱们作了第一次重大升级，在此次升级里，咱们提出了一个重要的概念就是三层架构，Matrix对应数据库切分场景，对SQL有必定限制，Group对应读写分离和高可用场景，对SQL几乎没有限制。如图2所示。

图2 数据库升级为三层架构

这 种作法马上获得了你们的承认，TDDL所提供的读写分离、分库分表等核心功能，也成为了阿里集团内数据库领域的标配组件，在阿里的几乎全部应用上都有应 用。最为可贵的是，这些功能从上线后，到如今已经经历了多年双11的严酷考验，从未出现过严重故障（p0、p1级别故障属于严重故障）。数据库体系做为整 个应用系统的重中之重，能作到这件事，真是很是不容易。

随着核心功能的稳定，自2010年开始，咱们集中所有精力开始关注TDDL后端运维 系统的完善与改进性工做。在DBA团队的给力配合下，围绕着TDDL，咱们成功作到了在线数据动态扩缩、异步索引等关键特征，同时也比较成功地构建了一整 套分布式数据库服务管控体系，用户基本上能够彻底自助地完成整套数据库环境的搭建与初始化工做。

大概是2012年，咱们在阿里云团队的支持下，开始尝试将TDDL这套体系输出到阿里云上，也有了个新的名字：阿里分布式数据库服务（DRDS），但愿可以用咱们的技术服务好更多的人。

不 过当咱们满怀自信地把本身的软件拿到云上的时候，却发现咱们的软件距离用户的要求差距很大。在内部由于有DBA的同窗们帮助进行SQL review，因此SQL的复杂度都是可控的。然而到了云上，看了各类渠道提过来的兼容性需求，咱们常常是不自觉地发出这样的感叹：“啊？原来这种语法 MySQL也是能够支持的？”

因而，咱们又进行了架构升级，此次是以兼容性为核心目标的系统升级工做，但愿可以在分布式场景下支持各种复杂的SQL，同时也将阿里这么多年来在分布式事务上的积累都带到了DRDS里面。

此次架构升级，咱们的投入前所未有，用了三年多才将整个系统落地完成。咱们先在内部以咱们本身的业务做为首批用户上线，通过了内部几百个应用的严酷考验之后，咱们才敢拿到云上，给到咱们的最终用户使用。

目前，咱们正在将TDDL中更多的积累输出到云上，同时也努力优化咱们的用户界面。PS：其实用户界面优化对咱们这种专一于高性能后端技术的团队来讲，才是最大的技术挑战，连我也去学了AngularJS，参与了用户UI编。

DRDS主要功能介绍

发展历史看完了，下面就由我来介绍一下目前咱们已经输出到云上的主要功能。

分布式SQL执行引擎

分布式SQL引擎主要的目的，就是实现与单机数据库SQL引擎的彻底兼容。目前咱们的SQL引擎可以作到与MySQL的SQL引擎全兼容，包括各种join和各种复杂函数等。他主要包含SQL解析、优化、执行和合并四个流程，如图3中绿色部分。

图3 SQL引擎实现的主要流程

虽 然SQL是兼容的，可是分布式SQL执行算法与单机SQL的执行算法却彻底不一样，缘由也很简单，网络通讯的延迟比单机内通讯的延迟大得多。举个例子说明一 下，咱们有份文件要从一张纸A上誊写到另一张纸B上，单机系统就比如两张纸都在同一个办公室里，而分布式数据库则就像是一张纸在北京，一张纸在杭州。

自 然地，若是两张纸在同一个办公室，由于传输距离近，逐行誊写的效率是能够接受的。而若是距离是北京到杭州，用逐行誊写的方式，就马上显得代价过高了，咱们 总不能看一行，就打个“飞的”去杭州写下来吧。在这种状况下，仍是把纸A上的信息拍个照片，【一整批的】带到杭州去处理，明显更简单一些。这就是分布式数 据库特别强调吞吐调优的缘由，只要是涉及到跨机的全部查询，都必须尽量的积攒一批后一块儿发送，以减小系统延迟提升带来的不良影响。

按需数据库集群平滑扩缩

DRDS容许应用按需将新的单机存储加入或移出集群，DRDS则可以保证应用在迁移流程中实现不停机扩容缩容。

图4 DRDS按需进行平滑扩缩

在内部的数据库使用实践中，这个功能的一个最重要应用场景就是双11了。在双11以前，咱们会将大批的机器加入到咱们的数据库集群中，抗过了双11，这批机器就会下线。

当 DRDS来到云上，咱们发现双11其实不只仅只影响阿里内部的系统。在下游的各种电商辅助性系统其实也面对巨大压力。在双11前5天，网聚宝的熊总就找到 我说，担忧撑不过双11的流量，怕系统挂。因而咱们就给他介绍了这个自动扩容的功能怎么用，他买了一个月的数据库，挂接在DRDS上。数据库能力马上翻 倍，轻松抗过了双11，也算是我印象比较深入的一个案例了。

由于咱们彻底没法预测在什么时间点系统会有爆发性的增加，而若是在这时候系统由于技术缘由不能使用，就会给整个业务带来毁灭性的影响，风口一旦错过，就追悔莫及了。我想这就是云计算特别强调可扩展能力的缘由吧。

小表广播

小表广播也是咱们在分布式数据库领域内最经常使用的工具之一，他的核心目的其实都是一个——尽量让查询只发生在单机。

让咱们用一个例子来讲明，小表广播的通常使用场景。

图5 小表广播场景

图 5中，若是我想知道买家id等于0的用户在商城里面买了哪些商品，咱们通常会先将这两个表join起来，而后再用where平台名=”商城” and buyerID = 0找到符合要求的数据。然而这种join的方式，会致使大量的针对左表的网络I/O。若是要取出的数据量比较大，系统延迟会明显上升。

这时候，为了提高性能，咱们就必需要减小跨机join的网络代价。咱们比较推荐应用作以下处理，将左表复制到右表的每个库上。这样，join操做就由分布式join一下变回到本地join，系统的性能就有很大的提高了，如图6所示。

图6

分布式事务套件

在阿里巴巴的业务体系中存在很是多须要事务类的场景，下单减库存，帐务，都是事务场景最集中的部分。

而咱们处理事务的方法却和传统应用处理事务的方案不大同样，咱们很是强调事务的最终一致性和异步化。利用这种方式，可以极大地下降分布式系统中锁持有的时间，从而极大地提高系统性能。

图7 DRDS分布式事务解决套件

这种处理机制，是咱们分布式事务可以以极低成本大量运行的最核心法门。在DRDS平台内，咱们将这些方案产品化，为了DRDS的分布式事务解决套件。

利用他们，可以让你以比较低的成本，实现低延迟，高吞吐的分布式事务场景。

DRDS的将来

阿里分布式数据库服务DRDS上线至今，你们对这款产品的热情超出了咱们的预期，短短半年内已经有几千个申请。

尽管还在公测期，可是你们就已经把关系到身家性命的宝贵在线数据业务放到了DRDS上，我可以感觉到这份沉甸甸的信赖，也不想辜负这份信赖。

通过阿里内部几千个应用的不断历练，DRDS已经积累出一套强大的分布式SQL执行引擎和和一整套分布式事务套件。

我也相信，这些积累可以让用户在基本保持单机数据库的使用习惯的前提下，享受到分布式数据库高性能可扩展的好处。

在平时的DRDS支持过程当中，我面对最多的问题就是，DRDS能不可以在不改变任何原有业务逻辑和代码的前提下，实现可自由伸缩和扩展呢？十分惋惜的是，关系数据库发展至今，尚未找到既能保留传统数据库一切特性，又能实现高性能可扩展数据库的方法。

然而，虽不能至，吾心向往之！咱们会以“可扩展，高性能”为产品核心，坚决地走在追寻圣杯的路上，并坚信最终咱们必定可以找寻到它神圣的所在。

做者：王晶昱

简介：王晶昱，花名沈询，阿里巴巴资深技术专家。目前主要负责阿里的分布式数据库DRDS（TDDL）和阿里的分布式消息服务ONS（RocketMQ/Notify）两个系统。