昆仑分布式数据库架构介绍

一、前言

昆仑分布式数据库集群（下文简称昆仑数据库）是一个分布式关系数据库管理系统，面向 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-Linda），添加客服，在线沟通即可。