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有优秀的地方，大致总结以下几点：
-
自动分库分表，透明扩容。
- 在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方式上后，实现访问路由变更。
-
对SQL执行没有限制
- 带有分区Key的查询，可以路由的相应的存储节点计算
- 不带分区key的会路由到所有存储节点计算，然后在radon中合并
- 对于有条件及含聚集函数的查询大多还是在存储节点运算后在Radon上合并返回结果，这块需要进一步分析一下执行情况。
- 对于join，子查询等复杂类的SQL需要计算节点支持，在计算节点运算后返回给前端。
-
自带高可用套件： 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相使使用经验。 欢迎加知数堂-王者侠谷中交流：
