女主宣言上上周收到消息吴炳锡老师和青云QingCloud的邀请，不参加了还没有开源的基于条件MySQL的一款分布式数据库RadonDB的技术交流会。而本人相对于各大公有云厂商底层技术的实现比较比较很有兴趣，所以我对此行技术交流会有一些心得并做了系统的总结。下一步就给大家分享分享组织RadonDB的交流的一些心得。PS：相当丰富的一线技术、多元化的表现形式，尽在“HULK一线技术杂谈”，点关注哦！背景详细介绍在具体一点能介绍RadonDB体验心得以前，我们先来推荐帮一下忙当下DBA在使用悠久的传统MySQL主从或主从+proxy架构模式下依旧修真者的存在的一些棘手问题。基于条件第三方插件（通常MHA）的快速切换与数据一致性保证；单实例海量数据分库分表后的group、sort、limit及join网站查询；分库分片后各实例数据不均及数据增涨后二次word文档合并问题；分库分片后跨实例操作的分布式事物绝对的保证问题。RadonDB架构总体上来讲RadonDB总体优雅的解决了上述事项问题，当然了要明白清楚RadonDB应该怎么处理根据上述规定问题我们得必须所了解下它的整个结构架构。第一眼看到看起来好像除了多出了计算节点（Compute Nodes），雷鸣架构和象的分库分表中间件+MySQL没啥太大的区别。但实际上里面的很多设计细节很值得去爱玩味，具体一点:：SQL节点（SQLNode）SQL节点（SQL Node），共同负责一些如分布式想执行计划和分布式事物总体协调的工作，并且好象的DML操作都具备什么了分布式事物只要，不过DDL是没有可以提供类似于的保障。不过DDL操作象变更手续频率不高，而小概率失败（可自动稍后再试）也的确影响不大业务，DBA在使用上进行控制再试一下。是需要警告的是为了可靠分布式事物Snapshot隔离级别，SQL节点只能三个对外提供写，那些节点可读可写。更最重要的一点是你是什么SQL节点储存了一份表（table）读取分布的位置的元数据，的力量元数据信息是可以很方便的参与后端存储节点的数据迁移你的操作（稍微有点类似mongo的balance功能）。SQL节点互相会相互之间参与通信同样元数据的变化信息，通信协议传说中的rediscluster区分的当前流行的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），这个设计惊奇，以前也设计什么过分布式proxyAtlas，当时始终为高并发可以查询与跨物理节点的复杂查询相生相伴时的性能问题感到头痛惊骇不已。只不过SQL节点会对帮忙SQL进行解析，并决定哪些是急切SQL，然后将填写请求路由至可以计算节点。需要注意的是换算节点存储的是绝大部分StorageNodes集群的全量数据，另外内部通过基于条件binlog订阅-消费模式来对数据进行增量更新。值得一提的事计算出节点采用插件模式，也就意味着计算出节点不肯定会非就算MySQL，也是可以是风险性较低的DB。不过换算节点只不过存储位置的是全量数据，确实当前区分压解存储当然了也有较小的存储空间代价。数据均衡可以介绍完RadonDB整体架构，个人对它的表存储设计和数据均衡全面印象非常深刻。大多的关系型数据库的拆分的或较常见的开源proxy一般也是还没有解决差别分片数据均衡分配的问题，而RadonDB提供了个新的解决思路，表存储策略具体详细见下图：从上图可以清晰的看到在RadonDB里创建战队一个以id才是分片sign的表t1，表t1会系统默认被自动出现切两类32张小表，它们分布均匀的聚集起来在多个存储节点上。各个小表都有一个自己的哈希区间，作用于标志自己所能存储的HASH范围。按照交流发现自己，实际上这种word文档合并借鉴的那就是redisclusterslot的存储分配策略。这样切分的最大好处就是况且三张100GB+的逻辑表，只不过在集群节点的读取会被区域分割成很小的多张表，这相对于程序维护和数据迁移我还是比较优雅的。这一次我们看看RadonDB是该如何并且容量扩展，或则说数据均衡的，具体迁移过程也可以用如下图来只能证明：红色框里可以表示添加一个分片后数据的分布情况，但是RadonDB会按照基于Go语言自研的shifter工具(源码尚未开源，以工具可以提供建议使用)参与并发式全量+增量的不同步的，其实就是为了尽量会减少迁移到的数据量，RadonDB会优先权以小表并且迁走。当然了这里有三个问题要尽量，在迁入之后路由可以切换那一瞬，原表要一个可读可写状态，这期间对于业务而言可能会会有另一个瞬间的小抖动。总结相比较，RadonDB实际可以理解为是另一个中间件，并加强了当前流行的分布式一致性协议（raft）和通信协议（gossip）包括MySQL实现程序的一套分布式解决方案。它可以解决了DBA始终独自面对的关系型数据库分布式事物、分布式模式下数据营养平衡、高可用快速切换、数据一致性及分布式模型下复杂查询性能等一穿越系列问题。当然了在体验过程中也发现一些可以不改进之处的点及实际使用建议。具体一点:：分片快速扩容数据迁移区分的是全量+增量的，是否是也可以相似mongo的那样的然后在分片互相通过数据实时同步而无需dump，这样的实现很有可能会更幽雅些。好象肯定会帮我推荐RadonDB需要vip模式来利用对业务的透明访问，但这对一般中小型企业并没有什么稳定高效的lvs服务但是vip管理又是三个问题，这里见意建议使用服务发现到或配置好不好管理方案如开源的consul或360开源的qconf。部分自建私有云平台很可能而且之后对MySQL5.5或5.6的技术定制高度感情依赖怎么升级到5.7或情报营的8.0难度较高，RadonDB可能是三个非常好的契机也许是可以一试。