RadonDB架构解析

RadonDB在DTCC大会主会场宣布开源了, 一个期待已久的产品终于走进了开源社区。 感谢青云领导层的对技术贡献的情怀。

做为一个MySQL从业人员,从我对RadonDB关注到使用,将近有半年多时间,这次RadonDB开源,基本也全程参与,在这里开源计划到最终在DTCC展现,也深深感受为开源,公司也需要付出很多很多。

这里了为了能快速的让大家了解RadonDB,我这里对RadonDB架构做一个简单的梳理,本着更容易大家理的态度不夸大,更利于接近于实质, 同时也方便大家深入去学习RadonDB。

RadonDB整体架构

RadonDB官网: http://radondb.io

RadonDB基于Golang开发,由四部分组成:

  •    Radon SQL 路由层 ,Proxy模式  下载地址: https://github.com/radondb/radon
  •    Xenon  MySQL Plus高可用组件 下载地址: https://github.com/radondb/xenon
  •    存储节点 ,官方MySQL或是Percona分支,推荐一主两从,增强半同步
  •    计算节点  ,目前使用的TokuDB做为全量数据存储,推荐优化后的分支: https://github.com/xelabs/tokudb

 

Radon作用:

  •    SQL解析及路由,混合OLTP和OLAP
  •    分布式事务支持
  •    用户验证, 在Radon中验证,不需要MySQL端创建
  •    连接池功能
  •    SQL审计日志记录(默认没开启,开启后会记录全量的请求,用于审计使用)
  •    记录全量SQL的binlog,用于计算节点数据实时复制
  •    原生集群支持,配置在节点间自动同步

Xenon(MySQL Plus)作用:

MySQL的高可用组件,这个也是我一直觉的增加半同步出现后,是MHA的一个最佳替换产品。 还有很多好玩的功能可以去在上面扩展,主要功能如下

  •   MySQL高可用选主
    • 基于Raft(依赖于GTID)选主
    • 数据一致性依赖于增强半同步(semi-sync)
  • 故障切换动作
    • 借助于配置中leader-start-command  & leader-stop-command  调用相应的脚本完成
    • 这一块也可以自已扩展,结合Consul,ZK来玩
  • MySQL故障后切为从节点后,自动拉起并修复制关系,也可以自动重建(需要配置)
  • 集成Xtrabackup备份调度实现

MySQL存储节点:

利用MySQL的增强半同步构建,一主两从。

主要用于存储数据中的某个分片,有点类似于Redis Cluster结构中的一个主从分组。 官方使用三个节点,为了高可用,推荐至少两个节点。 实验环境,也可以使用一个节点(在单节点结构下MySQL Plus不是必须的)

计算节点:

目前利用作者优化过的TokuDB版本存储分库分表后的全量数据,这样复杂的SQL请求可以转到该节点上运行,官方目前该节点配置是三个,也可以是1-2个, 如果复制SQL比较多,这个地方需要增多一点,实现多个从节点上的SQL运算。 官方反馈,这个地方也需在找新的技术替代,如: Greenplum或是ClickHouse,也可能是MariaDB的ColumnDB。

该节点要担任:SQL中无分区Key的查询,join查询等复杂类的操作。 该节点数据主要靠Radon给多写实现。 如果没这部分操作,可以不要计算节点。不过,推荐放置,这样相当于有一个地方有一个全量数据。对数据安全也是一个增强。

同样该节点也可以后续加入,通过https://github.com/xelabs/go-mydumper 全集群某个分片全量迁移,然后在结合Radon记录的GTID信息实现增量同步。

计算节点可以说是RadonDB中的一个亮点,借助于Radon实现了一个全量数据维护,这复杂的查询或是统计的分析都可以到计算机节点实现,这个地方如果将来换成一个OLAP类的数据库,就更回完美。

借用官方的架构图供大家在看一下:

 

RadonDB优点

大致对整个结构有一个了解后,我们再看看几个实质的问题,RadonDB有优秀的地方,大致总结以下几点:

  1.  自动分库分表,透明扩容。

    • 在RadonDB中目前只支持Hash拆分,默认把一个表分成: 4096个slot,实际分配到多个子表中,例如青云产品中配置成32个子表,那么每个子表对应128个Solt(4096/32)。 例如创建一张表:
    • create table zst_user(id int not null, wubx varchar(32))   partition by hash(id)
    • 如果有一个MySQL存储分片,会在这个存储分片上建出来32张实际的表,每个表对应id Hash后的128个Slot
    • 诱明扩容
      • 在RadonDB,可以配置当一个表增长超过多大时,当集群中添加节新的存储节点时,会动态进行数据迁移,默认配置单表超过1G,这个步骤迁移是通过利用go-mydumper导出,记录Radon上该节点的GTID,然后到目标节点导入,再通过Radon上补Binlog方式上后,实现访问路由变更。
  2.  对SQL执行没有限制

    • 带有分区Key的查询,可以路由的相应的存储节点计算
    • 不带分区key的会路由到所有存储节点计算,然后在radon中合并
    • 对于有条件及含聚集函数的查询大多还是在存储节点运算后在Radon上合并返回结果,这块需要进一步分析一下执行情况。
    • 对于join,子查询等复杂类的SQL需要计算节点支持,在计算节点运算后返回给前端。
  3.  自带高可用套件: Xenon (MySQL Plus)

    • 支持MySQL节点上故障快速切换及利用API指令把节点重建(调用的xtrabackup)
    • 在数据一致性,安全性方面,还是依赖于MySQL的增强半同步,所以也推荐三个节点。

RadonDB不足之处:

RadonDB 现在可以说刚出江湖,核心代码1万行左右, 学习Golang的同学不要错过。 加上其它类库引入。 Radon代码11万+, Xenon代码5万行+ 整体来说还是一个轻量级结构。

目前还有一些不足及改进的地方:

1.  Radon 这个Proxy模型中, 目前默认提供单节点读写,支持读IP,业务层需要自已处理读写分离。 这样实质的业务压力还是在Proxy这一层(能不能抗住业务,需要亲测一下),需要考虑多节点同时提供读写能力。(这个其实现在Proxy模型都号称支持多节点同时读写,但对于数据一致性要求强的环境差不多都会出问题)。 这块官方为了金融环境,还是比较保守,实质上多个Radon可以成为无状态对外提共服务,更新冲突,可以让数据库自已来处理。 多个Proxy也相当于更多的连接, 这块实际测试中,可以考虑让多个Radon都对外服务,提高Radon的利用率。

2. Xenon(MySQL Plus)相对独立,没有和Radon有更多的交互, 这个是一个亮点,Xenon后续也可以用到不同的分布式结构下面。但做为产品中的一个组件,还是需要考虑和Radon有更多的交互,如:复制延迟情况, MySQL节点故障后,新选举出来的主,可以同步给Radon,把现有的VIP方案去掉。  这种分离的结构,也给了我们使用者更多灵活的空间,例如结构Consul来玩。感觉有利有弊,有很大的优空间。非常看好Xenon(MySQL Plus),绝对的一个高可用的利器。

3. 某些方面还有待提高,例如计算节点添加, 借助于Radon的Binlog实现,这一块也可以借助于官方的复制实现。需要进一步讨论。 这块可以通过后续DBA的运维手段改善。全量数据维护这块, 也是后续中维护的一个难点,需要提前规划好。

4. 集群中现在成员资源使用绝对不饱合,估计使用在30%以下。 Radon目前单节点提供服务,存储节点,也可只有从节点提供服务。  这块也是金融级高可用的通命,特别是两地三中心架构中,更加浪费。

总的感受

RadonDB  整体非常不错,设计方面,非常独道,属于一个多年开发经验,理解开发中痛点的一个数据库产品MyNewSQL,代码也比较精简,觉的也是学习Golang不错的项目。对于理解数据库架构设计也是一不错的东西。知数堂准备把RadonDB放置到课堂中做为教学内部中的一部分。也欢迎大家一块来交流RadonDB相使使用经验。 欢迎加知数堂-王者侠谷中交流: