Redis 会把 MySQL 中经常被查询的数据缓存起来，比如热点数据，这样当用户来访问的时候，就不需要到 MySQL 中去查询了，而是直接获取 Redis 中的缓存数据，从而降低了后端数据库的读取压力。如果说用户查询的数据 Redis 没有，此时用户的查询请求就会转到 MySQL 数据库，当 MySQL 将数据返回给客户端时，同时会将数据缓存到 Redis 中，这样用户再次读取时，就可以直接从 Redis 中获取数据。 本篇内容包括：关于 Redis 缓存，缓存相关问题（包括 Redis 缓存热 key 问题、Redis 缓存穿透问题、关于布隆过滤器、Redis 缓存击穿问题 与 Redis 缓存雪崩问题的相关内容），Redis 缓存预热，Redis 缓存过期与内存淘汰策略。
文章目录- 一、关于 Redis 缓存
- 1、Redis 如何实现缓存
- 2、Redis 缓存更新策略
- 1、Redis 如何实现缓存
- 2、Redis 缓存更新策略
- 二、缓存相关问题
- 1、Redis 缓存热 key 问题
- 2、Redis 缓存穿透问题
- 3、关于布隆过滤器
- 4、Redis 缓存击穿问题
- 5、Redis 缓存雪崩问题
- 三、Redis 缓存预热
- 四、Redis 缓存过期与内存淘汰策略
- 1、Redis 的缓存过期策略
- 2、Redis 的内存淘汰策略
一、关于 Redis 缓存
1、Redis 如何实现缓存
在请求达到后端之后，对需要进行缓存的接口，会先去 Redis 中找有无数据，没有的话会继续走正常的业务流程，然后将查询到的结果返回给客户端的同时也放在 Redis 中一份，下次相同请求进来后，就可以直接从 Redis中 拿到数据。
在进行缓存之后，相同的请求在缓存时间内是不会去读取数据库的，但是此时如果修改了数据库，则接口返回的数据就不能保证和数据库一致，因此在增、删、改时我们需要刷新缓存。
2、Redis 缓存更新策略
缓存更新的策略有很多，这里比较两种情况
- 第一种情况，先更新数据库再同步更新缓存或者先更新缓存再同步更新数据库，其实都属于 write through，同步更新的好处在于可以很好的保持数据的一致性，但是缺点在于同步更新时，必然会影响性能；
- 第二种情况，先更新缓存，然后再异步写回数据库，也就是 write back，异步写回的好处在于不会影响缓存的高性能，能够快速响应客户端，但是缺点在于在数据异步写回到数据库之前，存在缓存和数据库数据短暂不一致。
二、缓存相关问题
1、Redis 缓存热 key 问题
所谓热 key 问题就是，突然有几十万的请求去访问 Redis 上的某个特定 key，那么这样会造成流量过于集中，达到物理网卡上限，从而导致这台 Redis 的服务器宕机引发雪崩。
针对热 key 的解决方案：
- 提前把热 key 打散到不同的服务器，降低压力
- 二级缓存，提前加载热 key 数据到内存中，如果 redis 宕机，走内存查询
2、Redis 缓存穿透问题
访问一个缓存和数据库都不存在的 key，此时会直接打到数据库上，并且查不到数据，没法写缓存，所以下一次同样会打到数据库上。此时，缓存起不到作用，请求每次都会走到数据库，流量大时数据库可能会被打挂。此时缓存就好像被“穿透”了一样，起不到任何作用。
缓存穿透解决方案：
- 接口校验：在正常业务流程中可能会存在少量访问不存在 key 的情况，但是一般不会出现大量的情况，所以这种场景最大的可能性是遭受了非法攻击。可以在最外层先做一层校验：用户鉴权、数据合法性校验等，例如商品查询中，商品的 ID 是正整数，则可以直接对非正整数直接过滤等等。
- 缓存空值：当访问缓存和 DB 都没有查询到值时，可以将空值写进缓存，但是设置较短的过期时间，该时间需要根据产品业务特性来设置。
- 布隆过滤器：使用布隆过滤器存储所有可能访问的 key，不存在的 key 直接被过滤，存在的 key 则再进一步查询缓存和数据库。
3、关于布隆过滤器
布隆过滤器的特点是判断不存在的，则一定不存在；判断存在的，大概率存在，但也有小概率不存在。并且这个概率是可控的，我们可以让这个概率变小或者变高，取决于用户本身的需求。
布隆过滤器由一个 bitSet 和 一组 Hash 函数（算法）组成，是一种空间效率极高的概率型算法和数据结构，主要用来判断一个元素是否在集合中存在。
HashMap 和 布隆过滤器：其实当数据量不大时，HashMap 实现起来一点问题都没有，而且还没有误判率。不过，当数据量上去后，布隆过滤器的空间优势就会开始体现，特别是要存储的 key 占用空间越大，布隆过滤器的优势越明显。
4、Redis 缓存击穿问题
某一个热点 key，在缓存过期的一瞬间，同时有大量的请求打进来，由于此时缓存过期了，所以请求最终都会走到数据库，造成瞬时数据库请求量大、压力骤增，甚至可能打垮数据库。
缓存击穿解决方案：
- 加互斥锁：在并发的多个请求中，只有第一个请求线程能拿到锁并执行数据库查询操作，其他的线程拿不到锁就阻塞等着，等到第一个线程将数据写入缓存后，直接走缓存。因为这个可以保证只有一个请求会走到数据库；
- 热点数据不过期：直接将缓存设置为不过期，然后由定时任务去异步加载数据，更新缓存。这种方式适用于比较极端的场景，例如流量特别特别大的场景，使用时需要考虑业务能接受数据不一致的时间，还有就是异常情况的处理，不要到时候缓存刷新不上，一直是脏数据，那就凉了。
5、Redis 缓存雪崩问题
大量的热点 key 设置了相同的过期时间，导在缓存在同一时刻全部失效，造成瞬时数据库请求量大、压力骤增，引起雪崩，甚至导致数据库被打挂。缓存雪崩其实有点像“升级版的缓存击穿”，缓存击穿是一个热点 key，缓存雪崩是一组热点 key。
缓存雪崩解决方案
- 过期时间打散。既然是大量缓存集中失效，那最容易想到就是让他们不集中生效。可以给缓存的过期时间时加上一个随机值时间，使得每个 key 的过期时间分布开来，不会集中在同一时刻失效；
- 加互斥锁。该方式和缓存击穿一样，按 key 维度加锁，对于同一个 key，只允许一个线程去计算，其他线程原地阻塞等待第一个线程的计算结果，然后直接走缓存即可；
- 热点数据不过期。该方式和缓存击穿一样，也是要着重考虑刷新的时间间隔和数据异常如何处理的情况。
三、Redis 缓存预热
缓存预热就是系统上线后，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！
- 请求数量较高
- 主从之间数据吞吐量较大，数据同步操作频度较高
缓存预热就是系统启动前，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题!用户直接查询事先被预热的缓存数据!
缓存预热解决方案：
- 日常例行统计数据访问记录，统计访问频度较高的热点数据
- 利用 LRU 数据删除策略， 构建数据留存队列例如：Storm 与 Kafka 配合
- 将统计结果中的数据分类， 根据级别， Redis 优先加载级别较高的热点数据
- 利用分布式多服务器同时进行数据读取，提速数据加载过程
缓存预热实施：
- 使用脚本程序固定触发数据预热过程
- 如果条件允许， 使用了 CDN（内容分发网络）， 效果会更好。
四、Redis 缓存过期与内存淘汰策略
1、Redis 的缓存过期策略
Redis 主要有 2 种过期删除策略：
- 惰性删除指的是当我们查询 key 的时候才对 key 进行检测，如果已经达到过期时间，则删除。显然，他有一个缺点就是如果这些过期的 key 没有被访问，那么他就一直无法被删除，而且一直占用内存；
- 定期删除指的是 Redis 每隔一段时间对数据库做一次检查，删除里面的过期 key。由于不可能对所有 key 去做轮询来删除，所以 Redis 会每次随机取一些 key 去做检查和删除。
2、Redis 的内存淘汰策略
假设 Redis 每次定期随机查询 key 的时候没有删掉，这些 key 也没有做查询的话，就会导致这些 key 一直保存在 Redis 里面无法被删除，这时候就会走到 Redis 的内存淘汰策略。
Redis 的 内存淘汰策略是指在 Redis 的用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。
- volatile-lru：从已设置过期时间的 key 中，移除最近最少使用的key进行淘汰
- volatile-ttl：从已设置过期时间的 key 中，移除将要过期的 key
- volatile-random：从已设置过期时间的 key 中随机选择 key 淘汰
- allkeys-lru：从 key 中选择最近最少使用的进行淘汰
- allkeys-random：从 key 中随机选择 key 进行淘汰
- noeviction：当内存达到阈值的时候，新写入操作报错
Redis 的内存淘汰策略的选取并不会影响过期的 key 的处理。内存淘汰策略用于处理内存不足时的需要申请额外空间的数据；过期策略用于处理过期的缓存数据。
