数字化时代，数据库对任何企业而言都是其利用的外围资源。MySQL 作为以后最风行的关系型数据库，尽管是开源软件，然而其简略易懂、易于部署治理，且具备 ACID 个性、弱小的 SQL 查问 等特点，被各种业务零碎作为要害的外围存储。
随着业务量的倒退和数据量的增长，单机版本的数据库很难满足业务须要，而 MySQL 最常见的性能扩大办法是“读写拆散”，其本质是将拜访压力扩散到多个 MySQL 节点上，但存储压力并没有扩散，“分库分表”能够扩散拜访和存储压力，然而实现难度保护老本都会大幅减少。
▲读写拆散架构图▲
- 须要主从的集群架构，一主一从或者一主多从；
- 主库响应写申请，从库响应读申请；
- 主库通过复制将数据同步到从库，每个节点都保留一份业务数据。
–
–
业界实现 MySQL 的“读写拆散”有两种常见办法，_客户端实现和代理实现，_两种办法各有利弊，须要联合各自业务特点、零碎架构、运维能力来抉择实现。因为引入代理会使零碎架构更加简单，同时代理本身要思考性能、高可用、稳定性等因素，中小公司个别应用客户端办法实现读写拆散。而大公司有资源去投入数据库代理的开发和保护，当接入的业务越多，带来的价值就越显著。
首先说下客户端实现办法，例如 java 语言能够基于 MyBatis 和 Hibernate 简略封装后，即可实现读写拆散，架构图如下：
代理实现办法，须要引入数据库代理，实现读写拆散和数据库治理性能，代理兼容 SQL 协定，对于客户端来说代理就是数据库，架构图如下：
比照两种架构的优缺点：
无论哪种架构，实现逻辑并不简单，然而有一个细节须要特地留神：_MySQL 主从复制提早。_
MySQL 的复制是异步的，只管针对不同提早的起因有响应的优化计划，然而提早是客观存在的，是不可能百分百防止的。当只读呈现较大提早的时候，就会呈现数据不统一，读到的数据是主库提交前的，称之为“过期读”，这时业务上可能就会呈现问题。常见的解决办法有：
- 外围业务读写都指向主库，非核心业务采纳读写拆散。比方金融类业务，为了保证数据的一致性，就义扩展性。比方论坛业务，发帖后会晚一些查问到，它带来的影响会小很多，是能够忍耐的；
- 二次读取，读失败后再查一遍，它和业务逻辑无关，只须要对数据库拜访层从新封装即可，实现代价小。不过某些场景下，它扩充的读申请的数量，减少了数据库的压力，比方 DDoS 攻打，很容易把数据库压垮；
- 判断提早再读取，读取从库前判断是否有提早，没有提早再从库查问，如果有提早到主库查问。MySQL 本身提供判断提早的监控办法，如果开启了 GTID，间接比拟从库的 Retrieved_Gtid_Set 和 Executed_Gtid_Set 值，它们雷同则示意从库没有提早；没有开启 GTID 的状况下，须要比拟两组值，Master_Log_File 和 Relay_Master_Log_File、Read_Master_Log_Pos 和 Exec_Master_Log_Pos 这两组值完全相同，则示意从库没有提早。
京东智联云 RDS-MySQL 反对 “读写拆散代理” 性能，创立只读实例后，开启读写拆散代理，就能够在程序中配置读写代理的地址，由读写代理实现读申请被主动转发到只读实例，写申请被主动转发到主实例。目前 MySQL5.6-8.0，Percona 和 Mariadb 都反对开启只读代理。具体介绍信息见：https://docs.jdcloud.com/cn/r…
上面从该性能的数据面和管制面来介绍下基本原理和最佳实际。
用户在创立读写拆散代理的时候会配置只读库提早、健康检查、负载平衡策略等参数，依据用户业务特点，实现读写拆散性能。
京东智联云“读写拆散代理”创立界面如下：
- _只读实例提早阈值：_只读实例与主实例的提早超过阈值后，只读实例将从读写代理后端被移除。
- 负载平衡策略：读写代理散发读写申请的负载平衡策略，反对起码沉闷连接数、起码连接数、最小同步时延、均匀响应时延。
- 连贯超时工夫：只读实例健康检查的办法。超时后只读实例将从读写代理后端被移除。
- _反复次数：_只读实例健康检查的办法。重试次数超过指定次数后，只读实例健康检查失败，将从读写代理后端被移除。
- 查看工夫距离：只读实例健康检查的办法，依据工夫距离对读写代理后端的只读实例进行健康检查。
最佳实际：只读实例提早阈值依据业务特点配置，默认工夫是 100s，强烈建议该值_大于_查看工夫间隔时间。
通过 RDS 控制台，能够治理“读写拆散代理”的整个生命周期，包含创立、批改配置、删除和开启公网拜访。除此之外，“读写拆散代理”还能够感知转发 MySQL 实例的高可用切换、批改配置流程、只读实例的创立和删除。
- 高可用切换，当转发的 MySQL 产生主从高可用切换的时候，“读写拆散代理”会主动调整写申请转发到新的主库上；
- 批改配置，当转发的 MySQL 主从实例或者只读实例触发扩容、缩容的业务流程时，“读写拆散代理”会主动调整将读写申请转发到新的实例；
- 只读实例的创立和删除，“读写拆散代理”会在用户增加新只读实例后，依据负载平衡算法，主动转发申请到新只读实例；当用户删除只读实例后，“读写拆散代理”会主动进行转发申请到已删除的只读实例。
“读写拆散代理”尽管会在客户端与数据库之间引入代理转发申请，会有性能损耗，然而后端是有多个只读节点响应申请，京东智联云的只读实例数据量最大是 8 个，所以在用户业务读申请很大的状况下，应用“读写拆散代理”是晋升性能的最佳办法。
通过上述内容，想必大家曾经对 MySQL 是如何用读写拆散的办法保障高性能扩大有了初步理解，如果还想进一步体验 MySQL 服务，请点击_【浏览原文】_链接体验试用。