金仓数据库KingbaseES实现集中式与分布式共用内核，单核衍生四类集中形态与三类分布式集群

国产数据库厂商金仓（Kingbase）在其核心产品 KingbaseES 中实现了集中式与分布式架构的深度统一：整套系统基于同一内核构建，既可部署为传统集中式数据库的多种高可用形态，也能通过扩展模块快速演进为分布式集群。这一设计显著降低了用户在业务扩张过程中从集中式向分布式迁移的技术门槛与改造成本。

KingbaseES 的集中式家族包含四种部署形态：单机版、ClusterWare 主备集群、RWC 读写分离集群，以及 RAC 共享存储多活集群。这四者共享同一套数据库内核代码，仅在上层调度与集群协调逻辑上有所差异，因此应用层无需修改即可适配不同部署方式。

单机部署是最基础形态，一个实例对应一套存储，适用于低并发、对高可用要求不高的场景。其故障恢复时间（RTO）较长——网络或节点故障时 RTO 超过 10 分钟，存储故障则超过 30 分钟；但数据一致性保障强，恢复点目标（RPO）为 0。

ClusterWare 主备集群采用两节点结构，主库与备库各持一份完整数据副本。当主库失效时，备库接管服务，切换时间通常需 1 分钟以上；若存储损坏，则按半小时准备恢复。该方案虽提升可用性，但存储资源未节省，且仅有一份物理存储。

RWC（Read-Write Cluster）为一主多备的读写分离架构，写请求由主库处理，读请求自动分发至备库。其写响应时间约为单机的 120%，RTO 小于 1 分钟，RPO 仍为 0。每个节点保存完整数据副本，容量随节点数线性增长，适合读多写少的业务场景。

RAC（Real Application Clusters）是共享存储多活方案，多个数据库实例挂载同一份底层存储，均可执行读写操作。常规操作响应时间约为单机的 120%，而跨节点争抢相同数据块的操作延迟可能升至 200%。RAC 优势在于扩展性强——增加计算节点无需同步扩容存储，仅需预留约两倍冗余空间用于容错。其 RTO 同样小于 1 分钟，RPO 为 0。

RAC 的内部架构分为三层：数据库层运行服务与后台进程，并设集群通信进程负责节点间全局缓存与封锁信息同步；集群文件系统层含锁管理进程（处理跨节点并发）与 I/O 进程（执行实际数据存取）；Clusterware 层则由故障处理进程（探测异常并自动处置）与成员管理进程（维护全局一致成员列表）组成。共享存储划分为数据区与投票区，后者用于仲裁节点间脑裂风险——当两节点失联时，依赖投票区决定哪一方有权继续提供服务。

客户端侧，KingbaseES 提供 JDBC 驱动支持连接级负载均衡。官方文档明确指出：RAC 可提升整体读写吞吐能力，但单次操作延迟会略高于单机，实际扩展效果取决于节点间数据访问冲突程度。因此推荐将业务模块按数据耦合度拆分部署，例如人力资源、销售管理、电话中心等模块各自独立访问不同节点，仅共享组织结构等少量公共数据，从而降低冲突概率。

以 RWC 主库故障为例，其切换流程共七步：首先进行重连确认，避免因短暂网络抖动误判；其次隔离日志接收进程，确保所有备库处于统一状态；第三步进入竞选阶段，依据同步模式（all/sync/custom/quorum/async）筛选候选节点，再按日志位标、优先级、节点 ID 顺序排序；第四步执行多数派检查，无 witness 节点时需可见节点超半数才允许切换；第五步网络确认，向可信网关 ping 测试，防止因本节点网络隔离导致脑裂；第六步正式接管，依次挂载 VIP、执行 arping、promote 主库身份、补 checkpoint；第七步由 repmgrd 守护整个流程，其自身又由 kbha 每 3 秒轮询监控。

在集中式基础上，KingbaseES 通过叠加四个关键模块——分片管理、分布式执行引擎、分布式事务处理、全局事务一致性保障——构建出三类分布式集群：TDC（透明分布式集群）、Sharding（分片集群）与 ADC（分析型分布式集群）。这三者并非全新开发，而是基于原有内核的增量扩展，真正实现“一份代码、两种形态”。

这种架构选择反映了当前国产数据库厂商在应对云原生与海量数据挑战时的务实策略：不盲目追求“分布式原生”，而是以成熟集中式内核为基底，逐步增强横向扩展能力。相比从零构建分布式数据库，该路径能更好继承已有生态兼容性（如 Oracle 兼容语法、PL/SQL 支持）、运维工具链与客户信任基础。

行业观察指出，数据库“集中+分布”融合架构正成为主流趋势。阿里云 PolarDB、华为 GaussDB 均采用类似思路，即在单机引擎之上叠加分布式层，而非彻底重构。其核心价值在于平滑演进——企业可在业务初期使用单机或主备集群，随着数据量与并发增长，仅需添加配置与模块即可升级为分布式部署，避免“推倒重来”式迁移带来的巨大成本与风险。

金仓数据库的实践表明，统一内核不仅降低了开发与维护复杂度，也提升了产品迭代效率。例如，内核层的 SQL 解析、查询优化、事务管理等核心能力只需一次升级，即可同时惠及集中与分布式形态。这对需要长期稳定运行的关键行业客户（如金融、政务、能源）尤为重要。

值得注意的是，尽管架构统一，但不同形态适用场景仍有明确边界。单机适合边缘或测试环境；主备集群满足中等可用性需求；RWC 适用于报表、BI 等读密集型系统；RAC 则面向核心交易系统，要求高并发与强一致性；而分布式集群主要服务于超大规模数据仓库、实时分析或互联网级业务。

目前，KingbaseES 已在多个省级政务云、国有银行核心外围系统及大型央企 ERP 平台落地应用。其“不换产品、不重迁移”的演进路径，为国产数据库替代提供了更具可行性的技术范式。