随着数据的增长，数据要求越来越大，单台机器的性能瓶颈也快速的体现出来。分布式就随之而出现。达梦分布计算集群也随之出现，英文名称为： DM Distributed Processing Cluster，简称 DMDPC。达梦分布式计算集群的出现，解决了以下几个问题：

1. 单机磁盘的容量有限，而分布式则无此限制。
2. 数据的容错和高可用性，即使有一个节点坏掉也不会影响使用。
3. 在性能上，也有了很大的提升。

系统架构：

如上图所示：分为三部分SP、BP、MP

1. 计划生成节点，英文全称为 SQL Processor，简称为 SP
     SP 为 DMDPC 集群中对外提供数据库服务的节点，负责接收用户请求并生成计划、划分子计划、按照一定规则计算并行度并调度各个子计划，并最终将执行结果返回给用户。对于一次客户端请求任务来说，客户端连接的 SP 负责生成、划分并调度计划，其它的 SP 和 BP 负责执行计划
2. 数据存储节点，英文全称为 Backend Processor，简称为 BP
     BP 为 DMDPC 集群中数据实际存储的节点，负责存储数据和接收 SP 的子任务调度指令，执行子任务，并返回结果给 SP。一个 DMDPC 集群可配置多个 BP 节点同时提供服务，且可以随着用户业务量变化动态增删 BP 节点。为了保障 BP 节点能够持续提供服务，每一个 BP 节点又可以配置成一个 BP 多副本系统。
3. 元数据服务器节点，英文全称为 Metadata Processor，简称为 MP
     MP 为 DMDPC 集群中提供元数据服务（即字典信息服务）的节点。所有 DDL 请求都会经过 SP 转发给 MP 执行，元数据信息全部存储在 MP。
   一个 DMDPC 集群只能配置一个 MP 节点提供服务。为了保障 MP 节点能持续提供服务，MP 节点可以配置成一个 MP 多副本系统。

  回想到，刚才我们说出现分布式的原因。但是看到图，即使多副本，SP也是单节点哈。不对吧？是假的分布式？其实不是，大家接着看下面的多副本介绍，就可以更加深刻的了解它，当多副本出现时，如何保证数据一致性呢？进而引出一个新的概念：多副本架构。

多副本架构

  DM 多副本系统由 N 个节点实例组成，N 必须是大于 1 的奇数。只有配置了 RAFT 归档的实例才能加入多副本系统。
  目前一个多副本系统最多支持部署 9 个节点实例。同一个 RAFT 组中的所有节点（三个或三个以上）共同构成一个多副本系统。实例之间通过 XMAL 模块进行 TCP 消息通讯。各个节点实例之间基于 RAFT 协议选举出一个领导者作为主库，其他实例作为备库（也就是副本）角色运行。主库会自动向备库同步日志，备库接收并重新应用日志，从而达到主备库之间数据保持一致的目的。

如图为BP的多副本架构。

系统原理

以查询为例：

下面以客户端的查询 SELECT 操作为例，介绍并行查询的流程。如上图中箭头序号所示。查询请求的处理流程如下：

1. 客户端发送请求给 SP；
2. SP 生成执行计划，同时 SP 向 MP 申请获取字典信息；
3. MP 返回字典信息给 SP；
4. SP 将生成的执行计划中的一个或多个子计划发送给此次查询相关的 BP；
5. 相关 BP 接收并执行子计划。根据实际需要，不同 BP 间、同一 BP 不同线程间可能存在数据交换；
6. 相关 BP 在子计划执行完成时将成功与否信息和/或请求调度信息返回 SP；
7. SP 向客户端返回最终查询结果。

以上内容为个人对达梦学习的初步认知，受限于视角与经验，不足之处恳请指正。

更多详细内容：请移步官方DPC文档