前言

在数据库高可用与高性能需求日益增长的今天，单节点数据库早已难以满足业务需求。金仓数据库KingbaseES的读写分离集群（KingbaseRWC）作为基于数据守护集群的增强方案，通过读写负载均衡能力大幅提升了数据库的并发处理能力。

一、读写分离集群的核心定位

金仓读写分离集群是基于硬件、软件系统不可靠，一定会有故障的假设设计的，是基于单台计算机无足够能力处理大量数据设计的。只要数据副本数量大于一，无论是硬件的升级、还是软件的迁移、单机的宕机或软件错误都无需停止对外服务，极大的保证系统的正常运行，并且降低了系统管理员和运维人员的工作量。

二、基础概念：理解集群运行的“最小单元”

2.1 数据库模式：主库（Primary）与备库（Standby）

KingbaseES数据库仅有两种模式，且角色分工明确：

• 主库（Primary）：唯一提供读写服务的节点，会生成WAL（预写式日志），并将日志同步给备库；
• 备库（Standby）：仅提供只读服务，无法生成WAL日志，通过接收主库的WAL日志并重放（REDO）来保持数据一致。

备库可通过SQL语句手动提升为主库（主库无法降级为备库）：

-- 备库提升为主库（仅备库可执行）
SELECT sys_promote();

2.2 数据库状态：判断节点健康度的关键

数据库运行过程中会处于不同状态，运维时可通过状态判断节点是否正常：

状态	含义	用户可连接？
DB_STARTUP	数据库启动中，正在重放WAL日志	否
DB_IN_PRODUCTION	主库正常运行	是（读写）
DB_IN_ARCHIVE_RECOVERY	备库正常运行 / 主库PITR恢复	备库可连接（只读）
DB_SHUTDOWNED	主库正常关闭	否

例如，若执行SELECT pg_stat_database_conflicts;发现备库状态频繁处于DB_IN_ARCHIVE_RECOVERY且有冲突，需排查主备日志同步是否延迟。

2.3 WAL日志：数据一致性的“守护者”

REDO 日志在KingbaseES 数据库系统中一般指 WAL（Write-Ahead Logging，预写式日志），其是保证数据完整性的标准解决方案——任何对数据页面的修改都必须先记录WAL并持久化到存储上。

WAL 中按顺序记录了所有对数据页面的修改，每一条修改记录称为一条 Record。一个事务包含至少一条 SQL语句，而一条SQL 会记录一条或多条record。事务提交时只需要保证将 WAL 从内存写入磁盘就可以完成，而不需
要保证所有更改的数据文件都写入磁盘。WAL是按顺序写入文件，而数据文件的更改大部分是随机位置，所以WAL写入磁盘的成本更低，这种方案减少了事务提交时磁盘写入的次数，提高了事务并发性能。

当数据库系统发生崩溃后，可以读取磁盘中的WAL并按顺序重放日志来恢复数据文件，保证了数据的可靠性。WAL 的文件组织形式是按wal_segment_size 进行划分的，默认情况下 wal_segment_size 为 16MB，即 WAL是由一系列16MB 大小的文件组成的。每个文件称为WAL段文件，段文件的名称是24字符的十六进制字符串，分别是8字符时间线、16字符段文件号，例如：000000010000000A0000002C。

2.4 脑裂：集群的“致命风险”

在主备集群或读写分离集群中，都应该有且只有一个primary 节点，其他节点都为standby。如果主备集群或读写分离集群中有多个primary 节点，此场景称为脑裂。

• 脑裂问题会导致数据分歧，无法保证数据一致性。

三、读写分离集群的5大核心特性

金仓读写分离集群的优势集中体现在“高可用”“高性能”“易维护”三大维度，具体可拆解为5个关键特性：

3.1 同步模式灵活适配

集群支持多种数据复制模式，可根据业务对“数据一致性”与“性能”的权衡灵活选择：

同步模式	特点	适用场景
实时同步（sync）	主库需等待WAL日志写入备库WAL文件后才提交事务，无数据丢失风险	金融交易、核心订单等强一致性场景
异步（async）	主库写入WAL日志到本地磁盘后即提交事务，备库异步同步，可能丢数据	非核心业务（如日志统计），优先追求性能
优选同步（quorum）	主库等待“多数备库”同步完成即可提交，兼顾一致性与性能	多备库场景（如1主3备），容忍部分备库故障

例如，某支付系统核心库采用“实时同步”模式，确保交易数据不丢失；而用户行为日志库采用“异步”模式，优先保证日志写入性能。

3.2 读写请求智能分流

基于事务级别的读写分离方案，通过JDBC驱动自动识别SQL语句读写种类，写语句发给主机，分发读语句到备机，从而实现读写分离。

3.3 节点负载动态均衡

驱动分发器均衡的将读操作均衡地分配到所有备库节点，降低主库的读写冲突，提高查询性能。

3.4集群在线弹性扩展

支持在线增加备库节点，新节点会被集群自动识别、同步日志，并参与读操作负载均衡。当数据库集群中出现某个节点宕机或者网络中断等问题时，金仓的数据库集群可以自动恢复。同时金仓JDBC会自动重建连接和自动判断主备状态，在非写事务状态下，JDBC还可以自动重发失败语句，直至成功，从而最大程度保障上层应用服务连续。

3.5 数据库性能显著提升

所有备库均可对外提供只读服务，集群通过JDBC配置实现“读写请求自动分发”：

• 写操作（INSERT/UPDATE/DELETE）自动路由到主库；
• 读操作（SELECT）均匀分发到多个备库，支持轮询、权重等负载均衡策略。

JDBC读写分离对比单机性能提升1.5倍。JDBC读写分离对比kingbasecluster性能提升3倍。

• Throughput曲线图：

四、读写分离实现原理：JDBC配置是关键

4.1 核心JDBC配置项

配置项	含义	示例
USEDISPATCH	是否开启读写分离	USEDISPATCH=true（开启）
SLAVE_ADD	备库IP列表（逗号分隔）	SLAVE_ADD=192.168.0.101,192.168.0.102
SLAVE_PORT	备库端口列表（与IP顺序一致）	SLAVE_PORT=54321,54321
nodeList	集群节点名称（需与repmgr cluster show查询结果一致）	nodeList=node1,node2,node3
HOSTLOADRATE	主库负载阈值，超过则读请求分流到备库	HOSTLOADRATE=33（主库负载超33%分流）

4.2 实战配置：两种常见方式

方式1：直接在连接串中配置（简单场景）

jdbc:kingbase8://192.168.0.100:54321/trade_db?
USEDISPATCH=true&
SLAVE_ADD=192.168.0.101,192.168.0.102&
SLAVE_PORT=54321,54321&
nodeList=node1,node2,node3&
HOSTLOADRATE=33

其中192.168.0.100为主库IP，trade_db为数据库名。

方式2：连接串+配置文件（复杂场景）

当备库数量多或需频繁调整时，可将配置放在jdbc.conf文件中：

# jdbc.conf配置文件
USEDISPATCH=true
SLAVE_ADD=192.168.0.101,192.168.0.102,192.168.0.103
SLAVE_PORT=54321,54321,54321
nodeList=node1,node2,node3,node4
HOSTLOADRATE=40

连接串简化为：

jdbc:kingbase8://192.168.0.100:54321/trade_db?ConfigurePath=jdbc.conf

4.3 事务一致性：异步模式的“注意事项”

在异步模式下，备库同步存在延迟，可能导致“读已提交”事务的一致性问题。例如：

• 事务1（主库）：更新商品库存update goods set stock=10 where id=1;并提交；
• 事务2（备库）：立即查询select stock from goods where id=1;，可能读取到旧值（如11）。

因此，异步模式不建议用于“同一事务内既有读又有写”的场景。若需强一致性，需将集群切换为“实时同步（remote_apply）”模式，确保备库已重放日志后主库才提交事务。

总结

金仓读写分离集群（KingbaseRWC）通过主备节点分工、WAL 日志保障数据一致性、智能读写分流与负载均衡，在确保高可用的同时显著提升性能，支持多种同步模式适配不同业务场景，仅需简单 JDBC 配置即可实现读写分离与在线扩展，为面临并发瓶颈、一致性挑战或高可用需求的企业提供了灵活高效的数据库解决方案，让数据库从业务瓶颈转变为增长动力。