开源分布式数据库RadonDB的核心技术和实现是什么？

RadonDB是结合了分布式一致性协议Raft和MySQL的新一代分布式关系数据库。它兼有NewSQL和MySQL数据库的优点。下面将从架构、执行、高可用等角度，结合开源代码，为您深入剖析RadonDB的核心技术和实现。

RadonDB是一个开源分布式数据库。为什么叫RadonDB？ RadonDB 中的氡气来自元素周期表。它是一种惰性气体，名为氡。由于其相对稳定的化学性质，我们以此命名了该数据库产品。

RadonDB 由以下部分组成：wo部分，Radon和Xenon，并且不是一个简单的数据库中间件。其中Radon类似于一个数据库中间件，而Xenon则是一个高可用的MySQL管理集群工具。

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

下层是Xenon，一个高可用的MySQL管理工具。这一层的每个虚线框中都有一个“主”和两个“从”MySQL，两者都通过 Xenon 进行管理。 Xenon实际上是一种去中心化的管理工具。当主节点发生故障时，将使用Raft协议来选择主节点。选择新的“master”后，会根据MySQL Binlog机制同步数据，以便新的master节点继续服务extern所有各方。

我们来谈谈RadonDB的一些技术细节。 RadonDB的主要功能是为用户SQL生成分布式计划并与执行器并行执行。执行器发送到存储层后，执行ORDER BY、LIMIT、GROUP BY等二次操作。

Radon支持集群模式，所以基本上是无状态的。当其中一个节点发生故障时，可以快速迁移其他节点，保证Radon层的高可用性。

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

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

生成分布式执行计划后，运行Insert执行器文件，并分发到对应的节点执行。

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

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

RadonDB将这五个阶段分为三个阶段：开始、执行和提交。

RadonDB实现SI隔离分布式事务级别。 Radon 中有一个提交锁。如果不添加此锁，则无法实现此隔离级别。那么SI隔离级别是多少呢？ SI 是快照隔离的缩写。它的功能是使未提交的交易不可见。例如，如果有三个分区，并且没有一个分区有XA提交，则其他事务在读取时看不到未提交的事务。数据。另一个影响是部分提交是不可见的。仍然有三个分区。第一个分区已提交 XA，另外两个分区正在准备提交。此时如果还有其他客户端读取数据，则不可见。

为了检测Stop的隔离级别而扫描仪表。如果分布式事务不能满足SI隔离级别，那么16个表扫描线程可能会看到更新线程的部分数据。

我们进行了超过100亿次的运算和检测测试，这个过程是随机的。我们将存储层的主节点拿下来，进行“主从”切换。在大量的测试中，没有读取到部分数据。

下面介绍RadonDB的另一个组件——Xenon，一个高可用的MySQL管理工具。假设一个节点有1个“主”、2个“从”和3个MySQL。它们之间如何实现高可用？

Xenon的工作机制是和MySQL配合，通过MySQL链路不断ping MySQL，获取MySQL信息。一台MySQL对应一台Xenon，部署在容器中。一个“master”和两个“slave”分布在不同的容器中。当Master不可用时，其他Xenons将无法检测到Master发送的心跳。此时Xenon发起的心跳会发起Master选举操作，其他Slave节点将被选举为新的Master节点。

接下来我们来说说如何Xenon发起master选举操作，如何选出新的master节点，选举后如何保证数据不丢失？

MySQL集群实现高可用有几个挑战： “主”和多个“从”：首先是如何选择“主”；二是选择“master”后如何与原来的Master同步数据。保证数据不丢失；三是如何尽快选出“大师”。当原来的“主”挂了之后，新的主节点如何尽快应用数据，对外提供服务。

我们将MySQL的GTID和Raft的leader选举结合起来。 Xenon主要实现Raft选主功能，并与MySQL GTID结合，实现高可用。了解Raft算法的朋友可能知道Raft主要做了两件事。首先是选择“主人”。第二个是日志同步。 Xenon使用Raft master选举协议选择“primary”。选择“primary”后，会结合MySQL GTID进行数据同步。

如果是一个“master”和两个“slave”节点，那么这两个slave节点中的哪一个被选为新的master呢？这结合了 MySQL 的 GTID 和半同步。当我们把semi-sync的vote_timeout设置为无穷大时，基本上就可以认为是“main”了。写入后，至少有一个“slave”会收到然后返回给“master”，“master”再返回给集群。这保证了至少一个“从机”和“主机”的数据完全同步。当“master”挂掉后，与主节点数据完全同步的从节点将被选为新的主节点。然后，基于MySQL的并行复制、快速播放以及对外提供服务。

介绍完了Radon和Xenon，我们来看看RadonDB中数据是如何分布的？ RadonDB的底层存储是based on MySQL，这意味着由 Xenon 管理的一个主服务器和两个服务器。 Slave是一个节点，整个存储层是由多个这样的节点组成的。

用户创建表时，需要指定分区键。 RadonDB会根据分区键将整个大表分成32个小表。分配规则如下。整个桌子有4096个槽位，其中每个小桌子有128个槽位，总共有32个小桌子。

RadonDB的最小单位是一个小表，命名为T1_0000到T1_0031。每张小桌占用128个槽位。比如第一个小表是从0到127，这样用户在进行Insert的时候就可以通过这个来判断数据会落到哪个小表中。

如何扩展RadonDB？ RadonDB的最小单位是一个小表，但是可以配置4096和128这两个数字。在扩展方面，RadonDB可以允许小表在不同机器之间动态漂移s。因为是一张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 实现了一个序列列表。该层的作用是查看集群对RadonDB执行的SQL语句。第二层是监控RadonDB内部峰值事务执行的阶段。是ou可以通过show txnz命令监控；最后一层是show queryz。该命令可以查看特定子句在哪些后端上执行。

通过这三层监控，可以快速定位具体问题，比如MySQL慢，到底慢在哪里？

上图是性能对比表。上面的RadonDB有四个存储节点，下面是一个独立的MySQL。可以看到，RadonDB的性能基本是单机的3倍，延迟基本是单机的1/3。为什么会出现这种情况？这就是分配的力量。假设我们有一个 1TB 的表。如果我们使用独立数据库，Btree会更高，每个请求的IO深度路径会更长。 RadonDB会将1TB的数据划分到4个节点。假设每个节点平均250G，每个节点都会细分每个小表。用户请求时，我们只需要请求小表，RadonDB执行所有req多个用户并行，时间完全取决于最慢的小表。所以在这个设计中，RadonDB的性能基本上会是单机的3倍，而延迟是1/3。

最后说一下RadonDB的前景。大家都知道像Google Spanner这样的NewSQL将会是一个大趋势，而且很多公司也在完全独立地开发NewSQL。有人认为基于MySQL的分库分表的传统方法已经过时了，我们提出了一个新的概念——MyNewSQL，它是MySQL和NewSQL的结合。

其实RadonDB就是一个MyNewSQL。它将NewSQL领域常用的算法全部带入MySQL中，从而实现了MyNewSQL。 RadonDB最终的功能与NewSQL基本相同，但它是基于MySQL进行存储，并且表和数据结构可以异构，性能也得到了很大的提升。

正在阅读以上内容对你有帮助吗？如果您想了解更多相关知识或阅读更多相关文章，请关注行业资讯频道。感谢您的支持。