GaussDB 整体架构解析

在介绍 GaussDB 体系结构之前，咱们先简单介绍一下 GaussDB 发展史。

在目前华为云数据库产品体系中，与 GaussDB 相关的两条主要产品线分别是 GaussDB 和 GaussDB(DWS)。其中，GaussDB 主要面向 OLTP 及通用关系型数据库场景，其技术体系可追溯至早期的 GaussDB 100，后发展为 GaussDB T，并进一步演进为当前的 GaussDB；GaussDB(DWS) 则主要面向 OLAP、数据仓库及分析型业务，其技术体系源可追溯至早期的 GaussDB 200，2019 年，GaussDB 200 合并了 GaussDB 300 的部分设计，更名为 GaussDB A，后来演变成了华为云上的 DWS 服务。

1. GaussDB 体系结构

GaussDB 分布式数据库由多个核心组件协同组成，主要包括 CN（协调节点）、DN（数据节点）、GTM（全局事务管理器）、CM（集群管理器）、OM（运维管理组件）以及 ETCD 等基础管理组件。不同版本和部署模式下，组件构成及其职责可能有所差异。

主备版逻辑架构图：

分布式版逻辑架构图：

ETCD、DN、CM、OM 是三种软件架构共有的组件；
CN、GTM 则是分布式架构独有的组件。

1.1 协调节点(CN)

协调节点（Coordinator Node，CN）是 GaussDB 分布式数据库中的管理与调度中心，主要负责接收客户端 SQL 请求、解析 SQL 语句、生成执行计划，并将执行任务分发至各数据节点（DN）执行。同时，CN 负责汇总各 DN 返回的执行结果，并将最终结果返回给客户端。CN 还负责维护全局系统目录（Global System Catalog），确保分布式集群中元数据的一致性。

在 GaussDB 分布式集群中，可以部署多个 CN，各 CN 之间角色平等，不存在主从关系。客户端连接任意一个 CN 执行 DML 语句，都能够获得一致的执行结果，通常建议在 **CN 与应用程序之间部署负载均衡器(F5、LVS）。

与 DN 不同，CN 不存在类似 DN 的主备复制机制 。CN 本身不承担数据持久化和数据副本同步，因此配置 CN 高可用时，主要通过部署多个 CN 实例来实现，而不是通过主备同步实现。CN 是 GaussDB 分布式部署形态特有的组件，集中式部署不需要单独部署 CN。CN 的核心职责概括为以下四个方面：

SQL 解析与优化

接收客户端 SQL，完成 SQL 解析、语义分析、查询优化并生成执行计划。
任务调度与数据分片

根据执行计划，将 SQL 任务拆分并调度到相应 DN 执行，同时协调分布式执行过程。
全局事务管理

参与分布式事务的协调与管理，保证跨 DN 事务的正确执行。
元数据一致性维护

维护全局系统目录和元数据信息，确保各 CN 对数据库对象及相关元数据具有一致的认知。

1.2 数据节点(DN)

数据节点（Data Node，DN）是 GaussDB 分布式数据库中负责数据存储与数据计算的核心节点 。DN 负责存储业务数据，支持行存、列存以及混合存储，同时承担 SQL 执行、数据查询、数据处理等任务，并将执行结果返回给协调节点（CN）。

DN 主要承担数据存储和数据计算任务，从功能职责上可以概括为 SQL 执行引擎 和存储引擎两大部分。SQL 引擎负责 SQL 的解析、优化和执行，并通过存储相关接口访问数据；存储引擎负责数据的组织、读写和持久化。

在分布式集群中，每个 DN 负责管理部分业务数据，并通过高速网络与其他 DN 协同完成分布式查询和分布式事务 。为保证数据的高可用性和一致性，DN 主备节点之间通过 Quorum 或 Paxos 等数据复制机制进行数据同步。因此，分布式环境中一台主机经常会部署多个 DN 实例，一个 DN Group 的副本分布在多台主机上。

1.3 全局事务管理器(GTM)

GTM （Global Transaction Manager）是分布式事务的核心组件，负责生成和维护全局事务ID、事务快照、时间戳、Sequence 信息等全局唯一的信息。确保 ACID 特性在跨节点事务中生效。GTM 采用多版本并发控制（MVCC）机制，支持高效的并发访问。整个集群只有一组GTM：一个主GTM，一个或多个备GTM。

GTM 仅处理全局时间戳请求，64位 CSN（可以理解为全局递增的序列号）递增，几乎都是CPU++和消息收发操作。为了避免频繁持久化带来的性能开销，GTM 采用批量/周期性持久化 的方式，将 CSN 状态定期持久化到 ETCD。GTM 在持久化 CSN 时预留一定的安全增长区间（backup_step），使得即使 GTM 发生故障并从 ETCD 恢复，也能够继续生成严格递增的 CSN，避免出现 CSN 回退的问题。

传统 GTM 架构属于一种中心化的全局事务服务 ：全局时间统一、 CSN 生成简单、分布式事务协调逻辑清晰。但随着集群规模不断扩大，所有节点都依赖一个 GTM Group，会形成一定的中心化扩展瓶颈 。因此，未来的架构演进方向是： 逐步降低对中心化 GTM 的依赖，向去中心化架构演进。

1.4 集群管理器(CM)

CM（Cluster Manager，集群管理器）是 GaussDB 分布式数据库的集群管理与高可用控制组件，主要负责集群状态监控、故障检测、主备切换、资源管理以及高可用仲裁等工作。

可以将 CM 理解为 GaussDB 集群的 "大脑" ：它持续感知 CN、DN、GTM 等关键实例的运行状态，并根据集群当前状态进行故障判断和恢复决策，在必要时触发主备切换，从而保证数据库集群的高可用性。CM 由 CM Agent、CM Server 和 OM Monitor 组成，其中 CM Agent 负责进程保活、仲裁指标采集和命令执行，CM Server 根据状态判定是否需要修复并下发指令，OM Monitor 负责 OM、etcd、cm_agent 的保活与启停。 CM采用 Paxos 协议实现高可用。CM 本身也存在主备关系，当 CM Primary 发生故障时，通过高可用仲裁机制选出合适的备用 CM 接管服务。

① CM Agent

CM Agent 部署在集群各主机上，主要负责本机实例监控和命令执行。

其主要职责包括：

监控所在主机上的 CN、DN 等数据库实例运行状态；
采集实例状态及相关仲裁指标；
将监控信息和状态周期性上报给 CM Server；
接收并执行 CM Server 下发的控制和仲裁指令；
配合完成实例启动、停止、主备切换等操作。

② CM Server

CM Server 是 CM 的核心控制与仲裁组件，负责根据各 CM Agent 上报的信息判断集群状态，并决定是否需要进行故障恢复或主备切换。

主要职责包括：

汇总各 CM Agent 上报的实例状态；
判断实例是否发生故障；
判断当前集群是否需要执行修复；
制定故障恢复和主备切换策略；
向 CM Agent 下发相应的控制指令；
负责集群高可用仲裁。

③ OM Monitor

OM Monitor 是 CM 体系中的监控与保活组件，主要负责对 OM、ETCD、CM_Agent 等关键基础管理进程进行监控。当相关进程异常退出时，OM Monitor 可以根据管理策略执行相应的保活、拉起或启停操作。

1.5 分布式键值存储系统(ETCD)

ETCD 是一个高可用的分布式键值数据库，用于共享配置和服务发现(服务注册和查找)，负责存储集群各个节点状态，便于集群 CM 管理各个节点。 ETCD 存储 CM 所需的数据，集群的启动中，先启动的是 ETCD，然后才是其余的组件，其操作命令也是分开的。

在 GaussDB 集群中，ETCD 主要用于保存集群管理所需的关键状态信息，包括集群配置信息、集群拓扑信息、CM 高可用及仲裁相关信息、节点及实例状态等 。 ETCD 一般部署为奇数个，角色分 Leader 和 Follower。Leader 向 Follower 复制数据，通过 Raft 多数派保证数据一致性。因此，3 节点 ETCD 集群最多可以容忍 1 个节点故障。

ETCD 的作用概括为：

配置共享：为集群中的管理组件提供统一的配置数据存储，使不同节点能够获取一致的配置信息；
服务发现：保存服务注册信息，使集群管理组件能够发现其他服务和实例；
集群状态与拓扑信息存储：保存节点、实例以及集群拓扑等状态信息，为 CM 的集群管理提供数据基础；
高可用与一致性保障：通过 Raft 共识机制保证 ETCD 数据的一致性，并通过 Leader 重新选举实现自身的高可用；
支撑集群仲裁：ETCD 为 CM 等管理组件提供可靠的共享状态存储，从而支撑集群的高可用仲裁和故障处理。

简单说就是，CM 负责"管理和决策"，ETCD 负责"可靠地保存 CM 等组件进行管理和决策所需要的共享状态"。

在新版 GaussDB 中已经开始用自研的 DCC（Distributed Configuration Center，分布式配置中心）替代 ETCD 的部分能力 ，尤其是 CM/CMS 的选主和仲裁 。DCF （Distributed Consensus Framework）是支撑 DCC 等组件实现强一致和高可用的分布式共识框架。DCF 并不是一个独立运行的数据库进程，而是以动态库的形式集成到 GaussDB 数据库进程中 ，由 DN 调用 DCF 提供的相关接口，实现数据库节点之间的高可用协同。当开启 DCF 模式 后，DN 可以基于 DCF 提供的 Paxos 共识机制实现节点之间的自选主、自仲裁以及 XLOG 日志复制等能力，从而降低对外部集群管理组件进行数据复制和主备仲裁的依赖。

2. 单进程多线程架构

GaussDB 抛弃了 PostgreSQL 的多进程架构，采用了单进程多线程运行模式，同一进程内运行用户线程、系统线程、I/O 线程、日志线程等，线程之间协同工作，共同完成数据库的各项任务。多线程具有以下四大主要优势：

优势一：低启动开销

线程的启动开销远小于进程的启动开销。与进程相比，线程是一种更为"节俭"的多任务操作方式。在Linux系统下，启动一个新进程需要分配独立的地址空间，并建立多种数据表来维护其代码段、堆栈段和数据段，这是一种"昂贵"的多任务工作方式。相反，运行于同一进程中的多个线程共享相同的地址空间和大部分数据，因此启动一个线程所需的空间远小于启动一个进程。

优势二：便捷的通信机制

不同进程间具有独立的数据空间，数据传递只能通过通信方式进行，这不仅费时且不方便。而同一进程下的线程共享数据空间，一个线程的数据可以直接被其他线程使用，这不仅快捷而且方便。

优势三：低切换开销

在Linux系统中，进程切换分为两步：切换页目录以使用新的地址空间以及切换内核栈和硬件上下文。对于线程切换，切换页目录以使用新的地址空间是不必要的，只需执行切换内核栈和硬件上下文。因此，线程切换的开销明显小于进程切换。

优势四：较小的系统调用开销

在多线程架构中，系统调用的开销相对较小，因为线程切换仅涉及用户态和内核态之间的切换，而进程切换还需涉及用户态和内核态之间的切换以及地址空间的切换。

在启动 GaussDB 时，main 函数首先启动服务守护线程 Postmaster。随后，Postmaster 线程负责启动其他辅助线程，因此 Postmaster 是所有线程的父线程。当用户的 SQL 请求到达时，服务守护线程会启动一个 worker 线程，由该worker线程处理用户请求，执行SQL并返回数据。除了主业务线程外，GaussDB 还提供了一些辅助线程，用于实现维护和调度功能。主要线程类型有：

线程名称	线程介绍
main thread	数据库主线程。 1. 连接监听和接收：主线程负责监听来自客户端的连接请求，并接收新的连接。当有新的连接请求到达时，主线程处理连接并分配相应的资源，以确保客户端能够与数据库进行通信。 2. 工作线程监控和处理：主线程持续监控所有工作线程的状态，确保工作线程正常运行。
worker thread	工作线程。GaussDB 会根据需要创建多个工作线程来处理SQL语句的执行。每个工作线程都会独立地执行SQL语句，并将结果返回给主线程。
startup	数据库启动线程。
background writer	后台数据写线程。将数据库数据缓冲区的内容周期性地同步到磁盘上，以确保数据持久性。
checkpointer	检查点线程。负责进行检查点操作，完成数据库的周期性检查点和执行检查点命令，以确保数据库的一致性和恢复能力。
WAL writer	后台WAL写线程。将日志缓冲区的内容周期性地同步到磁盘上，以确保事务日志的持久性。
system logger	运行日志写线程。将各个线程的运行日志信息写入运行日志文件中，以便于系统监控和故障排查。
autovacuum launcher	垃圾清理启动线程。
autovacuum worker	垃圾清理线程。对GaussDB数据库中的垃圾数据进行清理，以释放存储空间和提高系统性能。
archiver	日志归档线程。完成归档操作，将在线日志复制到归档目录，以确保日志的长期保存和备份。

GaussDB 早期是基于 PostgreSQL 9.2 开发的，在架构上借鉴了 PostgreSQL-XC，但后来进行了重构。进程模型容易遇到 OOM，当爆发连接风暴时，work_mem 这类参数的设置可能造成内存溢出。线程模型提高了内存信息的安全性，也降低了内存溢出的风险。但是如果某条 SQL 杀不掉的话，PostgreSQL 可以在操作系统层面使用kill命令杀掉该连接，而高斯则不能，因为如果使用kill杀掉，会造成数据库主进程也被 kill。

转载：实战派K8S&DB