一、分布式数据库的根底外围能力-程度扩容（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