一款可能解放DBA的分布式数据库RadonDB的体验之旅

背景介绍

在详细介绍 RadonDB 体验心得之前，我们先来介绍一下当下 DBA 在使用传统 MySQL 主从或主从+proxy 架构模式下依然存在的一些棘手问题。

1.基于第三方插件（通常 MHA）的快速切换与数据一致性保证；

2.单实例海量数据分库分表后的 group、sort、limit 及 join 查询；

3.分库分片后各实例数据不均及数据增长后二次拆分问题；

4.分库分片后跨实例操作的分布式事物保证问题。

RadonDB 架构

总体上来说 RadonDB 相对优雅的解决了上述问题，不过要清楚知道 RadonDB 如何处理上述问题我们得首先了解一下它的整体架构。

第一眼看上去除了多出了计算节点（Compute Nodes），整个架构和一般的分库分表中间件+MySQL 没什么太大的区别。但实际上里面的很多设计细节很值得玩味，具体如下：

SQL 节点（SQL Node）

SQL 节点（SQL Node），负责一些如分布式执行计划和分布式事物协调的工作，因此一般的 DML 操作都具备了分布式事物保证，不过 DDL 没有提供类似的保障。

当然 DDL 操作一般变更频率不高，同时小概率失败（可手动重试）也并不影响业务，DBA 在使用上进行控制即可。需要提醒的是为了保障分布式事物 Snapshot 隔离级别，SQL 节点只有一个对外提供写，其他节点只读。

更重要的一点是每个 SQL 节点存储了一份表（table）存储分布的元数据，借助元数据信息可以很方便的进行后端存储节点的数据迁移操作（有点类似 mongo 的 balance 功能）。SQL 节点之间会相互进行通信交换元数据的变化信息，通信协议类似于 redis cluster 采用的当前流行的 gossip 协议。

存储节点（Storage Nodes）

存储节点（Storage Nodes），实际上直接使用的是 MySQL5.7（其实也兼容 5.6+GTID）的默认三个节点的 N 组（N>=1）主从集群结构。不过这里引入了与 mongo 类似的 raft(分布式一致性协议)协议来进行自动高可用切换。RadonDB 的 raft 协议实现主要是基于 GTID 日志，因此 RadonDB 要求必须开启 GTID 复制模式，同时为了提供金融场景下的数据强一致性保障，RadonDB 要求采用强 semi-sync+永不超时机制。在实际的使用中 DBA 自己可以依据不同的场景进行不同的配置。

计算节点（Compute Nodes）

计算节点（Compute Nodes），这个设计让人眼前一亮，之前也设计过分布式 proxy Atlas，当时一直为高并发查询与跨物理节点的复杂查询并存时的性能问题头疼不已。实际上 SQL 节点会对请求 SQL 进行解析，并决定哪些是复杂 SQL，然后将对应请求路由至计算节点。

需要注意的是计算节点存储的是所有 Storage Nodes 集群的全量数据，并且内部通过基于 binlog 订阅-消费模式来对数据进行增量更新。值得一提的是计算节点采用插件模式，也就意味着计算节点不一定非要是 MySQL，也可以是其他类型的 DB。当然计算节点因为存储的是全量数据，虽然当前采用压缩存储不过也有较大的存储空间代价。

数据均衡

介绍完 RadonDB 整体架构，个人对它的表存储设计和数据均衡印象深刻。通常的关系型数据库的拆分或者常见的开源 proxy 一般都是没有解决不同分片数据均衡的问题，而 RadonDB 提供了一个新的解决思路，表存储策略具体见下图：

从上图可以看到在 RadonDB 里创建一个以 id 作为分片 key 的表 t1，表 t1 会默认被自动切分为 32 张小表，它们均匀的分散在多个存储节点上。每个小表都有一个自己的哈希区间，用于标识自己所能存储的 HASH 范围。通过交流发现，实际上这种拆分方式借鉴的就是 redis cluster slot 的存储分配策略。这样切分的最大好处就是即使一张 100GB+的逻辑表，实际上在集群节点的存储会被切分成很小的多张表，这对于维护和数据迁移还是比较优雅的。

接下来我们看一下 RadonDB 是如何进行扩容，或者说数据均衡的，具体迁移过程也可以用如下图来说明：

绿色框里表示添加一个分片后数据的分布情况，实际上 RadonDB 会通过基于 Go 语言自研的 shifter 工具(源码尚未开源，以工具方式提供使用)进行并发式全量+增量的同步，当然为了尽量减少迁移的数据量，RadonDB 会优先以小表进行迁移。不过这里有一个问题需要注意，在迁移最后路由切换那一刻，原表需要一个只读状态，这期间对于业务来说可能会有一个瞬间的小抖动。

总结

总体来说，RadonDB 实际可以理解为是一个中间件，并结合了当前流行的分布式一致性协议（raft）和通信协议（gossip）以及 MySQL 实现的一套分布式解决方案。

它解决了 DBA 一直面临的关系型数据库分布式事物、分布式模式下数据均衡、高可用切换、数据一致性及分布式模型下复杂查询性能等一系列问题。

不过在体验过程中也发现一些可以改进的点及实际使用建议。具体如下：

1.分片扩容数据迁移采用的是全量+增量的方式，是否可以类似 mongo 的那样直接在分片之间进行数据同步而无需 dump，这样的实现可能会更优雅些。

2.一般可能会推荐 RadonDB 采用 vip 模式来实现对业务的透明访问，不过对于一般中小型企业并没有稳定可靠的 lvs 服务并且 vip 管理也是一个问题，这里建议使用服务发现或配置管理方案如开源的 consul 或 360 开源的 qconf。

3.部分自建私有云平台可能因为之前对 MySQL 5.5 或 5.6 的技术定制高度依赖升级到 5.7 或后续的 8.0 难度较高，RadonDB 可能是一个很好的契机或许可以一试。

据内部消息，RadonDB 预计在 5 月中旬开源，希望即将开源的 RadonDB 能给大家在 MySQL 运维上带来不一样的体验，敬请期待吧~

本文转载自公众号贝壳产品技术（ID：gh_9afeb423f390）。

原文链接：

https://mp.weixin.qq.com/s/6xadsP03GnuzpY8I1KS-NQ