目录

一、Redis 作为缓存

1.1、缓存的基本概念

1.1.1、理解

1.1.2、缓存存什么样的数据？二八定律

1.2、如何使用 redis 作为缓存

1.3、缓存更新策略（redis 内存淘汰机制 / 重点）

1.3.1、定期生成

1.3.2、实时生成

内存淘汰策略（经典面试）

1. FIFO (First In First Out) ：先进先出

2. LRU (Least Recently Used) ：淘汰最久未使⽤的

3. LFU (Least Frequently Used) ：淘汰访问次数最少的

4. Random 随机淘汰

深入理解淘汰策略：

redis 中采用的淘汰策略

1.4、缓存使用的注意事项（重点）

1.4.1、缓存预热（Cache preheating）

1.4.2、缓存穿透（Cache penetration）

1.4.3、缓存雪崩（Cache avalanche）

1.4.4、缓存击穿（Cache breakdown）

---

一、Redis 作为缓存

---

1.1、缓存的基本概念

1.1.1、理解

缓存可以理解为，将常用的数据从放到一个访问速度更快的的地方，方便更快的随时读取.

也就是说，速度快的设备，可以作为速度慢的设备的缓存，加快读取速度。在计算机硬件中的访问速度如下：

• CPU 寄存器 > 内存 > 硬盘 > 网络

最常见的就是，使用 内存 作为 硬盘 的缓存，比如 redis.....  

当然 硬盘 也可以作为 网络 的缓存，比如浏览器通过 http/https 从服务器上获取数据（html、css、js、图片、视频......）并进行展示，像这样体积大，但又不经常改变的数据，就可以保存到浏览器本地硬盘上，后续在打开这个页面，就不必重新从网络获取上述数据了.

1.1.2、缓存存什么样的数据？二八定律

缓存速度虽然快，但是空间小，因此大部分情况，缓存只存放一些热点数据，就非常有用了.

这里就不得不提一下二八定律了，就是说缓存 只需要存储 20% 的热点数据，就可以应对 80% 的请求.

1.2、如何使用 redis 作为缓存

我们通常使用 redis 作为 数据库（mysql）的缓存.

这是由于，数据库是非常重要的组件，但是速度又很慢，一旦短时间内有大量请求来临，就有可能使数据库压力过大，导致宕机.

为什么会压力过大，导致宕机？

服务器每次处理一个请求，都要消耗一些硬件资源（cpu、内存、硬盘、网络......），任何一种资源的消耗超出了机器提供的上限，就很容易出现故障了.

如何提高 mysql 能承担的并发量？

1. 开源：引入更多的机器，构成数据库集群，例如 主从复制（即使主节点宕机，也可以通过提升从节点为主节点来解决）、分库分表.....

2. 节流：引入缓存，就是典型的方案. 把一些频繁的读取的热点数据保存到缓存上，后续再查询数据的时候，如果缓存已经存在了，就直接把从缓存上读到的数据返回，也就不在访问 mysql 了.

1.3、缓存更新策略（redis 内存淘汰机制 / 重点）

实际的工作中，如何知道 redis 中应该存储哪些数据？如何知道哪些数据使热点数据？

这就得看你使用缓存的哪种更新策略了~

1.3.1、定期生成

每隔⼀定的周期 (比如⼀天/⼀周/⼀个⽉) , 对于访问的数据频次进⾏统计，并以日志的形式记录下来，最后挑选出访问频次最⾼的前 N% 的数据，放到缓存中.

例如搜索引擎.

搜索引擎的 “查询词” 就是要关注的 “访问的数据”，通过日志，把每天（也可以按一周、一月）都使用到了哪些词，给记录下来，就可以针对这些日志进行统计（这里的统计数据量非常大，需要写个程序来统计，数量大到可能需要使用分布式系统来存储日志 HDFS），统计这一天中，每个词出现的频率，再根据频率降序排序，提取出 前 20% 的词，就可以认为这些词是 “热点词” .

接下来就可以把这些热点词，以及涉及到的搜索结构都提前拎出来，放到类似 “ redis” 这样的缓存中了。

如何定期统计呢？

可以写一套离线流程（往往使用 shell，python 写脚本代码），然后通过 定时任务 来触发（一天更新一次、一个月更新一次......），具体的：

a）完成统计热词的过程.

b）根据热词，找到搜索结果的数据.

c）把得到缓存数据同步到缓存服务器上.

d）控制这些缓存服务器自动重启.

定期生成的优缺点

优点：实现起来比较简单，过程可控（缓存中有什么东西，是比较固定的），方便排查问题.

缺点：实时性不够，如果出现一些突发性的事件，出现了一些新的热点词，新的热词就可能对数据库带来较大的压力（缓存中查询没有，直接打到数据库），例如，过年的前几天，“春节晚会” 这个词就会变的特别高频、或者是某个突发的新闻......

1.3.2、实时生成

先给缓存设定容量上限（可以通过 Redis 配置⽂件的 maxmemory 参数设定）.

接着，之后用户每次查询：

• 如果在 Redis 中查到了，就直接返回.
• 如果 Redis 中没有，就从数据库查询，在把查到的结果写入 Redis.

经过一段时间的 “动态平衡” ，redis 中的 key 就逐渐变成了 热点数据.

但是这样不停的写，redis 中的数据就会越来越多，达到 redis 配置的容量上限之后怎么办？

内存淘汰策略（经典面试）

为了解决上述问题，就可以使用以下四种 “内存淘汰策略” （以下淘汰策略不局限于 redis）：

1. FIFO (First In First Out) ：先进先出

把缓存中存在时间最久的 (也就是先来的数据) 淘汰掉.

2. LRU (Least Recently Used) ：淘汰最久未使⽤的

记录每个 key 的最近访问时间. 把最近访问时间最⽼的 key 淘汰掉.

3. LFU (Least Frequently Used) ：淘汰访问次数最少的

记录每个 key 最近⼀段时间的访问次数. 把访问次数最少的淘汰掉

4. Random 随机淘汰

从所有的 key 中抽取幸运儿被随机淘汰掉

深入理解淘汰策略：

假如在 甄嬛传 中，你是那个皇上，后宫佳丽三千，但实际上，你能宠幸的妃子也就那么几个（精力有限），相当于热点数据.

今天选秀一批新的小主，而你看上了其中的一个，那么就意味着后宫必有人失宠，那么到底要冷落谁呢？

FIFO：皇后最老，先冷落了.

LRU：找个太监统计最近的宠幸时间，比如，皇后(10天前)、华妃（一个月前）、熹妃（一天前），那么华妃失宠.

LFU：找个太监统计最近的宠幸次数，比如，皇后（6次）、华妃（1次）、熹妃（10次），那么华妃失宠.

Random：随机冷落一个妃子.

redis 中采用的淘汰策略

• volatile-ttl（相当于 FIFO, 只不过是局限于过期的 key） 在设置了过期时间的key中，根据过期时间进行淘汰，越早过期的优先被淘汰. 
• volatile-lru（就是 LRU，只不过局限于过期的 key） 当内存不足以容纳新写⼊数据时，从设置了过期时间的key中使⽤LRU（最近最少使用）算法进行淘汰.
• allkeys-lru（就是 LRU，针对所有 key） 当内存不⾜以容纳新写⼊数据时，从所有key中使⽤LRU（最近最少使用）算法进行淘汰
• volatile-lfu（就是 LFU，只不过局限于过期的 key） 4.0版本新增，当内存不⾜以容纳新写⼊数据时，在过期的key中，使⽤LFU算法 进行删除key.
• allkeys-lfu（就是 LFU，针对所有 key） 4.0版本新增，当内存不⾜以容纳新写⼊数据时，从所有key中使⽤LFU算法进行淘汰.
• volatile-random 当内存不⾜以容纳新写⼊数据时，从设置了过期时间的key中，随机淘汰数据.
• allkeys-random 当内存不⾜以容纳新写⼊数据时，从所有key中随机淘汰数据.
• noeviction 默认策略，当内存不⾜以容纳新写⼊数据时，新写⼊操作会报错.

1.4、缓存使用的注意事项（重点）

1.4.1、缓存预热（Cache preheating）

这里主要针对缓存更新策略是 实时生成的（定期生成 不涉及 “预热” ）.

为什么要预热？

redis 服务器首次接入之后，服务器是没有数据的，此时所有请求都会直接打给 mysql，在 redis 上没查到，而在 mysql 上查到的数据会继续写入 redis，随着时间推移，redis 上的数据越积累越多 mysql 承担的压力才逐渐变小 .

那么没预热前，mysql 的压力是相当大的.

如何解决上述问题？

通过缓存预热，就可以解决. 主要就是，把缓存 定期生成 和 实时生成 结合一下.

具体的，先通过离线的方式，通过一些统计途径，统计一些热点数据，导入到 redis 中，此时导入的这批热点数据，就能帮 mysql 承担很大压力了.

随着时间的推移，逐渐就使用新的热点数据淘汰旧数据了.

1.4.2、缓存穿透（Cache penetration）

查询某个 key ，在 redis 中没有，mysql 中也没有，这个 key 也就不会更新到 redis 中。

这就导致，这次查询没有，下次查，还是没有....... 如果这样的数据很多，并且反复查询，一样会给 mysql 带来很大压力.

如何处理？

首先是一种亡羊补牢的方式：通过改进业务/加强监控警报，但这都是出现事故，才采取的行为.

更靠谱的方案（降低问题的严重性）：

1. 如果这个 key 在 redis 和 mysql 上都不存在，仍然把这个 key 写入 redis，value 设置成一个非法值，比如 "".

2. 引入布隆过滤器. 每次查询 redis / mysql 之前都先判定一下 key 是否在 布隆过滤器 上存在（布隆过滤器本质上是结合 hash + bitmap 实现的，以比较小的空间开销和比较快的速度，针对 key 是否存在进行判定），不存在就没必要查了.

1.4.3、缓存雪崩（Cache avalanche）

在短时间内，redis 中大规模的 key 失效，导致缓存命中率陡然下降，并且 mysql 的压力迅速上升，甚至直接宕机.

redis 上为什么会出现 大规模的 key 失效？

1. redis 直接挂了，比如 redis 宕机，或者 redis 集群模式下大量节点宕机.

2. redis 好着呢，但是可能之前短时间内设置了很多相同过期时间的 key.

如何处理？

1) 加强监控警报，例如采取集群的监控，或者哨兵监控的方式，加强 redis 集群可用性.

2）不给 key 设置过期时间，或者设置过期时间的时候，添加一些随机因子，来避免同时过期.

1.4.4、缓存击穿（Cache breakdown）

这里翻译成 “击穿” 实际上不太合适，以至于一些面试官也分不清击穿和穿透（这种情况，最好两种都说明一下）.

这里更适合的翻译成 “瘫痪”.

缓存击穿 相当于 雪崩 的特殊情况. 针对热点 key，如果过期了，导致大量请求直接访问到数据库上，甚至引起数据库宕机.

如何处理？

1. 基于统计的方式发现热点 key，设置为永不过期. 这种方式往往需要服务器结构做出比较大的调整.

2. 进行必要的服务降级（例如服务器的功能本来有 10 个，特定情况下，会关闭一些不重要的功能，只保留核心功能.  类似于手机的省电模式），例如访问数据库的时候使用分布式锁，限制数据库的访问频率.