在数据库高可用架构下会存在1主多备的部署，备节点可以根据业务场景分发一部分流量以充分利用资源，并减轻主库的压力，因此在数据库的功能上需要读写分离来实现。
OceanBase数据库的读写分离是由ODP（OceanBase Database Proxy）数据库代理实现的，读写分离就是数据在主节点修改后，数据同步到备节点，备节点提供数据的读取功能。OceanBase数据库支持读写分离到表的Partition级别，这也是原生的分布式数据库的优势。
在OceanBase数据库中使用读写分离功能，需要经过两部分设置：
1）在SQL语句中通过Hint
/*+READ_CONSISTENCY(WEAK)*/配置
select /*+READ_CONSISTENCY(WEAK)*/ * from t1;
2）通过OBProxy配置项obproxy_read_consistency设置
alter proxyconfig set obproxy_read_consistency = 1;
配置项默认值0表示强读、1表示弱读。SQL hint是语句级别的，配置项是实例级别的。通常可以配置多个OBProxy实例，选择其中部分OBProxy开启读配置作为运维查询使用。
ODP通过配置项proxy_route_policy修改路由策略，通过设置为follower_first和follower_only可以让弱读请求优先发给备副本：
上述两个策略需要根据业务场景选择
PolarDB MySQL版本的集群自带读写分离功能，在PolarDB控制台的数据库连接中配置读写模式，包括只读模式和可读可写模式（自动读写分离）。当配置可读可写模式后，写请求会自动转发到主节点，读请求会自动根据各节点的负载（当前未完成的请求数）转发到主节点或只读节点。
同时读写分离模块自动对集群内的所有节点进行健康检查，当发现某个节点宕机或者延迟超过阈值（全局一致性读超时时间，取值范围：0~60000，默认为20ms）后，PolarDB将不再分配读请求给该节点，读写请求在剩余的健康节点间进行分配，以此确保单个只读节点发生故障时，不会影响应用的正常访问。当节点被修复后，PolarDB会自动将该节点纳回请求分配体系内。
在配置了可读可写模式下，SQL语句的转发遵循以下规则：
PolarDB在可读可写（自动读写分离）模式下仅支持基于活跃请求数负载均衡的策略，优先选择最小活跃（并发）请求数的节点去路由请求，来保证多个只读节点间的负载均衡。该策略基本可以保证流量根据后端节点的负载均衡的路由到不同的后端节点上，即使后端节点的规格不一致，也能较好的进行负载均衡。
为了满足线上业务负载的多样性，PolarDB后续版本引入了基于权重的动态负载均衡策略，为每个节点配置不同的权重后，在后续的路由过程中，权重和并发请求数会同时作为参考标准去动态的调整最终的路由决策。在控制台“数据库代理服务配置”中，可以为不同的节点配置不同的权重，动态权重越大，节点的优先级越高，路由分发的流量也越大。
在GaussDB数据库控制台的数据库代理页面，新增数据库代理，包括代理模式、一致性级别、路由模式和添加的数据库节点。
另外，在SQL中通过hint方式指定发往主节点或只读节点。需要注意的是Hint注释仅作为路由建议，非只读SQL、事务中的场景不能强制路由到只读节点。
GoldenDB数据库的读写分离策略由连接实例级别的策略+语句级别的策略共同决定：
不同策略的组合如表所示：
另外，为避免只读数据节点读取的数据长时间和主数据节点不一致，当一个只读数据节点的延迟时间超过设置的延迟阈值，则不论该只读数据节点的读权重是多少，读请求都不会转发至该只读数据节点。在新版本的读写分离配置中，增加了“是否可读主”的配置，选择否后，当主备时延超过阈值时，依旧不会读主节点。
需要注意的是在多分片的实例中，当CN节点配置参数force_read_split后，开启读写分离时，显示的开启事务后，为了保证事务操作的一致性，事务内是不允许更新操作的，只允许只读事务，否则会提示“read-only transaction”的报错。
TDSQL数据库默认支持读写分离功能，包括3种读写分离的配置操作，其中非只读账号由参数gateway.mode.single_backend.rw_split控制：
//主机读//
select * from emp order by sal，deptno desc；
//从机读//
/*slave*/ select * from emp order by sal，deptno desc；
官方建议使用第1种和第2种方式配置读写分离，第三种配置方式会有一定程度的性能损耗。
##优先连接到备节点
jdbc:opengauss://node1,node2,node3/database?autoBalance=roundrobin&targetServerType=preferSlave
##只连接备机进行只读操作
jdbc:opengauss://node1,node2,node3/database?autoBalance=roundrobin&targetServerType=slave
##只连接主机进行读写操作
jdbc:opengauss://node1,node2,node3/database?autoBalance=false&targetServerType=master
OpenGauss数据库在一主多备的架构下，当主节点宕机的时候通过自主寻主的机制，找到主备切换后的新主。通过JDBC连接中的配置参数hostRecheckSecond，当主机状态发生更改时再次检查主机状态，快速地找到新的主机并恢复连接，默认值为10秒。JDBC连接流程如下：
在TiDB数据库中读写分离通过follower read机制实现的，follower read是将TiKV读负载从Region的leader副本上offload到follower副本的负载均衡机制，以提升TiDB集群的吞吐能力并降低leader负载。TiDB的Follower Read功能开启通过变量tidb_replica_read配置：
set [session | global] tidb_replica_read = '<目标值>';
Tidb数据库的Follower Read在实现机制上是follower节点使用Raft ReadIndex协议确保当前读请求可以读到当前leader上已经commit的最新数据。因此在TiDB层面，Follower Read只需根据负载均衡策略将某个Region的读取请求发送到follower节点。
以上是几种国产数据库的读写分离实现，各个数据库厂商根据不同的业务场景在不同程度上实现了读写分离的功能，对比如下所示：
总体上而言，PolarDB、GaussDB和GoldenDB在读写分离的功能上更为完善，考虑到实例级别、SQL级别以及对事务的影响，还有在主备时延超过阈值时的处理。