MySQL缓存机制深度解析

在深入探讨MySQL缓存机制之前，我们先了解一下主从复制和读写分离这两个关键概念。

主从复制

主从复制是MySQL中常见的高可用性解决方案。主数据库（Master）负责处理所有的写操作，并将变更记录到二进制日志（binlog）中。从数据库（Slave）通过I/O线程读取并复制这些日志，再通过SQL线程应用这些变更，以保持与主数据库的一致性。

• DML操作导致主数据库数据变更，生成binlog文件；


• 从数据库请求读取binlog，开启I/O线程读取主数据库发送过来的日志，并写入中继日志（relaylog）；


• 从数据库通过SQL线程读取relaylog，进行回放，确保数据一致性。

读写分离

读写分离是一种优化读性能的技术，通常应用于高并发场景。具体来说，所有写操作都在主数据库上执行，而读操作则分布在多个从数据库上。虽然这种方法能显著提高读性能，但由于主从同步存在延迟，可能导致从库的数据不是最新的。根据业务需求，可以选择最终一致性和强一致性两种模式：

• 最终一致性： 写主库，读从库，适用于对实时性要求不高的场景。


• 强一致性： 写主库，对于高一致性要求的数据读主库，低一致性要求的数据读从库。

缓存方案

在读多写少的场景下，使用缓存可以有效减轻数据库压力。MySQL自带的缓冲层主要用于缓存热点数据，如数据文件和索引文件。此外，还可以引入外部缓存系统，如Redis或Memcached，它们将数据存储在内存中，访问速度远超磁盘，适合缓存热点数据。

同步问题及解决方案

引入缓存后，可能会出现数据不一致的问题。以下是几种常见情况及其解决方法：

• MySQL有，缓存无： 这种情况下，直接从MySQL读取数据即可。


• MySQL无，缓存有： 可能是脏数据，需清理缓存。


• 都有，但数据不一致： 需要确保数据同步策略正确。


• 都没有： 正常情况，无需特别处理。

强一致性

为了保证强一致性，通常采用以下策略：

• 写流程：先删除缓存，再写MySQL，后续由工具（如go-mysql-transfer）同步数据。


• 删除缓存是为了避免其他服务读取旧数据，确保数据最新。


• 强一致性适用于单数据中心模型，多数据中心可能需要分布式锁或其他复杂方案。

最终一致性

对于最终一致性，有以下两种常见解决方案：

• 直接写MySQL，等待其同步到Redis。


• 先写Redis，设置较短过期时间，等待MySQL同步后再覆盖并延长过期时间。

异常情况及应对措施

缓存穿透

当某个数据在Redis和MySQL中都不存在时，频繁的读取请求会直接打到MySQL，造成压力过大。解决方法包括：

• 将不存在的key设为并设置过期时间，减少无效查询。


• 使用布隆过滤器预判是否存在，减少不必要的查询。

缓存击穿

某些数据只存在于MySQL中，大量并发请求会导致MySQL压力过大。解决方案包括：

• 加锁控制并发，防止同时请求。


• 将热门key设置为永不过期。

缓存雪崩

缓存集中失效会导致大量请求涌向MySQL，可能使服务瘫痪。预防措施包括：

• 采用高可用集群方案，如哨兵模式或Cluster模式。


• 设置随机过期时间，错开失效时间。


• 重启时提前导入热数据，确保快速恢复。