共计 1744 个字符，预计需要花费 5 分钟才能阅读完成。
一、前言
昆仑分布式数据库集群（下文简称昆仑数据库）是一个分布式关系数据库管理系统，面向 TB 和 PB 级别海量数据处理，以高吞吐量和低延时解决海量数据高并发读写申请。
它提供强壮的事务 ACID 保障，高效易用的分布式查询处理，高可扩展性，高可用性和通明的分库分表数据处理性能，业务层和终端用户无感知的程度扩大能力，是典型的 NewSQL 分布式数据库系统。应用软件开发者依照应用单节点关系数据库雷同的办法应用昆仑数据库，就能够失去所有上述 NewSQL 数据库的长处，齐全不须要思考数据的分区形式等存储细节。
这样，利用开发者就能够十分疾速的开发强壮牢靠的，高可用和高可扩大的信息系统，来解决 PB 级海量数据。所有的海量数据管理的挑战和艰难都由昆仑零碎来解决，从而大大降低了开发分布式系统的工夫老本和资金老本和技术难度，并且全面晋升其产品质量，大大放慢利用开发和变更过程中的上线进度。
二、架构
昆仑分布式数据库架构图解
一个昆仑数据库集群有 3 类组件形成：一个或者多个计算节点，一个或者多个存储 shard 以及一个元数据集群。
2.1 计算节点
本软件是昆仑数据库的计算节点，基于 PostgreSQL-11.5 开发。为了实现主动的 DDL 同步及复制以及分布式事务，分布式查询处理等高级性能，咱们大量地批改了 PostgreSQL 源代码，而不是间接应用其 FDW 接口。咱们的代码放弃了很好的模块化，不便未来能够持续追随 PostgreSQL 版本更新。
kunlun-storage 是昆仑数据库的存储节点，它是咱们基于 percona-server-8.0 深度优化开发的 MySQL 分支。用户必须应用 kunlun-storage 软件组建昆仑数据库的存储集群和元数据集群，因为昆仑数据库集群须要的要害性能只存在于 kunlun-storage 中，并且它还蕴含了社区版 MySQL-8.0 XA 事务处理的所有容灾缺点的修复；最初，kunlun-storage 在 XA 事务处理方面比社区版 mysql 有大幅性能优化。计算节点应用 PostgreSQL 协定（后续会反对 MySQL 客户端协定）接管和验证用户的连贯申请，验证通过后，就接管和解决连贯上发来的查问并返回后果给客户端。
2.2 存储 shard
用户能够依据工作负载来增减计算节点，每个计算节点彼此平等和独立，没有依赖关系，都能够解决用户连贯和读写申请。计算节点含有每个数据表以及其余数据库对象的元数据，然而用户数据存储在存储 shard 中。
执行一个 SQL 时，计算节点解析该语句，而后对它做分布式查问优化，而后通过与后端存储 shard 做交互来实现分布式查问执行。交互的办法就是依据 SQL 语句的须要和数据在后端 shard 的散布信息，为相干的后端存储 shard 生成 SQL 语句。
如果执行的 SQL 语句是 SELECT 或者 INSERT/DELETE/UPDATE…RETURNING 而不是简略的 INSERT/DELETE/UPDATE, 那么计算节点会并发地发送语句而后接管后果，最初合并解决所有后端存储 shard 返回的后果，造成最终的查问后果，返回给客户端。
每个存储 shard 存储着一部分用户表或者表分区，每个 shard 的数据子集没有交加；每个存储 shard 是一个 MySQL binlog 复制集群，通过规范的 MySQL MGR single master 模式或者基于传统的 row based binlog 复制的强同步机制来实现高可用性。
一个 shard 的主节点承受来自计算节点的读写申请，执行申请并返回后果给计算节点；启用了备机读性能时，shard 的备节点能够接管和解决来自计算节点的只读申请。
用户能够依据数据量的减少和缩小来减少和较少存储 shard，数据会主动平均扩散到所有 shard 下面，从而达到主动和通明的高可扩展性。
2.3 元数据集群
元数据集群也是一个 MySQL binlog 复制集群，存储着一个昆仑数据库集群的元数据。多个数据库集群能够共用同一个元数据集群。
最初，昆仑数据库还有一个 cluster_mgr 程序，它负责保护正确的集群和节点状态，占用资源极少。
*KunlunDB 我的项目已开源
【GitHub：】
https://github.com/zettadb
【Gitee：】
https://gitee.com/zettadb
END
