高性能数据库--读写分离

读写分离的基本原理是将数据库读写操作分散到不同的节点上。

读写分离的基本实现：

• 搭建主从集群。

• master 负责写操作，slave 负责读操作。

• master 通过复制将数据同步到 slave，每台数据库都存储了所有的业务数据。

• 业务服务器将写操作发送给 master，将读操作发送给 slave。

"主从" 与 "主备" 的区别：

“主从” 的 “从” 可以理解为 “仆从”，需要帮主人干活，提供读数据的功能。

“主备” 的 “备” 是提供备份功能，不提供访问功能。

读写分离的实现逻辑并不复杂，但引入了2个问题：

1. 复制延迟如何处理？

2. 分配机制如何处理？

复制延迟

主从复制的延迟可能是几百毫秒，也可能是数秒，这就带来了问题：如果业务服务器写入后立即就读，读操作访问的是 slave，数据可能还没复制过来，例如用户注册完立即登录，就可能被提示“还没注册”。

常见解决方法：

1. 写操作后的读操作发送给 master

例如注册后登录时的读操作发给master。

这种方式与业务是强绑定，对业务侵入较大，比较容易产生bug。

2. 读 slave 失败后再读一次 master

就是“二次读取”，这个方式和业务没有绑定，只需要对数据库访问进行封装即可，缺点就是如果有很多二次访问，master 的压力就大了。例如被暴力破解账户，就会产生大量的二次读取，master 有崩溃的风险。

3. 关键业务读写操作都指向 master，非关键业务采用读写分离

例如用户管理系统，注册登录都访问 master，用户的介绍等业务采用读写分离，因为这些业务要求不高，即使用户修改自我介绍后读取到了旧数据，也没有太大的影响，可以忍受。

分配机制

有2中方式：

1. 代码封装

2. 中间件

1. 代码封装

在代码中抽象一个数据访问层，实现读写分离和数据库连接管理。

代码封装方式的特点：

1. 实现简单，可以根据业务进行定制。

2. 每个编程语言都需要实现一次，无法通用。

3. 故障时，如果主从切换，可能需要修改配置并重启。

开源方案中，淘宝的 TDDL（Taobao Distributed Data Layer，简称 头都大了）比较出名，基于 jdbc datasource 实现，具有主备、读写分离、动态数据库配置等功能。

2. 中间件

中间件是一套独立系统，提供SQL兼容的协议，业务服务无需自己实现读写分离，访问中间件和访问数据库没有区别，对于业务服务器来看，中间件就是数据库服务器。

中间件方式的特点：

1. 支持多种语言，因为提供的是标准SQL接口。

2. 需要支持完整的SQL语法和数据库的协议，实现复杂。

3. 所有数据库请求都经过中间件，所以对中间件的性能要求很高。

4. 数据库主从切换对业务服务器无感知，中间件可以探测数据库的主从状态。

目前开源的中间件方案中，MySQL官方推荐的是 MySQL Router，实现了读写分离、故障自动切换、负载均衡、连接池等。

官方文档：

https://dev.mysql.com/doc/mysql-router/8.0/en/

奇虎360也开源了自己的中间件 Atlas，基于 MySQL Proxy 实现。

官方文档：

https://github.com/Qihoo360/Atlas/blob/master/README_ZH.md

还有 MariaDB 的 MaxScale，可以了解下：

https://mariadb.com/kb/en/mariadb-maxscale-14/maxscale-14-tutorials/

内容整理自《从0开始学架构》