一文浅谈“读写分离”技术

读写分离，作为一种常用的数据库访问优化手段，得到广泛的应用。本文尝试从读写分离的技术实现、适用场景及典型产品等角度，阐述这一技术的整体现状。

1. 读写分离：概述

1).何为读写分离

读写分离，从字面理解就是将对数据库的读操作与写操作分离的一种优化手段。其最早起源于互联网快速发展时期，面对海量用户访问问题，通过这一技术来解决数据库性能瓶颈问题。目前已经成为非常常见的一种数据库访问优化技术。

2).读写分离好处

• 提高访问性能

  通过引入读写分离技术，将之前集中于单点的访问压力，分散到更多节点。即可利用更多的资源，支撑业务系统，可有效提升整体访问性能。

• 提高稳定性

  通过将读取与写入操作的分离，可有效规避由于异常操作所带来的风险。常见如一个大查询语句，因访问数据规模巨大占用大量CPU资源。通过承载端分离，可避免影响更为重要的写入操作。

• 提高资源利用率

  为了更好地保护数据，数据库系统通常采用多副本技术冗余保护数据，但其备用副本如无法提供业务访问，将是一种资源浪费，而读写分离可有效利用只读副本，提升整体资源利用率。

• 提高可用性

  通过引入更多节点来承载读写操作，结合负载均衡与高可用探查技术，可避免单点故障引发可用性问题。

• 提高访问效率

  通过利用不同节点分别承载读取与写入，还可缓解因为锁带来的争用问题，提高单节点的访问效率。

• 更大优化空间

  针对读取操作的特殊性，可通过分离后的独立资源采取特有的优化技术，进一步提升访问效率。

2. 读写分离：技术实现

1).常用方案

目前业界流行的读写分离方案，通常都是基于上述主从模式的数据库架构，通过引入数据访问代理层，来实现访问动作的读写分离。引入数据访问代理的好处是源程序不需要做任何改动就可以实现读写分离，坏处是由于多了一层中间件做中转代理，性能上会有所下降，数据访问代理也容易成为性能瓶颈，并且还存在一定维护成本。还有另一种方式，是将数据访问代理层前置到应用侧，通过SDK方式与应用集成在一起，可避免独立一层所带来的性能损耗和维护成本高的问题。但这种方式对开发语言有一定要求，存在适用性问题。

2).技术要点

读写分离功能的好与不好，主要是在易用性和灵活度问题。前者是关心如何让业务开发像操作单个主库一样，无需过多关注主从读写分离的细节，只需要做好相应读写配置后，就无需考虑写主读从的细节。后者是解决用户多变的业务场景和拓扑变化，并可实现自动适应。这其中是需要解决一系列技术问题，如下面这些常见的问题。

❖ 判断读写操作

如何判断读写操作，是读写分离面临的首要问题。判断方式可大致分为自动和手动两种，前者是通过显式的方式由用户来指定;后者则是自动进行判断，用户无需关心。这两种判断方式往往是互补的，可配合来使用。下面是常见判断逻辑及处理：

• 基于不同端口连接

该实现方式就读写分离功能而言不是太好，因为此方式与应用自己实现没有明显差别，只是将直接连接不同数据库的逻辑变成了连接中间件服务器的不同端口，并没有对应用系统开发带来实质性的简化工作。

• 基于SQL匹配

采用正则表达式匹配是比较容易实现的方案，可以无需应用的修改，只需要在中间件添加正则匹配的规则，即可将读、写分发的逻辑在中间件完成。读写分离的效果，取决于中间件的正则匹配规则的编写质量。

• 基于Hint

应用系统发送SQL时，可以添加Hint，显示的告诉中间件想要将该SQL发送到何处。中间件解析特定规则的Hint，即可实现对带有不同Hint的语句分发到不同的数据库节点。

• 基于语法解析

当中间件获取到应用发送的SQL字符串时，对其进行完整的语法解析，可以最大程度的获取SQL字符串中的信息，例如类型、操作对象等。基于语法的判断，就能够自动针对不同语句类型进行读写分发，可以最大限度的减少应用的适配工作。

使用语法解析是相对来说较为友好的方式，无需开发人员感知即可实现读写操作分离。但这其中存在难点，就是如何准确判断出只读操作存在一定困难，例如使用函数、存储过程、触发器或诸如“SELECT ... FOR UPDATE”类的操作。此时，是需要引入辅助机制进行判断，可采取配置名单方式来辅助分析;或者通过Hint、API的方式强制指定走写库或读库。除此之外，还有些命令也需要规范是否可在备库执行，如COPY、SHOW、SET、BEGIN...END等。

❖ 如何处理事务

事务类操作，往往意味着数据变化，在读写分离中如何处理呢?通常有两种思路，一种是简单粗暴方式，将所有事务及关联操作全部发送到主机;一种是更为精确的处理，即分析事务内的语句序列，将事务中先写后读的对象进行关联，一起发送到主机，确保数据正确，而把和写操作无关的读操作，进行拆分，发送到备机执行。后一种处理方式能最大限度的利用读写分离，当然需要解决对象前后关系这一问题。

❖ 解决主备延迟

基于副本方式的延迟是常见的，也是读写分离在设计之初就需考虑的问题。其通常的处理思路可以有多种：

• 强制读写走主库

这类解决方案最简单粗暴，也是实际工作中最常用的方案。通过对主备节点延迟情况的判断，来决定如何是走主库还是备库。通常可将延迟判断封装在中间层，前端应用可不感知，只需配置延迟阈值即可，当超过这一阈值就自动走主库。如下次访问时延迟低于阈值，可重新走备库。当然，这一方式无疑会加大对主库的压力。

• 轮转和重试备库

当在备库读取不到最新数据时，另一种思路多读取几次或者尝试读取其他备库。这里面的核心是对读取最新数据的判断，通常需要在应用开发时有所考虑才可。同时还需要制定退化方案，在何种情况下退化到读取主库。

• 结合缓存解决

如延迟是常态，很难短期内解决，通过引入缓存可达到立竿见影的效果。其原理是在数据写入主库时，同步或异步写入缓存，应用读取时优先读取缓存，失效时才读取数据库。这种方案因引入缓存组件稍显复杂，需解决缓存与数据库同步更新及失效问题;同时对应用侧有一定影响，需感知到缓存。比较好的处理方式是都封装在中间层，通过它来统一处理访问逻辑。

• 数据库优化

最后一种就是尽量避免出现延迟，常见对数据库有些可优化的措施。例如尽量减少在主节点上执行大事务操作、减少主库索引进而减小写入开销、主备库采用不同存储引擎提升效率等等。当然这些方案只能起到一定作用，无法完全避免延迟问题。

❖ 灵活负载策略

针对多个读库，读写分离组件还需提供灵活的负载均衡策略，常见的如随机、轮询、权重等等。这其中有几个特殊情况需要考虑：

• QoS

不同读库的服务能力有所差异下，其能提供的服务保障不同，需在读写分离中提供例如权重的配置，进行干预。当然，更好的方式是提供服务质量评估机制，可根据各读库的服务能力进行分配。

• 位置感知

针对多AZ、多Region的情况，不同读库承载的角色不同，有的只作为备选主库不承担读、有的作为远程灾备等，因此在读写分离中希望能感知到这些信息，有所区别对待。往往可通过设置标签的方式解决，根据不同标签设置不同策略。

❖ 解决读一致性

在读写分离中，当存在多个读库下，会因为延迟不同，出现读取不一致的情况。即路由到不同的读库，读取的数据鲜活度不同。这对于前端应用会造成一定困扰，解决的方法可采用会话粘性的策略，针对同一会话路由到同一读库，避免出现读不一致。

❖ 拓扑结构感知

如果读写分离访问的数据集群拓扑发生变化，例如主备发生切换，写操作要到新的主库;亦或是增加了备库数量，流量可以打到新备库等，这些都是需要读写分离组件感知到底层数据库拓扑的变化。这里的难点在于几个方面：

• 准确感知变化

当出现网络等原因，底层发生变化，可能读写分离组件没有探查到;或者探查本身就出现问题，没有发生变化而误认为发生变化。此时就会出现两张拓扑结构，一个实际结构，一是读写分离组件感知到的结构。这一问题，一方面可通过引入共识机制，增加多方判断解决;一方面也可通过与高可用组件互动减少误判。

• 感知时效问题

当发生拓扑变化后，从发生变化到被读写分离组件感知是需要时间的，过短会导致数据库探查压力大;过长会影响整体恢复时间，这其中需要有个取舍。建议将这一能力开放给用户，由用户根据自身业务进行决策。同时也可与高可用组件互动，将拓扑变化信息尽快推送到读写分离组件，变被动探查为主动感知，提高时效性。

• 人为干预能力

除因故障等原因发生的拓扑变化外，有时还需人工干预读写分离。如发生机器维护、数据库升级等情况下，可提前通过人工手段，从拓扑结构中摘除相关节点，做到更加平顺。

❖ 个性化诉求

除了上述要点外，还有些用户个性化的需求。如某个数据库用户的访问只走主库，某类应用的访问只走主库等，这类需求比较分散，比较好的处理方式是提供一定的脚本扩展能力，类似lua扩展Nginx的方式。

3. 读写分离：最佳实践

1).数据库优化手段对比

读写分离技术，是一种有效的数据库访问优化手段，但不是唯一。随着业务增长，达到一定规模后，提升数据库承载能力可以有多种方式，从大的分类来看可分为业务层优化、架构层优化、访问层优化与数据库优化几个方面。

• 业务层-垂直拆分

  最为彻底的优化手段，在业务层就做了拆分，投入较高，但取得效果往往也比较可观。

• 架构层-缓存/搜索

  通过引入缓存、搜索等技术，减轻对数据库压力，让数据库专注于有价值操作。这种方式需要一定改造工作量，取得收益取决于业务对数据的要求而定。

• 访问层-读写分离

  简单快速的优化方式，可快速提升性能，针对部分场景效果明显。

• 访问层-分库分表

  分库分表方式，原理上是采取“大化小”的策略，但对于SQL兼容性有较高要求，会存在一定业务改造工作量。预期收益效果看规模和业务对数据要求而定。

• 数据库-垂直拆分

  对现有数据库根据业务进行拆分，难易程度及投入成本取决于之前架构设计，难点在于拆分后的数据交互。预期收益不很明确。

• 数据库-垂直扩展

  对数据库升级是快速见效的措施，对应用几乎无影响，但需一定的成本投入及升级所需的中断服务的时间。取得收益存在上限瓶颈，预期中等。

• 数据库-水平扩展

  对分库分表类似，但通常初始投入较大，对应用存在一定侵入性。

从上述对比可见，读写分离，可以说是对应用侵入最小，也最容易实现的优化手段。相对投入不到，就可取得一定效果。特别是对于大量读请求和少量写请求的业务场景，会有不错的效果。

2).读写分离适用场景

读写分离是一种简单有效的优化方式，但不是万能，其有着明显的适用场景特征。

• 读多写少

当单机数据库不能支持业务的读写规模，就可以考虑读写分离。但需要考虑两者的比例，如果写操作比例大于读操作，那么大量写操作都在主库进行，读写分离达不到预期降低主库压力的作用。一般来说，两者读写比越大，效果越好。当然还需考虑写规模不能也不能高于单机数据库支持规模。

• 读有限扩展

针对承载读的规模超大的情况，也需慎重。通过读写分离是可以实现一定程度读操作的横向扩展，但不是无限的，受限于数据库复制的效率与成本，其存在扩展上限。对于大规模的可综合考虑缓存、数据拆分等多种手段。

• 允许延迟

针对主备方式难免存在延迟，因此对于延迟很敏感的操作不适于此方案。

• 非复杂查询

采用读写分离能在一定程度上解决查询效率问题，但针对复杂查询试图通过这一方式去解决不是一个好的思路。这类诉求建议通过搜索引擎、OLAP等技术去解决。

4. 读写分离：典型产品

业内有很多读写分离方案，一类是采用中间件思路开发，以开源产品为主;一类是数据库产品，内置读写分离功能。下面简单介绍下主要的产品：

1).MySQL-Proxy

MySQL-Proxy是MySQL官方提供的MySQL中间件服务。MySQL-Proxy实际上是在客户端请求与MySQLServer之间建立了一个连接池。所有客户端请求都是发向MySQL-Proxy，然后经由MySQL-Proxy进行相应的分析，判断出是读操作还是写操作，分发至对应的MySQLServer上。对于多节点Slave集群，也可以起做到负载均衡的效果。

# ./mysql-proxy --daemon --log-level=debug --user=mysql --keepalive --log-file=/var/log/mysql-proxy.log --plugins="proxy" --proxy-backend-addresses="192.168.1.5:3306" --proxy-read---proxy-lua-script="/root/soft/mysql-proxy/rw-splitting.lua" --plugins=admin --admin-username="admin" --admin-password="admin" --admin-lua-script="/root/soft/mysql-proxy/lib/mysql-proxy/lua/admin.lua"

其中proxy-backend-addresses是master服务器，proxy-read-only-backend-addresses是slave服务器。

2).Apache ShardingSphere

Apache ShardingSphere 是一款开源的数据库中间件产品，并在Apache基金会毕业，可以说是非常成熟的开源项目。其产品内置了丰富的功能，包括读写分离能力，具体包括：

• 支持动态、静态读写分离能力，支持自动拓扑感知与人工设定。

• 支持多种数据库(如MySQL、PG、openGauss等)及多种架构(如MySQL 主从、MGR等)

• 支持多端接入(Driver、Proxy)，可满足低时延场景

• 支持语法解析自动判断或 Hint 方式手工指定

• 支持包括熔断等能力的人工干预手段，可适应多种场景

• 支持类SQL的管理配置方式，支持热加载配置

• 支持丰富的负载均衡算法，如下图

3).MyCAT

MyCAT 是一款开源的数据库中间件产品。读写分离功能通过配置文件完成，如下

balance，读写分离策略

• 0，不开启读写分离机制，所有读操作发到当前可用writeHost上

• 1，全部readHost与stand by writeHost参与select语句负载均衡

• 2，所有读操作都随机在writeHost、readhost上分发

• 3，所有读请求随机分发到readhost

writeType，写模式

• 0，所有的操作发送到配置的第一个writehost

• 1，随机发送到配置的所有writehost

• 2，不执行写操作

switchType，切换模式

• -1，表示不自动切换

• 1，默认值，表示自动切换

• 2，基于MySQL主从同步的状态决定是否切换

• 3，基于MySQL galary cluster的切换机制

4).阿里云-RDS数据库代理(以RDS PG为例)

数据库代理是阿里云数据库RDS提供的一款安全、稳定、高性能，对应用完全透明的数据库中间层服务。数据库代理是位于数据库服务端和应用服务端之间的网络代理服务，代理服务端代替应用服务端数据库发送和接受所有数据库请求，进而可以在代理服务层上实现比如读写分离、连接池、端对端加密、防闪断等附加功能。通过数据库代理用户只需要通过一个链接地址即可实现读写分离架构，读写属性和只读属性的多样化选择满足了不同业务场景。

数据库代理支持了PostgreSQL的协议，并且具备对用户的请求连接认证权限的能力。代理中的路由策略是核心：可以通过hint中指定固定的实例节点来转发流量;也能够将事务内写操作之前的读请求转发到只读实例，降低主实例负载;路由策略还可以根据用户自定义的只读模式或读写模式对请求进行不同的分发执行。健康巡检模块周期性感知读写分离架构的拓扑变化情况，在实例节点不健康或者超过延迟阈值，会自动把读请求路由到其他的只读实例上。

5).OceanBase

OceanBase 数据库天然支持读写分离的功能，即通过 OBProxy 代理服务和修改 OBServer 的配置即可实现业务的读写分离策略。OceanBase 数据库在读取数据时，提供了两种一致性级别：强一致性和弱一致性。

• 强一致性是指请求路由给主副本读取最新数据;

• 弱一致性是指请求优先路由给备副本，不要求读取最新数据。

通过应用侧为执行的 SQL 添加 SQL Hint 来显性开启弱一致性读就可以实现基于注释的读写分离功能，同时也衍生出如下三种常用的读写分离策略：

6).KunlunBase

KunlunBase是一个开源、高性能的分布式关系数据库，支持混合负载、PB级数据量管理并提供毫秒延迟的新一代数据库解决方案。

KunlunBase 的读写分离在计算层的远程查询优化器内实现的，当用户的SQL同时满足如下条件：

• 当前SQL类型为select;

• SQL中不包含用户自定义函数，除非当前事务为只读事务;

• 如果不在事务中(autocommit=on)，则允许读写分离;

• 如果语句在显式事务中，则要满足：

- 如果在只读事务中，则允许读写分离;

- 如果在读写事务中，则该事务未更新过数据;

远程查询优化器就会将相应的SQL 执行计划下发到从备机的节点上执行。KunlunServer 会根据以下规则选择发送select语句到目标存储集群的哪个备机节点：

• 根据节点权重值选择 (ro_weight)

• 根据网络延迟(ping)

• 根据主从副本的数据一致性延迟(latency)