Redis的缓存

[1. 什么是缓存](#1. 什么是缓存)
[2. 使用Redis作为缓存](#2. 使用Redis作为缓存)
[3. 缓存的更新策略](#3. 缓存的更新策略)
- [3.1 定期生成](#3.1 定期生成)
- [3.2 实时生成](#3.2 实时生成)
[4. 缓存使用注意事项](#4. 缓存使用注意事项)
- [4.1 缓存预热(Cache preheating)](#4.1 缓存预热(Cache preheating))
- [4.2 缓存穿透(Cache penetration)](#4.2 缓存穿透(Cache penetration))
- [4.3 缓存雪崩(Cache avalanche)](#4.3 缓存雪崩(Cache avalanche))
- [4.4 缓存击穿(Cache breakdown)](#4.4 缓存击穿(Cache breakdown))

1. 什么是缓存

（1）缓存(cache)是计算机中的一个经典的概念。在很多场景中都会涉及到。核心思路就是把一些常用的数据放到触手可及(访问速度更快)的地方，方便随时读取。举个例子：

比如我需要去高铁站坐高铁。我们知道坐高铁是需要反复刷身份证的(进入高铁站，检票，上车，乘车过程中，出站...正常来说，我的身份证是放在皮箱里的(皮箱的存储空间大，足够能装)。但是每次刷身份证都需要开一次皮箱找身份证，就非常不方便。
因此我就可以把身份证先放到衣服口袋里。口袋虽然空间小，但是访问速度比皮箱快很多。这样的话每次刷身份证我只需要从口袋里掏身份证就行了，就不必开皮箱了。
此时"口袋"就是"皮箱"的缓存。使用缓存能够大大提高访问效率。

（2）这里所说的"触手可及"是个相对的概念。我们知道，对于硬件的访问速度来说，通常情况下：CPU寄存器>内存>硬盘>网络。那么硬盘相对于网络是"触手可及的"，就可以使用硬盘作为网络的缓存。

内存相对于硬盘是"触手可及的"，就可以使用内存作为硬盘的缓存。
CPU寄存器相对于内存是"触手可及的"，就可以使用CPU寄存器作为内存的缓存。

（3）对于计算机硬件来说,往往访问速度越快的设备，成本越高，存储空间越小缓存是更快，但是空间上往往是不足的。因此大部分的时候，缓存只放一些热点数据(访问频繁的数据)，就非常有用了。

（4）关于"二八定律"：

20%的热点数据，能够应对80%的访问场景。
因此只需要把这少量的热点数据缓存起来，就可以应对大多数场景,从而在整体上有明显的性能提升。

2. 使用Redis作为缓存

（1）在一个网站中，我们经常会使用关系型数据库(此如MySQL)来存储数据。关系型数据库虽然功能强大，但是有一个很大的缺陷，就是性能不高(换而言之，进行一次查询操作消耗的系统资源较多)。为什么说关系型数据库性能不高?

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

因此如果访问数据库的并发量比较高，对于数据库的压力是很大的，很容易就会使数据库服务器宕机。

（2）为什么并发量高了就会宕机?

服务器每次处理一个请求，都是需要消耗一定的硬件资源。所谓的硬件资源包括不限于CPU、内存、硬盘、网络带...一个服务器的硬件资源本身是有限的。一个请求消耗一份资源，请求多了，自然把资源就耗尽了。后续的请求没有资源可用，自然就无法正确处理。更严重的还会导致服务器程序的代码出现崩溃。

（3）如何让数据库能够承担更大的并发量呢?核心思路主要是两个：

开源：引入更多的机器，部署更多的数据库实例，构成数据库集群(主从复制，分库分表等...)。
节流：引入缓存，使用其他的方式保存经常访问的热点数据，从而降低直接访问数据库的请求数量。

实际开发中这两种方案往往是会搭配使用的。

（4）Redis就是一个用来作为数据库缓存的常见方案。Redis访问速度比MySQL快很多。或者说处理同一个访问请求，Redis消耗的系统资源比MySQL少很多。因此Redis能支持的并发量更大。

Redis数据在内存中，访问内存比硬盘快很多。
Redis只是支持简单的key-value存储，不涉及复杂查询的那么多限制规则。
就像一个"护盾"一样，把MySQL给罩住了。

客户端访问业务服务器，发起查询请求。
业务服务器先查询Redis，看想要的数据是否在Redis中存在。
- 如果已经在Redis中存在了，就直接返回。此时不必访问MySQL了。
- 如果在Redis中不存在，再查询MySQL。

（5）按照上述讨论的"二八定律"，只需要在Redis中放20%的热点数据，就可以使80%的请求不再真正查询数据库了。当然，实践中究竟是"二八"，还是"一九"，还是"三七"，这个情况可能会根据业务场景的不同，存在差异。但是至少绝大多数情况下，使用缓存都能够大大提升整体的访问效率，降低数据库的压力。

（6）注意：缓存是用来加快"读操作"的速度的。如果是"写操作"，还是要老老实实写数据库，缓存并不能提高性能。

3. 缓存的更新策略

接下来还有一个重要的问题，到底哪些数据才是"热点数据"呢?

3.1 定期生成

（1）每隔一定的周期(比如一天/一周/一个月)，对于访问的数据频次进行统计。挑选出访问频次最高的前N%的数据。

（2）以搜索引擎为例：

用户在搜索引擎中会输入一个"查询词"，有些词是属于高频的，大家都爱搜(鲜花，蛋糕，同城交友，不孕不育...有些词就属于低频的，大家很少搜。
搜索引擎的服务器会把哪个用户什么时间搜了啥词，都通过日志的方式记录的明明白白。然后每隔一段时间对这期间的搜索结果进行统计(日志的数量可能非常巨大，这个统计的过程可能需要使用hadoop或者spark等方式完成)。从而就可以得到"高频词表"。

这种做法实时性较低。对于一些突然情况应对的并不好。比如春节期间，"春晚"这样的词就会成为非常高频的词。而平时则很少会有人搜索"春晚"。

3.2 实时生成

（1）先给缓存设定容量上限(可以通过Redis配置文件的maxmemory 参数设定)。接下来把用户每次查询：

如果在Redis查到了就直接返回。
如果Redis中不存在就从数据库查，把查到的结果同时也写入Redis。
如果缓存已经满了(达到上限)，就触发缓存淘汰策略，把一些"相对不那么热门"的数据淘汰掉。
按照上述过程，持续一段时间之后Redis内部的数据自然就是"热门数据"了。

（2）通用的淘汰策略主要有以下几种：下列策略并非局限于Redis，其他缓存也可以按这些策略展开。

FIFO (First In First Out)先进先出：把缓存中存在时间最久的(也就是先来的数据)淘汰掉。
LRU (Least Recently Used)淘汰最久未使用的：记录每个key的最近访问时间.把最近访问时间最老的key淘汰掉。
LFU (Least Frequently Used)：淘汰访问次数最少的。
Random随机淘汰：从所有的key中抽取幸运被随机淘汰掉。

（3）理解上述几种淘汰策略：想象你是个皇帝，有后宫佳丽三千。虽然你是 "真龙天子"，但是经常宠幸的妃子也就那么寥寥数人(精力有限)。后宫佳丽三千相当于数据库中的全量数据。经常宠幸的妃子相当于热点数据，是放在缓存中的。今年选秀的⼀批新的小主，其中有⼀个被你看上了。宠信新人，自然就需要有旧人被冷落。到底谁是要被冷落的人呢?

FIFO：皇后是最先受宠的。现在已经年老色衰了。皇后失宠。
LRU：统计最近宠幸时间。皇后(⼀周前)，熹妃(昨天)，安答应(两周前)，华妃(⼀个月前)。华妃失宠。
LFU：统计最近⼀个月的宠幸次数，皇后(3次)，熹妃(15次)，安答应(1次)，华妃(10次)。安答应失宠。
Random：随机挑⼀个妃子失宠。

（4）这里的淘汰策略我们可以自己实现。当然Redis也提供了内置的淘汰策略，也可以供我们直接使用。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提供的策略和我们上述介绍的通用策略是基本一致的。只不过Redis这里会针对"过期key"和"全部key"做分别处理。

4. 缓存使用注意事项

4.1 缓存预热(Cache preheating)

（1）什么是缓存预热：

使用Redis作为MySQL的缓存的时候，当Redis刚刚启动，或者Redis大批key失效之后，此时由于Redis自身相当于是空着的，没啥缓存数据，那么MySQL就可能直接被访问到，从而造成较大的压力。
因此就需要提前把热点数据准备好，直接写入到Redis中。使Redis可以尽快为MySQL撑起保护伞。

（2）解决缓存预热的方案 ：热点数据可以基于之前介绍的统计的方式生成即可。这份热点数据不一定非得那么"准确"，只要能帮助MySQL抵挡大部分请求即可。随着程序运行的推移，缓存的热点数据会逐渐自动调整，来更适应当前情况。

4.2 缓存穿透(Cache penetration)

（1）什么是缓存穿透?

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

（2）为何会产生缓存穿透?原因可能有几种：

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

（3）如何解决缓存穿透问题?

针对要查询的参数进行严格的合法性校验。比如要查询的key是用户的手机号，那么就需要校验当前key是否满足一个合法的手机号的格式。
针对数据库上也不存在的key，也存储到Redis中，比如value就随便设成一一个值，例如设置成空。避免后续频繁访问数据库。
使用布隆过滤器先判定key是否存在，再真正查询。

4.3 缓存雪崩(Cache avalanche)

（1）什么是缓存雪崩？

短时间内大量的key在缓存上失效，导致数据库压力骤增，甚至直接宕机。本来Redis是MySQL的一个护盾，帮MySQL抵挡了很多外部的压力。一旦护盾突然失效了，MySQL自身承担的压力骤增,就可能直接崩溃。

（2）为何会产生缓存雪崩?大规模key失效,可能性主要有两种：

Redis挂了。
Redis上的大量的key同时过期。为啥会出现大量的key同时过期?
这种可能是短时间内在Redis。上缓存了大量的key，并且设定了相同的过期时间。

（3）如何解决缓存雪崩问题?

部署高可用的Redis集群，并且完善监控报警体系。
不给key设置过期时间或者设置过期时间的时候添加随机时间因子。

4.4 缓存击穿(Cache breakdown)

（1）什么是缓存击穿?

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

（2）如何解决缓存击穿问题?

基于统计的方式发现热点key，并设置永不过期。
进行必要的服务降级。例如访问数据库的时候使用分布式锁，限制同时请求数据库的并发数。

目录