第28章_mysql缓存策略

最新推荐文章于 2024-05-10 15:55:09 发布

路飞H

最新推荐文章于 2024-05-10 15:55:09 发布

阅读量213

点赞数

分类专栏： MySQL 文章标签： mysql 缓存数据库

本文链接：https://blog.csdn.net/qq_29750559/article/details/134367391

版权

本文探讨了MySQL缓存方案的选择、作用、场景分析，以及提升访问性能的方法，包括读写分离、连接池和异步连接。重点介绍了缓存与MySQL一致性状态，如何制定读写策略，以及缓存方案的故障问题及其解决策略，如缓存穿透、击穿和雪崩的处理。

摘要由CSDN通过智能技术生成

前提：读多写少，单个主节点能支撑项目数据量；数据的主要依据是mysql。

MySQL缓存方案目的分析

mysql 有自己缓冲层，它的作用也是用来缓存热点数据，这些数据包括索引、记录等。mysql 缓冲层是从自身出发，跟具体的业务无关。这里的缓冲策略主要是 lru。

mysql 数据主要存储在磁盘当中，适合大量重要数据的存储；磁盘当中的数据一般是远大于内存当中的数据。

一般业务场景的关系型数据库（mysql）是作为主要数据库的。

缓存层作用

MySQL缓存方案用来缓存用户定义的热点数据，用户直接从缓存获取热点数据，降低数据库的读写压力。

举例

比如说12点有一个促销活动，用户可以在12点之前预约，则12点之前预约的用户可称为热点数据，到12点的时候会有大量用户登录，这将对mysql造成很大压力，所以需要提前缓存预约的用户数据，因为mysql自带的缓存不适合用户定义的热点数据。此时可以考虑使用redis来缓存预约的用户数据，并且需要设置过期时间，因为12点之后可能过1小时活动就结束了，所以考虑过期时长为13：00 - 预约的时间。

缓存方案选择

缓存数据库可以选用 redis，memcached；它们所有数据都存储在内存当中，当然也可以将内存当中的数据持久化到磁盘当中。

场景分析

（1）内存访问速度是磁盘访问速度10W倍，访问磁盘的速度比较慢，尽量使获取数据是从内存中获取。

（2）读的需求远远大于写的需求。主要解决读的性能；因为写没必要优化，必须让数据正确的落盘。如果写性能出现问题，那么请使用横向扩展集群方式来解决。

（3）MySQL自身缓冲层跟业务无关。由于 mysql 的缓冲层不由用户来控制，也就是不能由用户来控制缓存具体数据。

（4）MySQL作为项目主要数据库，便于统计分析。项目中需要存储的数据应该远大于内存的容量，同时需要进行数据统计分析，所以数据存储获取的依据应该是关系型数据库。

（5）缓存数据库作为辅助数据库，存放热点数据。缓存数据库可以存储用户自定义的热点数据。

提升MySQL访问性能的方式

（1）读写分离。

（2）连接池。

（3）异步连接。

（4）预处理。

（5）更换存储引擎。

（6）分库分表。（淘汰的技术）

（7）mycat。（淘汰的技术）

（8）tidb。

MySQL主从复制

在这里插入图片描述

主库更新事件 ( update、insert、delete ) 通过 io-thread写到 binlog。
从库请求读取 binlog，通过 io-thread 写入从库本地 relay log（中继日志）。
从库通过 sql-thread 读取 relay-log，并把更新事件在从库中重放（replay）一遍。

复制流程：

Slave 上面的 IO 线程连接上 Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容。
Master 接收到来自 Slave 的 IO 线程的请求后，负责复制的IO 线程会根据请求信息读取日志指定位置之后的日志信息，返回给 Slave 的 IO 线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到 Master 端的 binlog 文件的名称以及 binlog 的位置。
Slave 的 IO 线程接收到信息后，将接收到的日志内容依次添加到 Slave 端的 relay-log 文件的最末端，并将读取到的Master 端的 binlog 的文件名和位置记录到master-info 文件中，以便在下一次读取的时候能够清楚的告诉 Master 从何处开始读取日志。
Slave 的 sql 进程检测到 relay-log 中新增加了内容后，会马上解析 relay-log 的内容成为在 Master 端真实执行时候的那些可执行的内容，并在自身执行。

由于MySQL的主从复制是异步的，所以同一时刻主数据库和从数据库的数据可能存在不一致的现象，这就造成可能从数据库中读取的数据不是最新的。