开源分布式数据库RadonDB的核心技术与实现

本文根据张雁飞在【IT168微学堂 第61期】的演讲内容整理而成。

讲师介绍：

张雁飞，TokuDB内核贡献者、维护者，TokuDB企业级热备工具作者。曾就职于阿里云数据库内核团队，目前为青云QingCloud数据库团队负责人，主导新一代分布式数据库产品——RadonDB的设计与研发。

内容摘要：

RadonDB是一款将分布式一致性协议Raft与MySQL相结合的新一代分布式关系型数据库，兼具NewSQL和MySQL两类数据库的优点，2018年5月10日，RadonDB在第九届中国数据库技术大会上正式宣布开源。本文，RadonDB的设计者张雁飞将从架构、执行、高可用等角度，结合开源代码为大家深度解析RadonDB的核心技术与实现。

正文演讲：

RadonDB是一个开源的分布式数据库。为什么叫RadonDB呢?RadonDB中的Radon出自元素周期表，是一种惰性气体，名字叫做氡。因其化学性质比较稳定，所以我们就以此来命名了这款数据库产品。

RadonDB包含两个部分Radon和Xenon，并不是一个简单的数据库中间件。其中，Radon类似于一个数据库中间件，而Xenon是一个高可用的MySQL管理集群工具。

上图是RadonDB的整个架构图，其中最上面一层是Radon，一个分布式的SQL层，负责SQL的解析和转发。这一层就是大家说的数据库中间件，它会根据用户请求将SQL语句生成分布式执行计划，并推到下面的存储层。

下面这一层是Xenon，一个高可用的MySQL管理工具。在这一层的每个虚线框里都是一“主”两“从”的MySQL，都通过Xenon进行管理。Xenon其实是一个无中心化的管理工具，当主节点挂了之后，会使用Raft协议进行选主，选出新的“主”之后，再根据MySQL Binlog这些机制进行数据同步，从而使新的主节点继续对外服务。

下面咱们聊一聊RadonDB的一些技术细节。RadonDB的主要功能是对用户SQL生成分布式计划以及执行器并行执行，当执行器下发到存储层以后，进行ORDER BY、LIMIT、GROUP BY等二次运算。

Radon支持集群模式，所以基本上是无状态的。当其中一个节点挂了之后，其他节点可以很快的迁移过去，保证Radon这一层的高可用。

如果从代码层面来看Radon的具体工作流程，用户SQL到达Radon之后， query.go文件会对SQL进行语法树的生成，生成之后根据SQL的类型进行处理。

首先，根据语法树生成分布式的执行计划。分布式的执行计划是根据路由表查找每个具体的数据分布在哪些后端，然后生成具体的子句。

分布式执行计划生成之后，就运行Insert executor文件，并下发到相应节点去执行。

以上，就是RadonDB 中Radon这一层的基本工作机制。

Radon这一层还有一个比较重要的功能——分布式事务。Radon分布式事务是基于MySQL原生事务——XA事务来进行的。MySQL的XA事务在执行时可分为五个阶段：第一个阶段是XA START，第二个阶段是SQL执行，第三个阶段是XA END，第四个阶段是XA PREPARE，这个阶段其实数据已经通过Binlog传到了备库，即使主库挂了，重建之后事务仍然处于XA PREPARE状态，我们可以认为数据不会丢失。最后一个阶段是XA COMMIT。

RadonDB对这五个阶段进行了分工，共分成begin、execute、commit三个阶段。

RadonDB实现了SI隔离级别的分布式事务。Radon里有一个Commit Lock，如果不加这个锁是实现不了这种隔离级别的。那么什么是SI隔离级别呢?SI是SNAPSHOT ISOLATION的缩写，它的作用是未提交的不可见，例如有三个分区，当它们都没有XA commit时，其它事务读的时候是看不到未提交事务的数据。另一个作用是部分提交不可见，还是有三个分区，第一个分区XA commit了，其他两个分区正准备commit，这时候如果有其他的客户端读数据也是不可见的。

为了检测XA的隔离级别，我们研发了一个开源工具，它的思路比较简单，就是一个更新线程不停地去更新，16个扫表线程不停地扫表。如果分布式事务满足不了SI隔离级别，那么16个扫表线程就有可能看到更新线程的部分数据。

我们进行了100多亿次操作和检测的测试，并且过程是随机的。我们会把存储层的主节点宕掉来做“主从”切换。在大量的测试中，目前还没有发现读取到部分数据的情况。

下面介绍一下RadonDB的另一个组件——Xenon，一个高可用的MySQL管理工具。假设一个节点有一“主”两“从”，三个MySQL，那么它们之间的高可用怎么来实现呢?

Xenon的工作机制是和MySQL配合，通过MySQL链接不停地去ping MySQL，并拿到MySQL的信息。一个MySQL对应一个Xenon，并部署在一个container里，一“主”两“从”分布在不同的container里面。当Master不可服务时，其他的Xenon会检测不到Master发来的心跳，这时由Xenon发起的心跳会发起选主操作，进而其他的从节点会被选为新的主节点。

接下来，我们讲一下Xenon如何发起选主操作、如何选择新的主节点以及选完之后如何保证数据不丢失?

对于一“主”多“从”的MySQL集群想要做到高可用有几个挑战：第一是如何选“主”;第二是选“主”之后，数据怎么跟原先的Master进行同步，保证数据不丢失;第三是如何尽快选“主”，当原来的“主”挂了之后，新的主节点如何尽快应用数据，并对外提供服务。

我们把MySQL的GTID和Raft的选主结合了起来。Xenon主要实现了Raft选主功能，结合MySQL GTID实现高可用。了解Raft算法的朋友可能都知道，Raft主要做两件事，第一件就是选“主”。第二个就是log同步。Xenon选“主”使用了Raft选主协议，选“主”之后会结合MySQL GTID进行数据同步。

如果是一“主”两“从”的节点，那么这两个从节点哪个被选为新的主?这里结合了MySQL的GTID和semi-sync。当我们把semi-sync的vote_timeout设置为无限长，基本上就可以认为是“主”。写完之后，至少有一个“从”会收到，然后返回给“主”，“主”再返回给cluster，这样保证至少有一个“从”和“主”的数据是完全同步的。当“主”挂了之后，和主节点数据完全同步的从节点会被选为新的主节点，之后根据MySQL的并行复制，快速回放，并对外进行提供服务。

介绍完Radon和Xenon，我们看一下，数据在RadonDB里面是怎么分布的?RadonDB的底层存储基于MySQL，也就是说由Xenon管理的一主两从是一个节点，整个存储层是由多个这样的节点组成的。

用户创建一个表的时候需要指定一个分区键，RadonDB会根据分区键把整个大表分成32个小表。分配规则是这样的，整个表有4096个槽位，其中每个小表是128个槽位，共有32个小表。

RadonDB的最小单位就是小表，命名为T1_0000到T1_0031，每个小表都是占128个槽位，例如第一个小表是从0到127。这样当用户在做Insert时，就可以依据此判断数据会落在哪个小表里。

RadonDB如何做扩容呢?RadonDB最小单位是一个小表，但4096和128这两个数字是可以配置的。在扩容上，RadonDB可以让小表在不同的机器间动态漂移。因为是MySQL表，所以把小表从一个MySQL实例上飘到另外一个MySQL实例比较简单。首先是做一个全量迁移，记下当时迁移的位点，然后再对增量进行追加。这种以小表为迁移的方式不但不影响读写操作，而且操作方便，既可以扩容，还可以缩容。

RadonDB还支持Binlog，为什么?因为RadonDB是一个分布式数据库，如果有别的数据库或数据想订阅RadonDB数据，那么就可以订阅RadonDB Binlog。连上RadonDB之后，执行SHOW BINLOG EVENTS，指定从哪个GTID开始，同时还可以指定订阅多少条。这样就可以把RadonDB数据实时的导入到异构的数据库里。

如果RadonDB收到了比较复杂的AP操作，例如JOIN，它的机制又是怎么样的呢?RadonDB还有一个计算节点，当用户SQL上来之后，RadonDB如果发现里面有比较复杂的JOIN等AP操作，会自动的把这个请求路由到计算节点上。

计算节点是插件式的，它可以是其他比较强大的AP分析型数据库，计算节点把结果计算完之后，RadonDB会自动的反馈给客户端，在这种情况下，客户端是无法感知到这些操作的。

这样做的好处是事务型和计算型是资源隔离的，但缺点是存储需要两份。如何克服缺点呢?其实目前我们也没有很好的办法，只是通过压缩暂时的解决了这个问题。

RadonDB还实现了审计日志功能，当用户的请求到达RadonDB之后，RadonDB把用户请求记录到本地磁盘上。我们可以通过上图中的多个维度进行审计，同时还可以查询慢操作。当日志请求量比较大时，RadonDB会定期进行清理。同时RadonDB还支持多种审计模式，例如只读审计、只写审计、读写审计等等。

大家可能会比较担心分布式数据库灌进了大量数据就很难导出来了。针对这种情况，RadonDB提供了导入和导出的工具，这些工具是并行式的，导入/导出的速度比MySQL原生的Mydumper还快。

RadonDB提供了全链路的监控，如果分布式数据库是一个黑盒，那么出了问题就很不容易排查。RadonDB从前往后做了三层监控，第一层就是show processlist，这层是监控用户到RadonDB的连接，跟MySQL是一样的。其中RadonDB实现了一个序列表，这一层的作用就是可以看到cluster到RadonDB执行的SQL语句。第二层是监控RadonDB内部峰值事务执行到哪个阶段，大家可以通过show txnz命令进行监控;最后一层就是show queryz，这个命令可以看到具体的子句在哪些后端执行。

通过这三层监控就可以很快的定位到具体问题，比如一个慢MySQL，它到底是慢在哪些地方。

上图是性能对比表，上面的RadonDB是四个存储节点，下面是单机MySQL。大家可以看到，RadonDB的性能基本上是单机的三倍，而延迟基本上是1/3。为什么会出现这种情况呢?这就是分布式的威力。假设我们有一个1TB的表，如果使用单机数据库，那么Btree会比较高，而且每次请求的IO深度路径也会比较长。而RadonDB会把1TB的数据分成四个节点，假设平均每个节点是250G，每个节点还有细分每个小表。当用户请求时，我们只需请求小表，而且RadonDB对所有的请求都是并行执行的，时间完全取决于最慢的小表。所以在这种设计中，RadonDB的性能基本上会是单机的三倍，而延迟是1/3。

最后说一下RadonDB的展望，大家都了解类似于Google Spanner这种NewSQL会是一个大趋势，而且很多公司也都在完全自主研发NewSQL。有人都认为传统的基于MySQL分库分表的方式已经过时了，而我们提出了一个新的概念——MyNewSQL，就是MySQL和NewSQL相结合。

其实RadonDB就是一个MyNewSQL，它把NewSQL领域里常用的算法都拿到了MySQL里，从而实现了MyNewSQL。RadonDB 最后实现的功能和NewSQL基本无异，但它是基于MySQL进行存储，表、数据结构都可以是异构的，性能上也有很大的提升。

一个分布式数据库的技术其实是非常繁琐的，通过这篇文章是不可能完全讲清楚的，但好在RadonDB已经开源，大家可以去GitHub上查看源码。

RadonDB的GitHub地址：https://github.com/Radondb