后端存储实战课——高速增长篇

待我称王封你为后i 2023-09-24 15:06 32阅读 0赞

> [《后端存储实战课》][Link 1] 的学习笔记，欢迎阅读斧正。

## 数据库超时 ##

MySQL CPU 的利用率一直是 100% 的话，MySQL 基本属于不可用的状态，执行的 SQL 都会超时。

CPU 利用率高的情况，绝大多数是由于慢 SQL 引起的，可以通过分析慢 SQL 日志查找类似问题原因。由于数据库忙的时候，执行的 SQL 都很慢，所以慢 SQL 日志中的 SQL 不一定都是有问题的，不能简单通过执行次数和执行时长进行判断，但是要关注单词执行时间特别长的 SQL。

给编写 SQL 带来的启示：

1.  SQL 涉及的表是哪些，数据规模如何？
2.  SQL 遍历的数据量是多少？
3.  避免写出慢 SQL

给系统设计带来的启示：

1.  利用缓存减少数据库查询，使用缓存时注意缓存命中率（击穿、穿透、雪崩现象）
2.  做好监控，及时处理
3.  做好降级方案

## 慢 SQL ##

> 一个前提：查询的执行时长基本上是和遍历的数据行数正相关的。

影响 MySQL 处理能力的因素：服务器配置、数据量大小、参数配置、繁忙程度。一台 MySQL 数据库，处理能力的极限大概是每秒一万条简单的 SQL（根据主键查询不需要遍历很多条记录的 SQL），一般一台 MySQL 服务器，平均每秒中执行的 SQL 数量在几百左右就算繁忙了。

一些经验：

1.  如果遍历行数在百万以内的，只要不是每秒钟都要执行几十上百次的频繁查询，可以认为是安全的。遍历数据行数在几百万的，查询时间最少也要几秒钟，你就要仔细考虑有没有优化的办法。遍历行数达到千万量级和以上的，这种查询就不应该出现在你的系统中。当然我们这里说的都是在线交易系统，离线分析类系统另说。
2.  遍历行数在千万左右，是 MySQL 查询的一个坎儿。MySQL 中单个表数据量，也要尽量控制在一千万条以下，最多不要超过二三千万这个量级。原因也很好理解，对一个千万级别的表执行查询，加上几个 WHERE 条件过滤一下，符合条件的数据最多可能在几十万或者百万量级，这还可以接受。但如果再和其他的表做一个联合查询，遍历的数据量很可能就超过千万级别了。所以，每个表的数据量最好小于千万级别。

如果真需要遍历大量数据，两种方案：

1.  使用索引避免全表扫描（增加索引的代价是降低数据插入、删除、更新的性能，对于更新频繁并且对更新性能要求高的表尽量少建索引），关联阅读：[MySQL 索引入门][MySQL]、[MySQL 查询优化][MySQL 1]
2.  分析 SQL 的执行计划，关联阅读：[MySQL explain 使用][MySQL explain]

## 缓存使用 ##

> 更新策略简单贴图，雪崩、击穿、穿透问题不再赘述

Read/Write Through：  
![Read/Write Through][Read_Write Through]  
Cache Aside：  
![Cache Aside][]  
Write Back：Write Back（写回）策略在更新数据的时候，只更新缓存，同时将缓存数据设置为脏的，然后立马返回，并不会更新数据库。对于数据库的更新，会通过批量异步更新的方式进行。

## MySQL 读写分离 ##

### 步骤 ###

#### 部署一主多从 MySQL 实例 ####

参考 [MySQL 官方文档][MySQL 2]

#### 分离应用对数据库的读写请求 ####

1.  手动实现，在 DAO 层做修改
2.  使用 Sharding-JDBC 组件（代码侵入少）
3.  代理方式：在应用程序和数据库实例之间部署一组数据库代理实例，比如说 Atlas 或者 MaxScale。对应用程序来说，数据库代理把自己伪装成一个单节点的 MySQL 实例，应用程序的所有数据库请求被发送给代理，代理分离读写请求，然后转发给对应的数据库实例。（会加长请求的链路，有一定性能损失）

### 主从延迟 ###

1.  如果有插入后立马要求查询到的业务，可以直连主库查询
2.  MySQL 的并行复制
3.  业务上规避（在应用程序和数据库实例之间部署一组数据库代理实例，比如说 Atlas 或者 MaxScale。对应用程序来说，数据库代理把自己伪装成一个单节点的 MySQL 实例，应用程序的所有数据库请求被发送给代理，代理分离读写请求，然后转发给对应的数据库实例）

## MySQL 主从 ##

### 大概步骤 ###

> MySQL 可以通过修改配置的方式来更改下述的时序。  
> 主库需要执行的操作：

1.  提交事务
2.  更新存储的数据
3.  写 binlog
4.  向客户端返回响应
5.  将 binlog 复制到所有从库

从库需要做的：

1.  将上述的 binlog 暂存
2.  回放 binlog
3.  更新对应数据
4.  向主库发送复制成功的响应

### 复制方式 ###

默认情况下，MySQL 采用的是异步复制的方式，因此执行事务操作的线程不会等待复制 binlog 的线程。

异步复制：主库向客户端返回操作成功的响应后，从库中会有专门线程从主库接收 binlog，并将其保存到中继日志中。从库中还有专门用来回放 binlog 的线程，读取中继日志，回收 binlog，更新数据

同步复制：同步复制的时序和异步复制基本是一样的，唯一的区别是，什么时候给客户端返回响应。异步复制时，主库提交事务之后，就会给客户端返回响应；而同步复制时，主库在提交事务的时候，会等待数据复制到所有从库之后，再给客户端返回响应。

半同步复制：异步复制是，事务线程完全不等复制响应；同步复制是，事务线程要等待所有的复制响应；半同步复制介于二者之间，事务线程不用等着所有的复制成功响应，只要一部分复制响应回来之后，就可以给客户端返回了。

## 关联阅读 ##

[后端存储实战课——设计篇][Link 2]

[后端存储实战课——海量数据篇][Link 3]

[Link 1]: http://gk.link/a/11Ted
[MySQL]: https://mindartisan.blog.csdn.net/article/details/106608303
[MySQL 1]: https://mindartisan.blog.csdn.net/article/details/107603173
[MySQL explain]: https://mindartisan.blog.csdn.net/article/details/107595923
[Read_Write Through]: https://img-blog.csdnimg.cn/83f34d65fb84420fb40b117a66d5e800.png
[Cache Aside]: https://img-blog.csdnimg.cn/4ee2117a9ea348d28f77f61a84626dd2.png
[MySQL 2]: https://dev.mysql.com/doc/refman/8.0/en/replication.html
[Link 2]: https://mindartisan.blog.csdn.net/article/details/127877796
[Link 3]: https://mindartisan.blog.csdn.net/article/details/128195418