谈谈 PolarDB-X 在读写分离场景的实践

在数据库使用过程中经常会遇到一些场景：

1. 业务写流量一直相对比较稳定，但随着时间，数据不断增加，数据库的压力也会越来越大，写操作会影响到读请求的性能，做任何优化可能都达不到最终的效果；
2. 在应用的用户访问量比较低的时候，一个数据库的读写能力是完全能够胜任的。但是在用户访问量增大的时候，数据库很快会成为瓶颈；

针对这种写少读多的业务可以考虑通过添加数据库节点来使其达到提升性能的目的，但添加节点，往往涉及到数据的搬迁，扩容周期比较长，很难应对徒增的业务流量。这个时候可以考虑采用读写分离的方式，将读写流量做分流，减轻主实例的压力，同时利用只读库横向的扩展能力，快速提升读性能。

其基本原理是让主数据库处理事务性查询，而从数据库处理select查询。当业务量非常大时，一台服务器的性能无法满足需求，就可以读写分离方式分摊负载，避免因负载太高而造成无法及时响应请求。目前业界实现读写分离的方案主要有两种：

基于程序代码内部实现

在代码中根据select,insert进行路由分类，这类方法也是目前生产环境应用最广泛的，优点是性能好，因为在程序代码中已经将读写的数据源拆分至两个，所以不需要额外的MySQL proxy解析SQL报文，在进行路由至不同数据库节点。缺点是通常该架构较复杂，运维成本相对较高。

基于中间Proxy（odp/mycat等）实现

Proxy一般位于客户端和服务器之间，代理服务器接到客户端请求后通过解析SQL文本再将SQL路由至可用的数据库节点中。优点是程序不需要改造可以实现无缝迁移，可移植性较好。缺点是性能相对前者略微逊色一些，并且并不是所有的读操作都能够被路由至从节点中。

上述方案都不能算是透明的，要不需要对业务代码进行改造，要不需要业务系统依然第三方组件；除此之外，业界主流的读写方案都无法做到一致性读，应用在使用弱一致性读时，要充分考虑主备副本的数据同步延时，并根据具体业务场景考虑延时的业务影响（脏读）是否能够接受。读写分离业务都还需要做额外的改造，以应对只读库异常或者延迟过大的时候下，对业务做降级处理。

为此，PolarDB-X内核侧提出一种提供了透明的强一致的读写分离能力，支持多种读写分离策略满足各类业务需求。

PolarDB-X Native 读写分离

PolarDB-X配置了多种读写策略，提供了透明的强一致的读写分离能力。简单的说其特点有：

• 无论什么状况都不用担心误写了“备副本或只读副本”，因为它不支持写，写操作会被路由到主副本；
• 无论什么时候不用担心“备副本或只读副本”故障，因为它会自动路由给其他正常的副本或者切回主副本；
• 无论什么场景不用担心 “备副本或只读副本”读不到最新的数据，因为它提供的是强一致的读写能力；
• 大查询不用担心打爆“主副本”，因为它支持将大查询路由给”备副本或只读副本“，避免对主副本造成压力。

其整体的方案设计如下：