共计 4541 个字符，预计需要花费 12 分钟才能阅读完成。
一、分布式数据库的根底外围能力 - 程度扩容（ScaleOut）
数据库系统架构的演变，如实的反映了信息社会一直倒退所带来的数据处理规模一直变大这一根本事实。
现在，分布式数据库产品已成为各行各业信息系统的存储服务中，利用越来越宽泛的技术选型。究其原因，是因为其在海量数据存储管理的扩大能力和性价比方面，较单机数据库有着压倒性的劣势。
在咱们对昆仑分布式数据库的扩容性能正式开始介绍之前，咱们首先回顾一下数据库管理系统扩容的常见模式。
数据库的扩容大体上分为如下两种模式：垂直扩容（Vertically Scale Up），程度扩容（Horizontally Scale Up）。
- Vertically Scale Up
垂直扩容是指对物理资源，如存储容量、计算能力、网络带宽等资源的扩大。
这种扩容形式由单机物力资源的瓶颈触发，以裁减单机物理资源为解决方案，满足数据库系统对物力资源的需要。然而这种扩容形式的毛病也是不言而喻的：单机物理资源总有下限，且个别价格十分低廉。
- Horizontally Scale Up
程度扩容的基本思路是将数据依照肯定的规定散布在不同的物理设施上，整个零碎对外依然出现逻辑上的繁多数据库服务。
零碎的扩大形式以通过减少物理设施的个数，来晋升数据库的整体对外服务能力。这种扩大模式，能够说在实践上实现了有限扩大。
其中，如果扩大的物理节点，蕴含了存储能力，则称为 share-nothing 架构，否则称为 share-storage 架构。
咱们熟知的 oracle-RAC 就是典型的 share-storage 架构，所有计算节点共用一套存储服务，而昆仑分布式数据库是典型的 share-nothing 架构。
如果从物理设施扩大引发的读写抵触的角度来扫视这两种架构的优劣的话，share-nothing 架构下，数据分片存储在多个存储集群中，分片之间没有交加，因此不会产生多点写入抵触的问题，因而线性扩大能力绝对于 share-storage 有劣势，但分布式事务处理和分布式查询处理性能以及主动的、利用无感知的程度弹性扩容等外围性能是在这种架构下必须要实现的性能，只有具备了所有这些性能，才是真正的分布式数据库系统。
这也是为什么分库分表中间件和应用层分库分表曾经不再适宜以后的技术水平要求—这些技术计划没有上述性能，会给利用开发者和 DBA 带来惨重的累赘和工作量，相当于要在利用代码中 case by case 实现分布式数据库系统的分布式事务处理和分布式查询处理性能，以及 DBA 手动停服实现扩容，这些惨重的累赘给利用零碎的稳定性可靠性带来微小的危险，并且验证影响客户业务发展和终端用户体验。
昆仑分布式数据库在架构选型时，就充分考虑到了上述的种种问题。基于咱们本身对分布式事务处理和分布式查询处理性能以及主动程度扩容的等分布式数据库外围性能的丰盛的设计和实现教训以及对相干用户需要的深刻理解，以及对线性扩展性的极致谋求，咱们在昆仑分布式数据库中实现了基于 share-nothing 架构的业务无感知的程度弹性扩容机制，更好地满足业务快速增长对数据库系统的服务要求。
二、昆仑分布式数据库 ScaleOut 性能介绍
2.1 存储层程度扩容
昆仑分布式数据库的存储服务逻辑上由多个独立的 MySQL 集群组成，每个集群称为一个 shard。
每个 shard 是昆仑分布式数据库存储层的独立的容灾服务单元，不同 shard 之间数据互相独立。因而存储层的扩容，咱们只须要减少 shard 这一独立的容灾存储单元即可。
在实现新的 shard 退出集群后，另一个更重要的须要解决的问题是如何将数据从原有的 shard 中迁徙到新的 shard 中，从而对数据读写的申请和数据存储的负载，实现存储层整体服务能力的晋升。
昆仑分布式数据库基于上述的业务要求，实现了无锁的数据 shuffle（搬迁）服务，在实现热数据无效摊派的根底上，牢靠的保障了存储服务的连续性，并且对利用零碎无感知无侵入。该搬迁服务既能够用于扩容也能够用于缩容。比方为了双十一促销须要长期减少几倍的计算和存储能力，促销完结后开释相干计算和存储资源并还给私有云平台。
- lock-free shuffle service
在抉择迁徙哪些数据上，昆仑分布式数据库会依据某些规定选定须要搬迁的表分片（后续撰文介绍），给出待迁徙表的汇合。其目标是为了可能辨认出真正的热点数据，从而更加平衡实现流量摊派以及更加高效的分布式查问。同时在数据 shuffle 的流程设计上，咱们也做了无锁化解决，确保一个表在被搬迁的整个过程中继续的可读可写，达到了业务零感知。
整个 shuffle 过程包含以下几个步骤。假如以后给出的 shuffle-set(待迁徙的库表) 是从 shard2 迁徙到新 shard 上。
第一步：须要实现的就是 shuffle-set 的 dump 和 load 操作。
在 dump 阶段，会保留一个 snapshot 的点位，即后续开始 binlog 复制的起始地位。整个 dump 的过程不会阻塞业务的申请。dump 实现后，会并行的将 dump 的数据文件，load 到新的 shard 中。
在 dump 和 load 的过程中，昆仑分布式数据库的集群管控模块 cluster_mgr 和节点管控模块 node_mgr 会协同工作，实现 shuffle-set 中表的数据搬迁工作。
如上图所示整个过程会划分为三个子工作下发到对应的 node_mgr 上：
- Dump_task
Cluster_mgr 下发 dump 工作到 shard2 的备机上，对应的 node_mgr 应用 mydumper 工具开始并发执行 dump 工作，待实现工作后，向 cluster_mgr 应答工作实现。
- Transfer_task
第一阶段的 dump 工作实现后，cluster_mgr 会向 shard-new 主机上的 node_mgr 下发 transfer_task 的命令，由 shard-new 向 shard2 拉取对应的 dump 文件。download 实现后，shard-new 上的 node_mgr 向 cluster_mgr 应答工作实现。
- Load_task
在实现了 transfer_task 后，cluster_mgr 开始向 shard_new 下发 load_task，工作的执行过程中，node_mgr 应用 myloader 工具，并发的向 shard-new 中 load 数据，实现后向 cluster_mgr 应答工作胜利。
第二步：会建设新 shard 与源 shard 之间的数据同步，将源 shard 上从 snapshot 点开始到以后工夫 shuffle-set 的数据变动全副 apply 到新的 shard 上。
数据同步链路的建设，利用 MySQL 原生的基于 binlog 的同步机制，通过建设一个只蕴含 shuffle-set 同步表的长期同步通道，并利用 dump snapshot 作为同步的起始点，拉取数据的增量志，并且以并发的形式在 shard-new 上重放这些日志，直到整个同步提早在预约的工夫范畴内（默认 3 秒），之后开始进行表切换操作。
表切换操作，会在源 shard 上对表进行 rename，切断业务的新的申请。随后如果计算节点拜访该表会发现表不存在，计算节点会从本人的元数据中找到表的新地位，该新地位由 cluster_mgr 在后续步骤更新。
实现 shard2 上的 rename 操作后，会在 shard-new 上确认 rename 操作曾经 replay，之后整个数据同步 channel 会被切断。假如表 A 在 shuffle-set 中，那么此刻，shard- 2 上蕴含一个表 A -renamed，同时，shard-new 上也蕴含一个完全相同的表 A -renamed。
第三步：告诉所有的计算节点 shuffle-set 表的路由更新。shuffle-set 表正式对外服务。
当数据同步的提早在一个正当的小的范畴内的时候，此时会在源 shard 上对表进行 rename 操作，切断业务的新的申请。实现 rename 操作后，整个数据同步链路会被切断。假如表 A 在 shuffle-set 中，那么此刻，shard- 2 上蕴含一个表 A -renamed，同时，shard-new 上也蕴含一个齐全想同的表 A -renamed(rename 操作也会由源 shard 同步到指标 shard)。
2.2 计算层程度扩容
昆仑分布式数据库的计算节点采纳无状态服务设计，所有的计算节点不在本地长久化任何与集群相干的数据。
因而，在计算能力扩容的设计和实现上，昆仑分布式数据库有着人造的劣势，即疾速的部署计算节点服务到集群中，计算节点服务在拉起后，会主动的从元数据集群中同步相干信息，包含路由信息，存储节点相干信息等。
因为所有的元数据处理都是内存操作，因而计算节点从扩容开始到对外服务的工夫窗口十分的短暂，能够实现麻利的计算能力的横向扩大。
2.3 容错与回滚机制
从下面的扩容流程咱们能够看到，整个过程蕴含了多个子工作的，且波及到了多个物理设施，因而强壮的容错和回滚设计是保证系统高可用的必然要求。
联合上述扩容流程设计，在不同的阶段产生故障的解决形式如下：
- dump 文件失败
如果 dump 文件失败，则能够进行重试（重试次数默认 3 次，可配置）。
- Transfer 文件失败
如果 dump 的数据文件在物理设施间的传输失败，则能够重试（重试次数默认 3 次，可配置）。
- load 数据失败
如果 load 操作失败，则能够重试（重试次数默认 3 次，可配置）。
- Table catch up 失败
Table catch up 即建设新 shard 与源 shard 的对于 shuffle-set 的数据同步通路，重放增量数据改变日志的过程，如果该过程失败，则须要返回错误信息以供剖析。之后终止流程，并清理新实例上的 shuffle-set 相干数据。
- 表切换失败
进入表切换流程后，原则上在没有产生如网络隔离，物理设施掉电等劫难状况下，表切换必须胜利。因而在实现机制上，咱们在源 shard 上执行 rename 操作前，会强行终止持锁的会话确保 rename 不会因为锁竞争而失败。
从实现源 shard 的 rename 操作后 3 秒内，如果此时在 shard-new 上，的确没有实现 rename 的 replay（如呈现上述的物理劫难），则须要终止流程，疾速的复原源实例上的曾经被 rename 的蕴含在 shuffle-set 中的表，复原对外服务。
三、布局与瞻望
随着昆仑分布式数据库版本的一直迭代和倒退，对于程度扩容能力的建设会逐步趋于精细化和智能化，目前相干的个性打算笼罩了如 shuffle-set 的抉择，shuffle 流程的优化提效等。
具体如下：
- 更加无效的 shuffle-set 构建算法
shuffle-set 的构建，一方面是为了更好的扩大热点 shard，晋升整个数据库服务的热点数据管控服务能力，另一方面，灵便无效的 shuffle-set 也是分布式查问优化得以高效执行的重要伎俩。因而在后续版本的迭代上，这部分能力也将是咱们重点关注的。
- shuffle 流程的优化
疾速高效的 shuffle 有助于数据库整体效力的晋升，后续版本会重点关注 shuffle 的效率，如尝试实现流水线式的数据 shuffle 策略等。
KunlunDB 我的项目已开源
【GitHub：】
https://github.com/zettadb
【Gitee：】
https://gitee.com/zettadb
END
