数据库之读写分离

高性能数据库集群的第一种方式是“读写分离”，其本质是将访问压力分散到集群中的多个节点，但是没有分散存储压力；第二种方式是“分库分表”(下一篇)，既可以分散访问压力，又可以分散存储压力。

读写分离

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

读写分离的基本实现是：

• 数据库服务器搭建主从集群，一主一从、一主多从都可以；
• 数据库主机负责读写操作，从机只负责读操作；
• 数据库主机通过复制将数据同步到从机，每台数据库服务器都存储了所有的业务数据；
• 业务服务器将写操作发给数据库主机，将读操作发给数据库从机

主从：从机一般需要提供服务，如提供读数据的功能；
主备：备机一般被认为仅仅提供备份功能，不提供访问功能；

读写分离的实现逻辑并不复杂，但有两个细节点将引入设计复杂度：主从复制延迟和分配机制

复制延迟

以 MySQL 为例，主从复制延迟可能达到 1 秒，如果有大量数据同步，延迟 1 分钟也是有可能的。主从复制延迟会带来一个问题：如果业务服务器在数据写入主机后，在数据还未复制到从机时读取数据，会出现数据不存在问题。
解决主从复制延迟有几种常见的方法：

1. 写操作后的读操作指定发给数据库主服务器
   这种方式和业务强绑定，对业务的侵入和影响较大，
2. 读从机失败后再读一次主机
   二次读取和业务无绑定，只需要对底层数据库访问的 API 进行封装即可，实现代价较小，不足之处在于如果有很多二次读取，将大大增加主机的读操作压力，进而出现崩溃
3. 关键业务读写操作全部指向主机，非关键业务采用读写分离
   例如，对于一个用户管理系统来说，注册 + 登录的业务读写操作全部访问主机，用户的介绍、爱好、等级等业务，可以采用读写分离，因为即使用户改了自己的自我介绍，在查询时却看到了自我介绍还是旧的，业务影响与不能登录相比就小很多，还可以忍受

分配机制

将读写操作区分开来，然后访问不同的数据库服务器，一般有两种方式：程序代码封装和中间件封装

程序代码封装

程序代码封装指在代码中抽象一个数据访问层（也称这种方式为中间层封装），实现读写操作分离和数据库服务器连接的管理。例如，基于 Hibernate 进行简单封装，就可以实现读写分离，基本架构是：

特点：

• 实现简单，而且可以根据业务做较多定制化的功能；
• 和编程语言相关，如果一个业务包含多个编程语言写的多个子系统，则重复开发的工作量比较大；
• 故障情况下，如果主从发生切换，则可能需要所有系统都修改配置并重启

实现:
开源的实现方案中有淘宝的 TDDL（Taobao Distributed Data Layer），它是一个通用数据访问层，所有功能封装在 jar 包中提供给业务代码调用。其基本原理是一个基于集中式配置的 jdbc datasource 实现，具有主备、读写分离、动态数据库配置等功能，基本架构是：

中间件封装

中间件封装指的是独立一套系统出来，实现读写操作分离和数据库服务器连接的管理。中间件对业务服务器提供 SQL 兼容的协议，业务服务器无须自己进行读写分离。对于业务服务器来说，访问中间件和访问数据库没有区别，事实上在业务服务器看来，中间件就是一个数据库服务器。其基本架构是：

特点：

• 能够支持多种编程语言，因为数据库中间件对业务服务器提供的是标准 SQL 接口；
• 数据库中间件要支持完整的 SQL 语法和数据库服务器的协议（例如，MySQL 客户端和服务器的连接协议），实现比较复杂，细节特别多，很容易出现 bug，需要较长的时间才能稳定。
• 数据库中间件自己不执行真正的读写操作，但所有的数据库操作请求都要经过中间件，中间件的性能要求也很高；
• 数据库主从切换对业务服务器无感知，数据库中间件可以探测数据库服务器的主从状态。例如，向某个测试表写入一条数据，成功的就是主机，失败的就是从机。

实现：
目前的开源数据库中间件方案有： MySQL Router，奇虎 360 公司Atlas(基于 MySQL Proxy 实现)，Apache的ShardingSphere

总结

读写分离适用单机并发无法支撑并且读的请求更多的情形。
在单机数据库情况下，表上加索引一般对查询有优化作用却影响写入速度，读写分离后可以单独对读库进行优化，写库上减少索引，对读写的能力都有提升，且读的提升更多一些。
如果并发写入特别高，单机写入无法支撑，则读写分离也无法解决这个问题；
如果通过缓存技术或者程序优化能够满足要求，则无需读写分离；

缓存一般用在查询类业务上

--------来源《极客课程》∙ 学习摘要