阿里云drds手册阿里云知识产权

随着互联网时代的到来，计算机要管理的数据量呈指数级增长，但我们根本无法对用户数量做出准确的估计。我们的系统需要支持的用户数量很可能在短短一个月内突然爆发式的增长数千

本文最后更新时间： 2023-03-18 15:55:04

随着互联网时代的到来，计算机要管理的数据量呈指数级增长，但我们根本无法对用户数量做出准确的估计。我们的系统需要支持的用户数量很可能在短短一个月内突然爆发式的增长数千倍，数据很可能从原来的几百GB快速增长到几百TB。如果在疫情爆发的这个关键时刻，系统不稳定或无法访问，对业务将是毁灭性的打击。

在这种对系统性能、成本和可扩展性的新需求下，以HBase、MongoDB为代表的NoSQL数据库和以阿里DRDS、VoltDB、ScaleBase为代表的分布式NewSQL数据库如雨后春笋般涌现。

本文将介绍阿里DRDS的技术概念、发展历史和技术特点。

DRDS设计理念

自从70年代关系数据库建立以来，其实大家对数据库的追求从来没有改变过:更快的访问数据，按需伸缩以承载更多的访问和数据量，易于开发，硬件成本低。我们可以称之为数据库领域的圣杯。

为了支持更多的访问和数据，我们必须需要分布式数据库系统。而分布式系统不可避免的会面临强一致性带来的延迟增加的问题，因为网络通信本身的成本要远远高于单机通信，这种通信的成本会直接增加系统单次提交的延迟。延迟会导致数据库锁持有时间更长，使得分布式事务在高冲突条件下性能不升反降(这个可以具体理解为阿姆达尔定律)，甚至性能与单机数据库相差甚远。

从上面的解释中我们可以发现，问题的症结并不是分布式事务做不了，而是分布式事务因为性能差而没有用。数据库领域的专家们努力了40年，但至今没有人能很好地解决这个问题。Google Spanner的开发负责人经常在他的博客上谈论延迟的问题，我相信他的博客也受到这个问题的困扰。

面对这个问题，传统的关系数据库选择了放弃分布式的方案，因为在七八十年代，我们的数据库主要用于处理企业中的各种数据，面对的用户只有几千人，数据量最大的是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)，希望用我们的技术服务更多的人。

然而，当我们满怀信心地把自己的软件拿到云端时，却发现自己的软件与用户的要求相差甚远。从内部来说，SQL的复杂度是可控的，因为有DBA的同学在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前五天，网聚宝熊总来找我，说担心双11流量撑不住，系统会挂掉。于是我们向他介绍了如何使用这个自动扩展功能。他花了一个月时间买了一个数据库，并把它连接到了DRDS。数据库的能力立刻翻倍，我轻松战胜了双11，这是一个让我印象深刻的案例。

因为我们无法预测系统会在哪个点出现爆发式增长，如果这个时候系统因为技术原因无法使用，会对整个业务造成毁灭性的影响。一旦错过了出路，后悔就来不及了。我想这就是云计算特别强调可扩展性的原因。

小饭桌广播

小表广播也是分布式数据库领域最常用的工具之一。它的核心目的其实只有一个——尽可能让查询只发生在单台机器上。

我们用一个例子来说明小饭桌广播的一般使用场景。

图5小饭桌播放场景

在图5中，如果我想知道buyer id等于0的用户在商城买了哪些产品，我们通常先把这两个表连接起来，然后用where platform name = "mall "和buyerID = 0找到符合要求的数据。但是这种加入方式会导致左表大量的网络I/O。如果要读取的数据量很大，系统延迟会明显增加。

这时候为了提高性能，就必须降低跨机加入的网络开销。我们建议如下处理:将左表复制到右表的每个库中。这样，join操作就从分布式join变成了本地join，系统的性能大大提高，如图6所示。

图6

分布式事务套件

在阿里巴巴的业务体系中，有很多场景是需要交易的，比如下单减少库存，会计核算，这些都是交易场景最集中的部分。

但是，我们处理事务的方法不同于传统的应用处理事务的方案，我们非常强调事务的最终一致性和异步性。这样，可以大大减少分布式系统中的锁持有时间，从而大大提高系统性能。

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