前言

这是我的架构设计学习专栏的第3篇文章，此专栏用于存放我的架构设计学习笔记，内容一部分源于网上资料，一部分源于gpt和我自己的理解。专栏目前免费，欢迎订阅此专栏和关注我，随着专栏内容的增多，我可能会收费，所以建议喜欢本专栏的盆友尽早订阅。

我的架构设计专栏地址：https://www.nowcoder.com/creation/manager/columnDetail/0ybvLm 我的八股专栏地址：https://www.nowcoder.com/creation/manager/columnDetail/j8ZZk0

高性能集群实现方案-读写分离

1.前言

业务发展速度和数据增长速度，远远超出数据库厂商的优化速度，尤其是互联网业务兴起之后，海量用户加上海量数据的特点，单个数据库服务器已经难以满足业务需要，必须考虑数据库集群的方式来提升性能。

并不是说一有性能问题就上读写分离，而是应该先优化，例如优化慢查询，调整不合理的业务逻辑，引入缓存等，只有确定系统没有优化空间后，才考虑读写分离或者集群。

读写分离适用单机并发无法支撑并且读的请求更多的情形。在单机数据库情况下，表上加索引一般对查询有优化作用却影响写入速度，读写分离后可以单独对读库进行优化，写库上减少索引，对读写的能力都有提升，且读的提升更多一些。 不适用的情况:

• 如果并发写入特别高，单机写入无法支撑，就不适合这种模式。

• 通过缓存技术或者程序优化能够满足要求

2.什么是读写分离？

读写分离主要是为了将对数据库的读写操作分散到不同的数据库节点上。 这样的话，就能够小幅提升写性能，大幅提升读性能。

3.怎么读写分离？

不论是使用哪一种读写分离具体的实现方案，想要实现读写分离一般包含如下几步：

1. 部署多台数据库，选择其中的一台作为主数据库，其他的一台或者多台作为从数据库。
2. 数据库主机负责读写操作，从机只负责读操作。
3. 保证主数据库和从数据库之间的数据是实时同步的，这个过程也就是我们常说的主从复制。
4. 系统将写请求交给主数据库处理，读请求交给从数据库处理。

4.主从复制延迟问题

以 MySQL 为例，主从复制延迟可能达到 1 秒，如果有大量数据同步，延迟 1 分钟也是有可能的。主从复制延迟会带来一个问题：如果业务服务器将数据写入到数据库主服务器后立刻（1 秒内）进行读取，此时读操作访问的是从机，主机还没有将数据复制过来，到从机读取数据是读不到最新数据的，业务上就可能出现问题。例如，用户刚注册完后立刻登录，业务服务器会提示他“你还没有注册”，而用户明明刚才已经注册成功了。

解决方法

• 读从机失败后再读一次主机

这就是通常所说的“二次读取”，二次读取和业务无绑定，只需要对底层数据库访问的 API 进行封装即可，实现代价较小，不足之处在于如果有很多二次读取，将大大增加主机的读操作压力。例如，黑客暴力破解账号，会导致大量的二次读取操作，主机可能顶不住读操作的压力从而崩溃。

• 关键业务读写操作全部指向主机，非关键业务采用读写分离

例如，对于一个用户管理系统来说，注册 + 登录的业务读写操作全部访问主机，用户的介绍、爱好、等级等业务，可以采用读写分离，因为即使用户改了自己的自我介绍，在查询时却看到了自我介绍还是旧的，业务影响与不能登录相比就小很多，还可以忍受。