【IT168 技术】本文根据张雁飞老师在2018年5月10日【第九届中国数据库技术大会(DTCC)】现场演讲内容整理而成。

▲张雁飞 Array | QingCloud 数据库高级技术专家

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

　　摘要：随着数据规模的逐步扩大，存储和运维成本逐渐增加，企业对数据库的要求也逐渐提高。有人认为以MySQL为代表的传统数据库已经过时，不能满足数据爆炸时代企业的要求;以NoSQL为代表的新型数据库仍有局限性，不具备ACID特性，很难满足企业对核心业务数据的严苛需求。此次分享的RadonDB是一款将分布式一致性协议Raft与MySQL相结合的新一代分布式关系型数据库。RadonDB的最大特点是结合两类数据库的优点，让DBA无缝地从传统的、单机时代的MySQL过渡到云原生的、无限扩展的分布式关系型数据库。

　　分享大纲：

　　1、 可扩展

　　2、 高可用

　　3、 强一致

　　4、 易部署

　　5、 MyNewSQL

　　RadonDB架构图

　　RadonDB定位是新一代分布式关系数据库，在今天这个云计算快速发展的时代，我们更愿意称它是一个云原生数据库，云原生数据库的天然属性是分布式、可扩展、高可用、强一致。下面的MyNewSQL，是因为我们把MySQL和NewSQL融合起来，来满足以上的几个特性。

　　这是RadonDB的架构图，我们可以看到，主要分上下两层，上层是一个分布式的SQL层，它由多个SQL节点组成，负责用户请求和申请分布式的执行制定计划。下层是存储层，这个存储层与其他NewSQL不一样的地方是，我们用的MySQL，可以看每个虚线框里都是三副本的MySQL。它们之间的高可用，我们使用了NewSQL里面比较流行的Raft一致性算法。这个后面会有详细的介绍。右下角是一个计算节点，这个稍后也会介绍，这就是RadonDB整个的架构图。

　　Distributed SQL

　　下面，看一下分布式的SQL层，SQL层的职责可以看下面这个图。

　　当中一个请求到来之后，SQL层会把这个请求解析成分布式的执行计划，然后，把这个SQL在后端的存储层并行的执行。而且它还会进行二次运算，就是Orderby/limit/groupby/aggration/join….等等。它还是一个无中心化的设计，部署起来比较方便，容易扩展，这是整个SQL层的一个设计。

　　Storage Nodes

　　再看存储层，存储层是RadonDB里一个比较新颖的设计，也是我们定位为在新一代分布式数据库的一个原因。

　　存储层，每个副本都是一个MySQL，因为MySQL不光有计算能力，还有存储能力。如果单单是一个KV的话，计算能力就比较弱一些，这是我们目前存储层使用MySQL的一个考量。整个存储层，由多个存储节点组成，每一个存储节点都是由三副本的MySQL组成，副本是通过Raft协议进行选主，然后再结合MySQL的自身的一套机制完成高可用。

　　副本高可用

　　接下来，我们看一下副本高可用。副本高可用其实有几个比较大的挑战。

　　第一个挑战，怎么快速选主?

　　第二个挑战，选出新的主后，数据怎么快速地回放?

　　第三个挑战，数据回放完，数据怎么保证不丢失? RadonDB是怎么解决的?

　　对于第一个挑战，我们使用了Raft协议，大家要知道，Raft协议主要干两件事，第一个就是选主，第二个是数据同步。在RadonDB里只使用Raft进行选主，当主挂掉之后，我们使用Raft选出新的主，然后数据同步。我们是基于MySQL原生的FGTID机制和并行复制这些特性进行快速回放。

　　保证数据不丢失，我们还是基于MySQL，并使用了MySQL的Semi-Sync机制，当用户写到主副本时，首先，它要到达一个从副本，从副本收到之后，再反馈给客户端，这样就时刻地保证了一个从副本与主副本的数据完全一致，从节点被选入新的主节点，保证了这个数据不丢失。

　　当选入新的主节点之后，RadonDB的Log 并行复制还是基于MySQL的机制，并行复制，快速地回放，这就等于实现了把Raft选主和Log 并行复制结合。原生态Raft协议里这两个，Raft Log并行回放是比较困难的，但是，我们结合MySQL就很好地完成了。而且，这三个副本是一个无中心化的设计，只要我们可达，它的部署比较灵活。

　　扩容

　　RadonDB的底层是全部基于MySQL，所以在扩容的时候也比较方便，因为MySQL有一套工具和机制。

　　在RadonDB里，每一个大表被分成了很多个小表，这样，我们优先扩容小表，会选一些热度高的小表进行漂移，漂移的机制是先全量，全量时，我们记住当时的一个位点，就是MySQL里Binlog位点，全量之后，我们再追这个增量，也是基于(GTID)这种机制。这样，前端业务基本上没有影响的情况下，完成了小表在物理机之间的动态漂移，当然你也可以制定一些规则，比较灵活。

　　分布式事务

　　RadonDB支持分布事务，还是基于MySQL原生XA机制来完成的。所以，大家可以看到RadonDB这上面能力跟MySQL很好地结合起来。

　　大家可以看到上图，其实MySQL Xa机制总共有5个步骤，但是到RadonDB里，我们进行了抽象，就是进行了封装。我们实现了快照的隔离级别，实现了Snapshot Isolation事务隔离级别。

　　Binlog

　　另外，RadonDB支持Binlog，大家可能认为一个分布式数据库，就是里面需要放一些海量的数据，但数据一旦进入你的分布数据库，怎么能出来?就比较麻烦，因此， RadonDB提供一个Binlog机制，就是让数据能快速的同步处理。

　　OLTP + OLAP

　　比如说，我们有一个OLAP的集群，可设置为RadonDB的Binlog，Binlog是实时地更新，这就完成了一个异构化的过程和数据流出，而且是实时的。

　　大家也看到，在刚才的架构图里，右下角有一个计算节点，其实，我们的计算节点就是通过这种机制跟RadonDB的数据进行同步。这样，就把OLTP和OLAP结合了起来，当用户一个比较复杂的查询到达RadonDB之后，RadonDB会根据SQL的模式发到TP节点还是AP节点，前端的用户是没有感知的，这就做到了一些资源的隔离。当然了，这也有一个缺点，数据可能是两份，但目前，我们是通过异构化、列式存储来进行的，高压缩做这种机制。

　　审计日志

　　另外，RadonDB还提供了一些审计日志这些功能，为了方便大家对业务进行一些审计，而且审计机制还可以定位一些慢查询SQL，因为分布式的数据库，节点比较多，所以定位一个SQL会比较复杂，有了审计日志，大家可以定位一些慢的SQL。

　　备份和恢复

　　RadonDB提供了一整套备份和恢复的工具，可以让用户快速地把数据流进去，流出来，比原生的要快很多。

　　性能

　　这是我们做的一个新的对比，可以看到，RadonDB在四个节点跟单机的MySQL的一个对比，基本上，性能是单机的三倍，但延迟只是1/3，性能明显提升，这就是分布式数据库的威力。而且这个性能基本上是可以横向扩展的。

　　RadonDB还提供了一些可调用的参数，让外面的监控可以很好地调用，这是RadonDB比较灵活的一个地方，可以根据定制让前端或者产品线调用。

　　监控

　　另外，RadonDB提供了一个全链路的监控，通过它，分布式就不再是个黑盒子。

　　mysql> show processlist;

　　第一条命是，MySQL常用的，表示用户的链接到RadonDB的状态。

　　mysql> show txnz;

　　第二个命令是，分布式事务在哪个阶段执行，耗时多少，这个都可以很清楚地看到。

　　mysql> show queryz;

　　最后一个命令，具体哪些子句落到哪些节点，甚至耗时多少，比如说，某个节点有一些问题，都可以从这个上面反映出来，比较灵活。