1. 简介
RadonDB是一款基于MySQL研发的新一代分布式关系型数据库(MyNewSQL)。
向用户提供具备⾦融级高可用、强一致、超大容量的数据库服务，高度兼容MySQL语法，自动⽔平分表，智能化扩容。
2. RadonDB 的 优 势
(1):自动⽔平分表，一键即可开启智能化扩容，扩容过程业务不中断。
(2)数据多副本并可跨数据中⼼部署，率先使用GTID并行复制+Raft一致性协议确保副本间数据强一致、零丢失主副本故障自动秒级切换，实现自动化运维，无需⼈⼯干预。
(3)存储副本使用MySQL(5.7.19)存储，稳定可靠的存储能力与强大的计算能力并存。
(4)提供分布式事务能力，保证跨节点操作的数据一致性。
(5)同时支持OLTP(高并发事务需求)和OLAP(复杂分析需求)。
(6)高度兼容MySQL语法，数据可快速导⼊、导出，简单易用。
3. 架构
RadonDB由SQL节点(Distributed SQL Nodes)和存储节点(Storage Nodes)以及计算节点(Compute Nodes)三大部分组成。
整体架构如下：
3.1 SQL节点
SQL节点主要负责:
(1)生成分布式执行计划(Distributed Plan)
(2)生成分布式执行器(Distributed Executor)且并行式执行
(3)协调分布式事务
对于用户的每一个query，到达一个SQL节点后，处理流程如下：
SQL节点是无状态的，但是为了保证事务的Snapshot Isolation隔离性，目前是一写多读模式。
3.2 存储节点
RadonDB整个存储层由多个存储节点组成。
每个存储节点默认是由一主两从(三副本)的高可用MySQL集群组成，负责分区数据的存储与计算。
3.2.1 副本基MySQL存储
为什么选择MySQL进行副本存储呢?
我们的考量是:
(1): MySQL稳定可靠、多索引写原子保证
(2):储存可以异构化，InnoDB/TokuDB多引擎可选
(3): 尽量把计算下推给MySQL，充分发挥数据就近(Data Locality)优势，以减少存储层与SQL层数据传输
(4)：MySQL 8.0即将推出，功能更加强大
3.2.2副本高可用，强一致
为了保证节点内副本的高可用，我们把MySQL GTID并行复制技术与分布式一致性协议Raft完美结合，在主副本故障后自动秒级切换并瞬间可用，并确保切换后数据零丢失。
在RadonDB里，我们把GTID(Global Transaction Identifier)作为Raft协议的log index，结合MySQL的Multi-Threaded Slave (MTS)，可以做到log entry的并行复制、并行回放，log重放时间异常短暂，故障切换后即刻对外服务。
同时，RadonDB使用强Semi-Sync-Replication技术确保至少一个从副本与主副本在数据上是完全同步的，当主副本故障后，数据完全同步的从副本将被选为新的主副本，这样就确保了数据零丢失，并实现了高可用。
比如，某个存储节点的三副本状态为:
这样当Master(主副本)不可服务的时候，Slave1(从副本)将被选为新主，Slave2自动’CHANGE MASTER TO’到新主Slave1并根据GTID(4和5)进行数据同步，切换后状态为:
当某个副本不可用被判定为损坏时，RadonDB则开启流式重建(streaming-rebuildme)机制，对该副本进行快速重建，以保证足够多的副本可用。
3.3 数据分布
RadonDB对数据的划分最小单元是一个“小表”。
划分策略为(默认):
(1):整张表共 4096 slots
(2):每个小表 128 slots
这里的4096和128均可配置，默认可支持单表最大4PB的容量(假设物理盘最大1TB)。
如果我们在RadonDB里创建一个表t1，数据分布情况为:
可以看到，表t1被划分成32个小表，它们均匀的分散在多个存储节点上。
每个小表都有一个自⼰的哈希区间，用于标识自⼰所能存储的HASH范围。
3.4 动态扩容
为了减少扩容数据迁移量，RadonDB优先以⼩表为单位进行迁移。
RadonDB定期的采集存储节点资源使用情况(CPU/Disk/表热度等)，在扩容的时候会优先选择这些空间紧张且热度较高的⼩表为迁移对象，使得整体资源分配达到最优。
扩容时，⾸先进行全量迁移(并发式)，然后根据全量时的位点进行增量同步，如果业务写⼊较大，数据差异量一直呈加大趋势，RadonDB会启动动态限流机制以加快增量迁移。
迁移完毕，RadonDB会对表数据并发式做Checksum校验，严格保证迁移前后数据的正确性，根据我们的测试(RDB虚机环境)，Checksum速率可以达到300MB/s，所以对这些小表来说还是非常快的。
添加新存储节点后数据分布情况:
3.5 分布式事务
为什么需要分布式事务能力呢?
我们通过一个例子来说明分布式事务的重要性，比如用户执行了一个区间update操作:
Distributed Executor在不同存储节点执行情况为:
这里，node2的执行器执行失败，其他2个执行成功，如果没有分布式事务保证，整个表其实是处于一种不一致、甚⾄数据不可用状态。
RadonDB提供了分布式事务能力，node1和node3的操作将被回滚(ROLLBACK)，这样就保证了跨节点操作原子性，使数据库处于一个一致性状态。
3.6数据一致性
那么，RadonDB支持什么级别的一致性呢?
我们先来看一个场景，对于2个不同的client操作，一个为区间读，一个为区间更新，比如：
假设表t1.a初始值全部为0，如果没有分布式事务保证, client1的查询结果集可能是:
因为client1的查询读到了client2的更新数据(部分)。
在RadonDB里，这种情况是不存在的，client1的返回结果集有2种。
全 部 为1
这种情况发生在client2-update完成后client1-select再执行:
全 部 为0
client1-select的开始(START)在client2-update完成(COMMIT)之前：
RadonDB在一致性上做到了SI(Snapshot Isolation)级别，只要某个分布式事务没有commit，或部分区已经commit，那么它的操作对其他事务都是不可见的。
我们使用go-jepsen进行SI测试，经过100多亿次操作并检测，并在检测期间随机kill存储节点主副本，均未发现问题。
go-jepsen是一个验证SI隔离级别的工具，它的原理比较容易理解:
1个线程不停的更新(update)整张表，16个读线程不停的扫表(scan)，然后对读到的数据进行等值校验，如果这批数据有差异，说明读到了update的脏数据，是不满足SI的。
4. 复杂查询
对于跨节点join等复杂查询(偏OLAP查询)，如果放到SQL层实现，这样的问题有:
(1)：SQL层与存储层网络传输较大，因为数据要在SQL层进行计算和过滤，导致性能低下或不可用复杂查询会抢占OLTP资源，互相干扰而造成抖动
(2):出于以上考虑，RadonDB对于复杂的OLAP类查询，SQL层会自动路由到单独的计算节点进行计算并返回，OLAP和OLTP资源完全隔离，互不影响，用户在使用时无感知。
这样的缺点是数据需要2份，目前通过高压缩解决。
5. 性能
5.1 硬件环境:
5.2 测试模型
sysbench: 16表, 512线程，随机写，5000万条数据
5.3 测试结果
可以看到RadonDB的延迟是单机MySQL的1/3，但性能几乎是单机的3倍，这要得益于RadonDB对大表进行切分后，用户的写操作在这些⼩表上可并发式执行。
6.数据导⼊和导出
RadonDB目前只支持go-mydumper⽅式的数据导⼊和导出。
XeLabs/go-mydumper使用go语⾔开发，与maxbube/mydumper格式完全兼容，但是对并行进行了优化，性能更加卓越。
导⼊数据到RadonDB，go-mydumper会批量并行式导⼊，⾮常快捷。
从RadonDB导出数据时，go-mydumper会批量并行流式导出，资源占用率较低。
6.1 安 装go-mydumper
6.2.如何导⼊数据到RadonDB
6.2.1 从数据源导出数据
⾸先使用mydumper从别的MySQL数据源导出数据，比如:
6.2.2 修改schema
在导出目录(比如sbtest.sql)里找到*-schema.sql(比如sbtest.benchyou0-scehma.sql):
对原语句最后增加’PARTITION BY HASH(分区键)’的语法:
sbtest.benchyou0-schema.sql:
修改为(这里是以id为分区键):
6.2.3导⼊数据到RadonDB
6.4如何导RadonDB数据
可以使用mydumper导出RadonDB数据，此过程是流式获取(select语句加’/*backup*/’ hint)并导出，基本不占用系统内存。
7. 总结
RadonDB是一个基于MySQL而实现的高可用、强一致的分布式数据库。
RadonDB具备双层计算能力，SQL节点提供基本的计算能力(结果集的⼆次运算)，而存储层由于使用MySQL则具备强大的存储计算能力。
对于用户的每一个query，RadonDB都尽可能的把计算下推，让存储层MySQL过滤掉更多的数据，以减少SQL层和存储层之间的网络传输，充分利用data locality优势，发挥最佳性能。
我们认为基于MySQL的分布式数据库(MyNewSQL)远未到头，RadonDB只是一个开始。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
