关系型数据库 读写分离

 

一。概述

 

读写分离数据库实例一般采用主从方式。

多主多从方式，虽能整体提高数据处理能力，但多主之间数据同步，数据一致性问题，暂无较完善的开源解决方案。

目前大多数系统采用一主多从的方式。主为读写实例，从为读实例。请求随机，轮训或加权（多从读实例负载均衡策略）等分配到不同从读实例。

主通过异步，半异步方式复制数据到从。

主从异步复制数据，写及时读，从读实例数据尚未完成同步，就有可能读到过期数据。读写分离，要解决写及时读到最新数据的问题。

读写分离一般在应用层添加读写分离中间件或在数据存储层添加数据库代理（上层无感知）来实现读写分离。

 

读写分离本身是数据层的领域问题，设计方案上，最好对上层透明。代理模式基本做到无感知，只需要修改一下应用中数据库地址。目前分库分表中间件，处理分库分表同时，也实现了读写分离的功能。

 

二。读写分离，一主多从读写请求分配原则

场景	分配到主读写实例	根据多从实例负载策略分配到某个从读实例	备注
SQL所有写	是
SQL同一个本地事务内读写	是
SQL无本地事务的读		是	从读实例都不存在或下线，还是分配到主读
SQL修改表结构语句	是

 

三。代理模式阿里云RDS读写分离

一主多从，代理模式，数据存储层读写分离。

• 应用修改

修改数据库连接地址。

• 运维修改

添加读实例。

 

四。中间件模式Sharding-JDBC

对应用不透明，有一定工作量。

• 应用修改。

1. 引入jar包。
2. 添加主从数据源配置

 

 

五。广义业务读写分离

 

 

 

（一）公司内部运营与企业B端（医院，医院医生）用户，C（居民）端用户读写分离

（二）B端医院与医院医生与C端居民用户读写分离

六。复杂搜索与日常OLTP数据读写分离

• 

   

 

七。不建议读写分离情况

• 数据量不大。
• 写多读少。
• 访问量不大，不需要读写分离。

 

八。TiDB