RadonDB架构解析

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

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

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

- RadonDB整体架构 -

整体架构

1、RadonDB官网:http://radondb.io

2、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的作用 -

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。

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

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

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

- 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、 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整体非常不错,设计方面,非常独道,属于一个多年开发经验,理解开发中痛点的一个数据库产品,代码也比较精简,觉的也是学习Golang不错的项目。对于理解数据库架构设计也是一不错的东西。新的东西也需要一个完善的过程, 相信官方在RDS产品定位下,也会更快的促进产品改进。期待RadonDB越来越好,也有更多的人一块参与进来。

知数堂准备把RadonDB放置到课堂中做为教学内容中的一部分,也欢迎大家一块来交流RadonDB相使使用经验。

原文发布于微信公众号 - 3306pai(pai3306)

原文发表时间:2018-05-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CDA数据分析师

案例分析:基于消息的分布式架构

美国计算机科学家,LaTex的作者Leslie Lamport说:“分布式系统就是这样一个系统,系统中一个你甚至都不知道的计算机出了故障,却可能导致你自己的计算...

2138
来自专栏Albert陈凯

Apache Spark快速入门

https://www.iteblog.com/archives/1408.html 一、 为什么要选择Apache Spark 当前,我们正处在一个“大数据"...

3646
来自专栏Ceph对象存储方案

实弹军演-基于Ceph对象存储的实战兵法

1 知己知彼,百战不殆 剖析业务IO模型 了解业务基本存储模型: 最高并发多少,最高读写带宽需求。 并发多少决定了在知道单个RGW最大并发数上限的前提下你需要用...

2727
来自专栏大愚Talk

为什么要用Redis

最近阅读了《Redis开发与运维》,非常不错。这里对书中的知识整理一下,方便自己回顾一下Redis的整个体系,来对相关知识点查漏补缺。

892
来自专栏Java帮帮-微信公众号-技术文章全总结

研究微信即时通讯的服务端、朋友圈、红包、推送等方案

即时通信:前端获得消息发送到服务端,服务端处理后通过推送的方式,给到接收方;Android使用长连机制,联通网络长连十几分钟,电信仅五六分钟,因此需要根据测试的...

2753
来自专栏Java Edge

分布式MySQL集群方案

4706
来自专栏JackieZheng

RabbitMQ入门-初识RabbitMQ

初识RabbitMQ 要说RabbitMQ,我们不得不先说下AMQP。AMQP,即Advanced Message Queuing Protocol,高级消息队...

2336
来自专栏架构师之旅

高可用可伸缩架构实用经验谈

 移动互联网、云计算和大数据的成熟和发展,让更多的好想法得以在很短的时间内实现为产品。此时,如果用户需求抓得准,用户数量将很可能获得爆发式增长,而不需要像以往一...

1807
来自专栏美团技术团队

大众点评账号业务高可用进阶之路

1383
来自专栏Golang语言社区

go实现一个简单的游戏服务器框架(lotou)起源

https://github.com/sydnash/lotou 目前代码比较粗糙,欢迎各种改进建议。 最近一直想学习一些关于游戏服务器的知识,显示看了一下云...

29012

扫码关注云+社区