金仓数据库 KingbaseES 的集中式家族有四个成员。单机、ClusterWare 主备集群、RWC 读写分离集群、RAC 共享存储集群。分布式是在这套内核上加分片管理、分布式执行、分布式事务、全局事务一致性四个模块，拼出 TDC、Sharding、ADC 三种集群，一份代码两种形态。
集中式的四种形态
单机最简单，一个实例一套存储。网络或节点故障，RTO 大于 10 分钟；存储故障，RTO 大于 30 分钟；RPO 都是 0。ClusterWare 是主备结构，两台机器各存一份数据，主库停了备库接管，切换要一分钟以上，存储坏了按半小时准备，存储只有一份。
RWC 是读写分离，一主多备。写请求走主库，读请求分到备库。写响应时间约为单机的 120%，RTO 小于 1 分钟，RPO 为 0。存储上每个节点各存一份完整数据，容量随节点数增加。RAC 是共享存储多活，多个实例挂同一份存储，每个实例都能读写。普通操作响应约为单机的 120%，跨节点抢同一批数据的冲突操作约为 200%。存储单副本，加节点不加存储，留两倍容量做冗余。RTO 小于 1 分钟，RPO 为 0。四种形态的应用改造成本都填"无"。
图：KingbaseES RAC 的运行架构。两节点之间通过集群通信进程交换全局缓存与封锁信息，锁管理进程做跨节点并发控制，成员管理进程维护全局一致的成员列表，故障处理进程负责探测，底层是同一份共享存储。
RAC 内部的进程与区域
官方文档的架构章节把 RAC 拆成三层：数据库层、集群文件系统层、Clusterware 层。数据库层跑服务进程和后台进程，另有一个集群通信进程，负责节点之间的全局缓存和封锁信息交换，I/O 从这一层下发到集群文件系统。
集群文件系统层有锁管理进程和 I/O 进程，锁管理进程做跨节点的并发控制，I/O 进程完成实际的数据存取。Clusterware 层有两个进程，故障处理进程做故障检测、检出异常后自动处置，成员管理进程维护全局一致的成员列表，两层之间用节点心跳通信。
共享存储划成两个区：数据区放数据库文件，投票区用于节点间的仲裁。投票区这个设计的意思很直接——两个节点互相看不见的时候，靠它决定谁有资格继续提供服务，避免两边都认为自己该做主机。
客户端这一侧，KingbaseES 提供连接驱动，做连接级的负载均衡。文档对性能的说明比较实在：RAC 能扩展读写吞吐，但相比单机，操作响应时间会增加；扩展效果和使用时节点间的访问冲突量直接相关。所以它的建议是让不同业务模块访问不同节点，模块之间数据相对独立，冲突就少。人力资源、销售管理、电话中心这种划分，共享的只有组织结构和人员信息这一小块。
图：KingbaseES RWC 的部署形态。应用通过 JDBC 驱动把写请求发给主库、读请求分给备库；主备之间传输日志，每台服务器上有守护进程做健康检查与故障转移。
RWC 切换的七个步骤
按主库故障的场景走一遍，一共七步。第一步，重连确认。备库上的守护进程发现主库异常后不立即动作，按 reconnect_attempts 的次数和 reconnect_interval 的间隔反复重连，排除网络抖动造成的误判，循环结束仍连不上，才进入下一步。
第二步，隔离。备库先关掉自己的日志接收进程，并确认其它备库也关了，保证所有备库站在同一状态上竞选，不会出现两个节点同时还在追日志的情况。
第三步，竞选。先看同步配置：all、sync、custom 三种模式要求备库处于 streaming 且 sync；quorum 模式要求 streaming 且 quorum；async 模式则比较主库的日志写入位标与本库的回放位标，差值小于 lsn_lag_threshold 才有资格。过了这一关才开始排序，先比日志位标，位标新的赢；位标一样，看 priority，高的赢；还分不出，挑 node_id 小的。三个条件都是死的，不掺人为判断。
第四步，多数派检查。没有 witness 节点时，可见节点数不足总数一半，竞选直接放弃；配了 witness 节点，这个限制可以有限放宽，允许大于半数节点失效时切换。
第五步，网络确认。向 trusted_servers 里配置的网关逐个 ping，一个都不通就放弃升主。这一步是防脑裂用的——如果只是本节点网络被割开，看谁都不像活着，贸然升主就会双主写入。
第六步，接管。顺序是先挂 VIP、再执行 arping，两个动作都成功才做 promote，最后补一次 checkpoint。VIP 挂载在 promote 之前，中间这段时间业务能连上，写操作被拒，日志里是只读报错。第七步，守护。上面这套流程由 repmgrd 执行，它自己由 kbha 看护，kbha 每 3 秒检查一次 pid 文件，进程不在就拉起来，而 kbha 由系统定时任务每分钟拉起一次。
文档还给了切机时间的计算公式，最短切机时间等于重连次数减一乘以重连间隔、加一、再加 ping 网关耗时与 VIP 切换耗时；最长那个公式在它基础上还要叠加监控间隔、连接超时、备库隔离超时。每一步各占多少秒，逐个列出。
分布式集群怎么来的
分布式这块，官方文档的表述是：分布式扩展架构基于集中式架构扩展，增加分片管理、分布式执行、分布式事务、全局事务一致性等模块，支撑 TDC、Sharding、ADC 分布式集群。分布式能力装在同一套内核上，数据量小的时候按集中式部署，业务长大了加分片模块，管理平台、监控、备份工具、运维习惯都沿用，不用再做一轮迁移评估。
这和分库分表拼装的路线不一样。分库分表底下是若干个独立的单机库，跨库事务、全局一致性要靠外部中间件补，补出来的东西和数据库内核是两套逻辑。这里的分布式事务、全局一致性是内核模块，SQL 进来走的还是同一条执行路径，执行器、优化器都是那一份。
图：同一套内核的装配关系。左侧四种集中式形态由单机逐级向上，右侧分布式集群在同一内核上叠加分片管理、分布式执行、分布式事务、全局一致性四个模块。
算成本，四个变量
存储容量、应用改造、维护人力、恢复时间，这四个变量决定选型。存储容量上，RWC 每个节点一份数据，容量随节点数线性增长；RAC 全体实例共用一份，加节点不加容量，两倍容量做冗余。
应用改造这一项，四种形态都是"无"，改的是部署形态，代码不动。维护人力这一栏，单机标极低，两套集群标低，RAC 标中，共享存储多活要管集群、管心跳、管存储。
恢复时间这一项，单机是十几分钟，RAC 和 RWC 是一分钟以内，RPO 四种形态都是 0。
图：四种形态的恢复能力和成本对照，数据取自官方文档的方案对比表，RTO 按网络或节点故障口径。
文档自己列出的短板
文档的限制与约束一节点出了这个版本的两处缺口：隔离级别的支持不完整，SSI 没能用上，异步通知特性也没做。跨节点冲突密集的业务，还要把模块分布重新规划一遍，冲突操作的响应会到单机的 200%。
分布式那边要设计的有三样。分片键怎么选、跨片事务怎么拆、全局索引怎么建。这三样没有工具替你算。
落到决策上，三个问题问完基本就有答案：三年内数据量会不会稳定超过 TB 级，并发有没有万级的明确预期，团队里有没有人真正管过分布式集群。三个都答不会，从集中式起步，同一套内核后面还能加模块；有一个答会，也不用换产品，加模块就是了。真到切换那一步，割接窗口、重写代码、重新培训的人，三笔开销都得提前算清楚。
