代码改变世界

GoldenDB 整体架构解析

2026-09-16 09:15  圣彼得堡的村长  阅读(31)  评论(0)    收藏  举报

GoldenDB 整体架构解析

1. 整体架构

  • GoldenDB 是一款由中兴通讯自主研发的金融级分布式关系型数据库，整体采用分层架构，由管理节点、计算节点、数据节点以及 全局事务节点组成。
  • 在此基础上，系统配备了统一的运维管理平台（Insight / OMM），实现集群监控、诊断分析与自动化运维能力。
  • 当然，外围生态工具同样丰富，包括导入导出组件（LoadServer）、数据迁移平台（SLOTH）以及备份恢复机制，共同构成了稳定、高效的金融级分布式底座。
GoldenDB体系架构

1.1 管理节点

  如图所示，管理节点主要包括 Insight、Metadataserver、ProxyManager、ClusterManager 和 LoadServer 组件。

  • Insight：统一的智能化运维与监控管理平台，负责对整个分布式集群的运行状态进行实时监控、性能分析、告警通知以及巡检，帮助运维人员全面掌控集群健康状况。
  • Metadataserver(MDS)：元数据服务组件，负责存储和管理集群中所有的元数据信息（如分片路由规则、表结构定义、节点映射关系等）以及系统的鉴权信息，是整个分布式数据库的“神经中枢”。
  • ProxyManager：代理管理组件，主要负责对计算节点前置的代理或访问入口进行统一管理和调度，保障客户端请求能够高效、安全地分发到正确的计算节点。
  • ClusterManager：集群管理中心，负责整个集群生命周期的调度与控制，包括各组件的自动化部署、配置下发、状态汇总以及节点故障后的调度响应。
  • LoadServer：分布式数据导入导出与迁移组件，配合运维指令负责海量数据的并行导入、导出以及跨平台的数据流转和迁移任务。

  为方便理解，对以上组件与主流分布式数据库产品相应的角色进行了对标梳理：

GoldenDB OceanBase GaussDB TiDB TDSQL for MySQL
Insight OCP TPOPS TiDB Dashboard 赤兔管理系统
Metadataserver RootService DCS 或 ETCD + (System Catalogs) Placement Driver Zookeeper/Metacluster
ProxyManager OBProxy CN (Coordinator Node) TiDB Server/TiProxy Proxy 管理组件
ClusterManager OCP Server/OCP Agent CMServer/CM Agent TiDB Operator (K8s) /TiUP Scheduler / Manager
LoadServer OBLoader/OBDumper gs_dump/gs_restore Dumpling/TiDB Lightning Mydumper/Xtrabackup

1.2 全局事务节点

  • 全局事务节点在 GoldenDB 中的实现是 全局事务管理器（GTM），GTM​ 负责全局事务号（GTID）的分配、事务状态管理以及全局一致性控制。
  • RDB （本质上是个 MySQL 数据库）作为 GTM 的专用存储组件，用于持久化全局事务号、活跃事务列表及事务快照等关键元数据。
  • 通常 GTM 和 RDB 本身也采用主备高可用部署，保障 GTM 元数据的可靠性。

  这里提一下，业界除了 中心化 GTM 路线外，还有几条典型的演进路线，基本上是在 2PC 思想上进行演变：

  • TiDB 的 PD 提供 TSO，虽然都是中心化节点，提供全局唯一、单调递增的时间戳/事务号，决定事务可见性与顺序，但是 TSO 通常只授时不管理事务状态，事务协调下推到计算节点（去中心化 2PC），而 GoldenDB 的 GTM 则更“重”，同时管控 2PC 与冲突检测，并配 RDB 持久化。
  • OceanBase 取消了独立 GTM，协调者无状态，全局顺序依赖 GTS（租户级全局时钟），本质仍是中心化授时，但更轻量且内嵌于集群。
  • TDSQL for MySQL：也没有明确的 GTM 组件，而是采用了 MetaCluster+ 全局 MVCC 的方案。中心时钟源专注于为事务开启和提交提供全局唯一且严格递增的时间戳（GTS）；而具体的事务管理器（TM）模块则直接内置于计算层（Proxy）中，发起分布式事务时，Proxy 直接扮演 2PC 的协调者角色，负责向各个数据分片发起 Prepare 和 Commit 指令。

  对比 GoldenDB 和 TDSQL for MySQL，GoldenDB 中 GTM 是全局事务协调者，CN/DN 为参与者；而在 TDSQL 中，协调者角色被内嵌到 SQL Proxy（CN）中，CN 直接驱动 2PC，底层的分片成为事务参与者（反客为主）。不再依赖独立 GTM 进程，仅通过 ZooKeeper/MetaCluster 完成拓扑与高可用决策。

为什么 TDSQL 选择的是 ZooKeeper ，这里再引申一下 CAP 定理。

image
  • Consistency（一致性）：任何客户端同时看到的数据都是一致相同的，无论是从分布式系统的哪个节点。任何一个读操作总是能够读到之前完成的写操作的结果，也就是说，在分布式环境中，不同节点访问的数据是一致的。
  • Availability（可用性）：每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据。即快速获取数据，可以在确定的时间内返回操作结果。
  • Partition Tolerance （分区容错性）：分区指的是分布式系统中部分节点因为网络故障导致彼此通信中断或延迟。分区容错性指的是即使分布式系统中部分节点因网络故障导致通信中断或延迟，分布式系统也能够正常提供服务。

   CAP 定理指出：一个分布式的系统不可能同时满足一致性、可用性和分区容错性，最多同时满足两个。当处理 CAP 的问题时，可以有以下几个选择：

  • （1）满足CA，不满足P。将所有与事务相关的内容都放在同一个机器上，这样会影响系统的可扩展性。传统的单机关系型数据库或其主从复制，如 MySQL、PostgresSQL 等都采用了此种设计原则。
  • （2）满足AP，不满足一致性(C)，即允许系统返回不一致的数据。牺牲C的 AP 系统尽可能的获取一致性数据的行为称为弱一致性。在弱一致性里，有一个特例，被称为最终一致性(BASE理论）。那为什么明知道数据不一致，但会选择 AP 呢，比如我发了一篇博客然后又修改了一下，一部分朋友立马看到了修改后的文章，电梯里的另一部分朋友却看到的是修改前的文章，出电梯后，再看到的文章是修改后的，实际影响并不大。在金融领域要求强一致性，而在内容、社交等场景中，AP + 最终一致性则是更优的工程权衡。
  • （3）满足CP，不满足A。强调一致性性和分区容错性，放弃可用性性(A)。在网络分区发生时，为保证数据一致性，受影响的服务必须等待数据同步完成。在等待期间，相关节点无法对外提供读写服务，直至集群状态恢复一致。

现在我们看一下 Zookeeper 的特点：

  ZooKeeper 基于 ZAB 协议，属于典型的 CP 系统。它采用多节点（通常为 2N+1）部署，单个节点故障不会导致集群整体不可用，所以它具备分区容错性（P）；集群中只有一个 Leader 负责处理写请求，Follower 同步复制日志以保证强一致性，当 Leader 挂掉后，整个系统进入恢复模式，此时是不可用的，直到新的 Leader 被选举出来。因此，ZooKeeper 优先保障数据一致性，而非始终可用，符合 CAP 理论中的 CP 特性。

  综上，ZooKeeper 在 Leader 选举期间的短暂“不可用窗口”，对于主要承担控制面协调、不承担事务处理的是可接受的；而其提供的“强一致性保证”，则是分布式场景下防止脑裂、确保元数据准确的刚性需求。
image.png|800

1.3 计算节点

  计算节点用于接收应用发送过来的业务语句，对业务语句做语法解析，对数据做分布式的优化，包括语句的改写，并行分发等等，最终生成分布式的执行计划，按照执行计划将语句下发到数据节点集群中。计算节点还进行分布式事务的并发控制、存储节点负载均衡、用户认证与鉴权等任务。
image.png
内部子模块（单 JVM 内多线程）：

  • 前端协议层：MySQL 报文解析、认证、长连接管理
  • SQL 解析/重写：语法检查、逻辑优化
  • 分布式优化器：生成分布式 Join / 下推计划
  • 路由与分片计算：按分片键定位 DN Group
  • 事务协调逻辑：向 GTM 申请 GTID，驱动 1PC+补偿 或 2PC
  • 后端连接池：到各 DN 的长连接管理
  • 本地元数据缓存：从 MDS 同步来的库表拓扑

  这里提一下，由于 GoldenDB 走的是将 MyCat 中间件 和 MySQL 融合到一起的路线，因此 GoldenDB 的 CN 是一个 Java 进程；GaussDB 的 CN 是一个数据库进程（coordinator），《GaussDB 内部探秘：进程、目录与端口》提到过 CN 也是一个数据库。 TDSQL 的 CN 则基于 开源 ProxySQL 演进而来。

1.4 数据节点

   数据节点用于实际存储数据、执行原子 SQL 操作和本地事务控制。每个数据节点对应一个 MySQL 节点，多个数据节点组成一个安全组 Group。在安全组 Group 中，数据节点按照一主多备进行快同步数据复制。多个 Group 组成一个数据库集群，数据在 Group 之间按照用户设计的策略进行水平分布。
image.png
一组主备 DN+dbagent，称为一个分片。

  • 每个 DN 是一个 深度定制过的 MySQL 实例（mysqld），但主从复制换成了 GoldenDB 自研的 gSync 快同步，不是原生半同步。
  • 组织方式：
    • 多个 DN 组成一个 安全组，组内一主多备；
    • 表按 hash/range/list 分片落到不同 Group；
    • DN 只认本地事务，不感知全局事务号（GTID 由 CN+GTM 注入）。

2. 部署规范

   GoldenDB 进行部署时，每个组件都有属于自己的专属系统用户，并且完全运行和隔离在各自用户的/home/目录下。 这种部署方式既符合金融级安全隔离和规范化运维的核心设计理念，也便于后续通过 cgroup、ulimit 等手段对不同组件进行细粒度资源管控。

组件模块 系统用户名 用户组 账号说明与职责
Insight 运维平台 insight goldendb Insight 安装用户。用于运行 Insight Server 监控平台及各主机上的 InsightAgent 数据采集代理。
Manager 管理节点 zxmanager goldendb Manager 安装用户。负责管理节点相关控制服务的运行。
系统巡检与预检工具 zxgdbcheck goldendb 集群自动化巡检与健康检查专用用户。用于执行系统环境检查、日常巡检或安装前置预检的专用账号。
GTM 全局事务节点 zxgtmN goldendb GTM 安装用户。用于运行全局事务管理器及底层 RDB 存储支撑进程。
CN 计算节点 zxdbproxyN goldendb CN 安装用户。用于运行 CN进程，处理 SQL 解析与路由。
DN 数据节点 zxdbN goldendb DN 安装用户。用于运行底层实际存储分片数据。

说明：

  • zx 是前缀，可在 install_senior.ini 中 user_prefix 配置；
  • goldendb 用户组也可以在 install_senior.ini 中配置；
  • 一个租户绑定一个 GTM 集群，一个机器内部署多个租户就有多个 gtm 用户，如 zxgtm1,zxgtm2
  • 不同租户之间 CN 不共享，因此一个机器可能会出现多个 CN，数字就加 1，如 dbproxy1,dbproxy2
  • 多一个分片，数字加 1，如 zxdb1,zxdb2,zxdb3..

  下一期，我们将逐条拆解 install_senior.ini ​ 中的关键参数。理解部署架构是“知其然”，掌握参数配置则是“知其所以然”。

  这里是《实战派K8S&DB》，更多干货敬请关注公众号。如果本文对你有所帮助，欢迎点赞、推荐和转发，也欢迎关注后续文章，一起考证、一起学习 GoldenDB 分布式数据库。

参考来源：《数据库系列之GoldenDB整体架构和一键部署》