MySQL的缓存策略
目录
一、MySQL 缓存方案用来干什么
二、提升MySQL访问性能的方式
1、读写分离（MySQL的主从复制）
2、连接池
3、异步连接
三、缓存方案是怎么解决的
1、缓存与MySQL一致性状态分析
2、制定热点数据的读写策略
四、缓存方案问题的解决方法
1、缓存穿透
2、缓存击穿
3、缓存雪崩
五、缓存方案的弊端
一、MySQL 缓存方案用来干什么
用来缓存用户定义的热点数据，用户直接从缓存获取热点数据，降低数据库的读写压力。
我们都知道内存的读取速度是磁盘访问速度的十万倍，那么这个缓存方案适用于什么场景呢？
1、既然读取速度这么高，那么肯定就是读的需求远大于写的需求。
2、MySQL自身的缓冲层跟业务无关。MySQL中的缓存层也是用来缓存热点数据，但是这些数据包括索引、记录等。mysql 缓冲层是从自身出发，跟具体的业务无关，而不是缓存我们用户自己定义的热点数据。
3、因此我们采用Redis作为我们的缓冲数据库，存放用户定义的热点数据。而MySQL只是作为项目的主要数据库，便于统计分析。
二、提升MySQL访问性能的方式
1、读写分离（MySQL的主从复制）
什么是读写分离？我们设置多个从数据库，从数据库分布在多个不同的机器中，我们写的操作依然是在主数据库，而读的操作分给了从数据库，从数据库的数据都是来自主数据库。这样将读写进行分离，会解决主数据库读的压力。
我之前的文章讲过主从之间如何进行同步。我们得知主从之间可能会存在数据不一致的情况，但是最终的数据是一样的，也就是可能会有延迟。比如博主写了一篇文章并且刚刚发布，但是我的朋友说还没有看到，我说你等个几秒就好了。对于这种情况就很适合这种方案（读取从数据库）。
但是对于读的时效性很强的时候（一致性），我们就不可以读取从数据库了，而是直接读取主数据库。
2、连接池
在MySQL中存在连接池的组件，比如两个客户端连接上来，但是我们使用多个线程去服务这几个客户端，可以大大提高并发访问数据库的能力，并且，连接池的资源是可以复用的，我们可以避免连接建立或断开，以及安全验证的开销。
他的网络模型采用的并不是Reactor，而是select+阻塞io模型。对于上面所说的多个线程服务客户端，这里要特别注意，如果我们开启一个事务的话，一个事务内不是包含很多SQL语句嘛，我们要保证这些事务语句全部在一个线程内执行。
3、异步连接
我们上面的连接池中讲到了网络模型采用的是 select + 非阻塞IO 。如果是阻塞IO的话也就是同步方式，我们发送多个SQL语句的话，他需要一个一个进行执行并且一个一个进行返回。
但是我们采用异步的方式（非阻塞IO），我们发送多个命令，那么这些命令会异步执行，谁执行完毕，谁就通过回调函数进行返回，大大节省网络传输的时间。
三、缓存方案是怎么解决的
1、缓存与MySQL一致性状态分析
| 可行方案 | 不可行方案 |
| MySQL有，Redis无 | MySQL无，Redis有 |
| 都有，数据一致 | 都有，数据不一致 |
| 都没有 |
我们根据上面所讲述的主从复制，可以得知，MySQL中必须保存全部的数据，而Redis从数据库只是保存热点数据。那么我们来讨论上面这个表格的情况。
可行方案中：MySQL有，Redis无。MySQL没有热点数据需要进行存储，所以Redis中没有数据，也就是说，用户查找的这个数据并不是热点数据。
第二种方案：都有，数据一致。MySQL中包含热点数据，而且Redis中也包含热点数据，并且是一致的数据。这样我们查找从数据库的时候，就不会出现与主数据库查询不同的情况了。
第三种：都没有。也就是说用户查找的这个数据是不存在的，所以在MySQL中也不存在。
不可行方案：MySQL无，Redis有。我们讲的主从复制，需要保证写数据是写在主数据库中的，所以主数据库包含全部的信息，而从数据库是从主数据库中进行同步的。所以这种情况是不允许的。
不可行方案：都有，数据不一致。我们讲的主从复制中也说到了从数据库与主数据库进行同步可能会有延迟，但是最终数据是一致的。这样就会导致我们可能读取从数据库的时候（读取热点数据）可能会导致与主数据库的数据不一致。
2、制定热点数据的读写策略
对于读的策略比较简单，由于是热点数据，我们直接读取缓存（Redis），如果在Redis中找到了数据，那就直接返回。如果未找到，那就读取MySQL，如果在MySQL中读到数据，并且返回后，那就写入Redis。这里写入Redis中的是热点数据，并不是说，一查没有，一查没有，就全部写入Redis中。
写的策略分两种，一种是安全为主，一种是效率为主。
如果要以安全为主，我们就要避免主数据库和从数据库读取的数据不同的问题。当我们先写入MySQL后，必然会出现MySQL与Redis数据不同的问题，那么我们就不能先写入MySQL。而是要先删除Redis中的数据，然后再写入MySQL，最后将MySQL中的数据同步到Redis中去，这样就保证两方的数据一致了。但是我们的缓存方案就是为了提升效率，现在却为了安全而降低了效率，这是我们不愿看到的。
如果要以效率为主，我们可以先写入缓存，并且设置过期时间（大约是200毫秒），然后再写入MySQL，当写入MySQL后，我们再将MySQL中的数据同步到Redis中去。当同步到Redis中去的时候，这个过期时间也就到期了。过期时间是与MySQL网络传输时间+MySQL处理时间+MySQL同步到Redis的时间。有个问题是如果当写入MySQL写入失败，这个时候Redis中含有数据，那么他就会提供脏数据。但是这个问题也就200毫秒的存活时间，因为从数据库会找主数据库进行同步。
四、缓存方案问题的解决方法
1、缓存穿透
问题：如果黑客让客户端一直读取MySQL和Redis中都不存在的数据，那么所有的读取操作都落在了MySQL中，那么就会造成MySQL中访问的性能急剧降低。
解决：如果在Redis和MySQL中读取的数据都不存在，那么就在Redis中设置一个<Key,nil>，代表查找的这个热点数据不存在。或者部署布隆过滤器（类似于哈希表），使这些数据只能增加，不能删除，具体可以搜一搜。
2、缓存击穿
问题：如果Redis中没有，但是MySQL中有，也就是说本来一个热点数据，在Redis中存在，但是过期了，那么大量的并发请求读取操作就会落到MySQL中，这样就造成MySQL访问的性能急剧降低。
解决：我们可以将过热的数据设置成不过期的状态。或者是添加分布式锁，将并发的请求操作，变成串行执行。
3、缓存雪崩
问题：我们在写入Redis中的数据是需要加入过期时间的，但是当我们不小心将多个过热数据的过期时间设置成统一时间，就会面临大量热点数据集中失效的问题，虽然失效，但是在MySQL中还是存在这个数据，所以大量的请求读取操作就会落到MySQL中去，就会造成MySQL访问性能急剧降低。
解决：我们可以将这个过期时间给错开，避免同时过期。当然我们可以在重启MySQL的时候，先将一些热数据先缓存到Redis中。
五、缓存方案的弊端
我们上面讲到一个问题就是，不能支持多语句的事务，如果要支持的话，需要保证begin到commit之间的全部语句都在一条线程中执行。而且Redis不支持回滚，并且有时候会造成Redis与MySQL数据不一致。
感谢大家的观看！0voice · GitHub