开源分布式图数据库有哪些(最牛的分布式数据库)

很多新手对开源分布式数据库RadonDB的核心技术和实现不是很清楚。为了帮助大家解决这个问题，下面小编就详细讲解一下。需要的人可以从中学习，希望你能有所收获。

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

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

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

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

下面一层是Xenon，一个高可用的MySQL管理工具。在这一层的每个虚线框里，都有一个“主”和两个“从”MySQL，由Xenon管理。氙实际上是一种分散的管理工具。当主节点挂机时，它会使用Raft协议选择主节点，然后根据MySQL Binlog机制同步数据，这样新的主节点就可以继续为外界服务。

先说说RadonDB的一些技术细节。RadonDB的主要功能是为用户SQL生成分布式计划，并并行执行执行器。在执行器被分配到存储层后，执行二次操作，如排序依据、限制和分组依据。

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

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

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

生成分布式执行计划后，运行Insert executor文件并将其分发到相应的节点上执行。

以上是RadonDB中氡层的基本工作机理。

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

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

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进行存储，表、数据结构都可以是异构的，性能上也有很大的提升。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注行业资讯频道，感谢您对的支持。