Redis 典型应用——缓存（缓存预热，穿透，雪崩，击穿）

一、缓存

缓存是计算机中一个很经典的概念，核心思路是把一些常用的数据放到访问速度更快的地方，方便随时读取；

但对于计算机硬件来说，往往访问速度越快的设备，成本越高，存储空间越小，缓存是更快，但空间上是不足的，因此大部分时候，缓存只存放一些热点数据；

二、Redis 用作缓存

在一个网站中，我们经常会使用关系型数据库来存储数据（例如 MySQL），虽然关系型数据库功能强大，但是性能不高（进行一次查询操作消耗的系统资源较多），性能不高的原因体现为：

• 数据库把数据存储在硬盘上，硬盘的 IO 速度并不快，尤其是随机访问；
• 如果查询没有命中索引，就需要进行表的遍历，大大增加硬盘 IO 次数；
• 关系型数据库对于 SQL 的执行会做一系列的解析，校验，优化工作；
• 如果是一些复杂查询，如联合查询，需要进行笛卡尔积操作，效率更是降低很多；

因此，如果访问数据库的并发量比较高，就很容易使数据库服务器宕机；服务器每处理一次请求，都要消耗一定的硬件资源的（CPU，内存，硬盘，网络带宽等），当一个服务器的硬件资源被耗尽的时候，后续的请求没有资源可用，就无法处理请求，甚至导致服务器代码出现崩溃； 

让数据库能够承担更大的并发量的措施主要有以下两个思路

• 开源：引入更多的机器，部署更多的数据库实例，构成数据库集群；
• 节流：引入缓存，保存经常访问的热点数据，从而降低直接访问数据库的请求数量；

Redis 就是一个用来作为数据库缓存的常见方案；

Redis 访问速度比 MySQL 快很多，或者说处理同一个访问请求，Redis 消耗的系统资源比  MySQL 少很多，因此 Redis 能支持的并发量更大，并且 Redis 数据在内存中，访问内存比硬盘快很多，Redis 只是支持简单的 key-value 存储，不涉及复杂查询的那么多限制规则； 

当客户端访问业务服务器，发起查询请求，业务服务器先查询 Redis，看要查询的数据是否在 Redis 中存在，如果在 Redis 中，则就直接返回，此时就不会访问 MySQL 了，如果在 Redis 中不存在，再去查询 MySQL；

缓存是用来加快 "读操作" 的速度的，如果是 "写操作"，还是要写数据库，缓存并不能提高性能；

三、缓存的更新策略

缓存中应该存储哪些数据呢？如何知道哪些数据是热点数据呢？

1. 定期生成

每隔一定的周期（比如一天/一周/一个月），对于访问的数据频次进行统计（写程序来统计），挑选出访问频次最高的前 N% 的数据，存储在缓存中；

• 优点：实现起来较简单，过程更可控（缓存中有什么是固定，更方便排查问题）；
• 缺点：实时性较低，对于一些突然情况应对的并不好；
  • 例如：平时很少会有人搜索 "春晚"，因此这个关键词就不会在缓存中，而在除夕夜时，这个词就会成为非常高频的词，导致缓存失效；

2. 实时生成

先给缓存设定容量上限（可以通过 Redis 配置文件的 maxmemory 参数设定）然后用户每次查询

• 如果在 Redis 中查到了，就直接返回；
• 如果在 Redis 中不存在，就从数据库中查找，如果在数据库中查到了，则将查到的结果写入 Redis，否则，说明数据库中也不存在该数据；

当缓存满了的时候（缓存容量达到上限），就会触发缓存淘汰策略，把一些 "不太热门的数据" 淘汰掉；

常见的缓存淘汰策略

• FIFO（First In First Out）先进先出：把缓存中存在时间最久的 key（最先存的）淘汰掉；
• LRU（Least Recently Used）淘汰最久未使用的：记录每个 key 的最近访问时间，把最近访问时间最老的 key 淘汰掉；
• LFU（Least Frequently Used）淘汰访问次数最少的：记录每个 key 最近一段时间的访问次数，把访问次数最少的 key 淘汰掉；
• Random 随机淘汰：从所有的 key 中随机进行淘汰；

Redis 内置的淘汰策略

volatile-lru：当内存不足以容纳新写入数据时，从设置了过期时间的 key 中使用 LRU（最近最少使用）算法进行淘汰  ；

allkeys-lru：当内存不足以容纳新写入数据时，从所有 key 中使用 LRU（最近最少使用）算法进 行淘汰；

volatile-lfu 4.0 版本新增：当内存不足以容纳新写入数据时，在过期的 key 中，使用 LFU 算法进行删除 key；

allkeys-lfu 4.0 版本新增：当内存不足以容纳新写入数据时，从所有 key 中使用 LFU 算法进行淘汰；

volatile-random：当内存不足以容纳新写入数据时，从设置了过期时间的 key 中，随机淘汰数 据；

allkeys-random：当内存不足以容纳新写入数据时，从所有 key 中随机淘汰数据；

volatile-ttl：在设置了过期时间的 key 中，根据过期时间进行淘汰，越早过期的优先被淘汰；(相当于 FIFO，只不过是局限于过期的 key)   ；

noeviction：默认策略，当内存不足以容纳新写入数据时，新写入操作会报错；

下面内容以使用 Redis 作为 MySQL 的缓存为例

四、缓存预热（Cache preheating）

1. 解释

当 Redis 刚刚启动，或者 Redis 大批 key 失效之后，此时由于 Redis 内部相当于是空着的，没啥缓存数据，那么 MySQL 就会被直接访问到，从而使 MySQL 面临较大的压力；

2. 解决办法

因此就需要提前把热点数据准备好，直接写入到 Redis 中，使 Redis 可以尽快为 MySQL 撑起保护伞，热点数据可以基于统计生成；

这份热点数据不一定非得那么 "准确"，只要能帮 MySQL 抵挡大部分请求即可，随着程序运行的推移，缓存的热点数据会逐渐自动调整，来更适应当前情况；

五、缓存穿透（Cache penetration）

1. 解释

访问的 key 在 Redis 和数据库中都不存在，此时这样的 key 不会被放到缓存上，后续如果仍然在访问该 key，依然会访问到数据库，这就会导致数据库承担的请求太多，压力很大；

2. 产生原因

• 业务设计不合理，比如缺少必要的参数校验环节，导致非法的 key 也被进行查询了；
• 误操作不小心把部分数据从数据库上误删了；
• 黑客恶意攻击

3. 解决办法

• 针对数据库上也不存在的 key，也存储到 Redis 中，比如 value 就随便设成一个 ""，避免后续频繁访问数据库；
• 使用布隆过滤器（hash + bitmap）先判定 key 是否存在，再真正查询；

六、缓存雪崩（Cache avalanche）

1. 解释

短时间大量的 key 在缓存上失效，导致数据库压力骤增，甚至宕机；比如，我们在同一时间，针大量的 key 设置了相同的过期时间，那当过期时间到来时，大量的 key 就会被删除从而失效；

2. 产生原因

• Redis 宕机；
• Redis 上大量的 key 同时过期；

3. 解决办法

• 部署高可用的 Redis 集群，并且完善监控报警体系；
• 不给 key 设置过期时间，或设置过期时间时添加随机时间因子（避免同时过期）；

七、缓存击穿（Cache breakdown）

1. 解释

缓存雪崩的特殊情况，针对热点 key，突然过期了，导致大量访问该 key 的请求直接访问到数据库，引起数据库宕机；

2. 解决办法

• 基于统计的方式发现热点 key，并设置永不过期或逻辑过期；
• 访问数据库时，使用分布式锁，限制同时请求数据库的并发数；