redis的应用----缓存

- 一、缓存的概念
- 二、使用redis作为缓存
- - 2.1使用redis作为缓存的原因
  - 2.2缓存机制的访问步骤
- 三、缓存的更新策略
- 四、缓存常见的问题
- - [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))

一、缓存的概念

缓存（Cache）是一种存储机制，旨在提供高速访问已保存的数据或计算结果。通过将数据存储在临时存储位置，当再次需要这些数据时，可以迅速从缓存中检索，而不是重新进行原始数据的获取和计算过程。缓存可以存在于各种层次，如硬件，CPU缓存、软件（如Web浏览器缓存）和专门的存储系统（如内存中的分布式缓存）‌

举例说明

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

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

二、使用redis作为缓存

2.1使用redis作为缓存的原因

在⼀个⽹站中, 我们经常会使⽤关系型数据库 (⽐如 MySQL) 来存储数据. 关系型数据库虽然功能强⼤, 但是有⼀个很⼤的缺陷, 就是性能不⾼. (换⽽⾔之, 进⾏⼀次查询操作消耗的系统资源较多)

为什么说关系型数据库性能不⾼?

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

因此, 如果访问数据库的并发量⽐较⾼, 对于数据库的压⼒是很⼤的, 很容易就会使数据库服务器宕机

为什么并发量⾼了就会宕机?

服务器每次处理⼀个请求, 都是需要消耗⼀定的硬件资源的. 所谓的硬件资源包括不限于 CPU, 内存, 硬盘, ⽹络带宽...

⼀个服务器的硬件资源本⾝是有限的，⼀个请求消耗⼀份资源，请求多了，⾃然把资源就耗尽了，后续的请求没有资源可⽤，⾃然就⽆法正确处理。更严重的还会导致服务器程序的代码出现崩溃

如何让数据库能够承担更⼤的并发量呢?

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

一般情况下，这两种方案都是搭配使用的

为什么使用redis作为缓存？

Redis 访问速度⽐关系型数据库 (⽐如 MySQL) 快很多，或者说处理同⼀个访问请求，Redis 消耗的系统资源⽐MySQL少很多，因此 Redis 能⽀持的并发量更⼤，Redis 数据在内存中, 访问内存⽐硬盘快很多，Redis 只是⽀持简单的 key-value 存储，不涉及复杂查询的那么多限制规则

2.2缓存机制的访问步骤

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

理论上，一般只需要在 Redis 中放 20% 的热点数据，就可以使 80% 的请求不再真正查询数据库了。当然，实践中究竟是 "⼆⼋", 还是 "⼀九", 还是 "三七", 这个情况可能会根据业务场景的不同，存在差异，但是⾄少绝⼤多数情况下，使⽤缓存都能够⼤⼤提升整体的访问效率降低数据库的压⼒

注意：缓存是⽤来加快 "读操作" 的速度的. 如果是 "写操作", 还是要⽼⽼实实写数据库, 缓存并不能提⾼性能

三、缓存的更新策略

根据网络中的梗我们就能够知道，哪些是热点数据，哪些非热点的数据，那么缓存是怎么区分的呢？这时就引入了更新策略

3.1定期更新

每隔⼀定的周期(⽐如⼀天/⼀周/⼀个⽉)，对于访问的数据频次进⾏统计，挑选出访问频次最⾼的前 N% 的数据

以搜索引擎为例进行说明

⽤⼾在搜索引擎中会输⼊⼀个 "查询词", 有些词是属于⾼频的, ⼤家都爱搜(鲜花, 蛋糕, 同城交友...)，有些词就属于低频的，⼤家很少搜索的。搜索引擎的服务器会把哪个⽤⼾什么时间搜了啥词，都通过⽇志的⽅式记录的明明⽩⽩，然后每隔⼀段时间对这期间的搜索结果进⾏统计 (⽇志的数量可能⾮常巨⼤，这个统计的过程可能需要使⽤ hadoop 或者 spark 等⽅式完成)，从⽽就可以得到 "⾼频词表"

但是这种方式实时性非常的低，对于一些突发情况处理起来不是很好，比如春节时经常出现的春节晚会，这就属于突然出现的高频词

3.2实时更新

先给缓存设定容量上限(可以通过 Redis 配置⽂件的maxmemory参数设定)，此时的查询步骤为：

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

3.3淘汰策略

下列策略并⾮局限于 Redis, 其他缓存也可以按这些策略展开：

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

这⾥的淘汰策略, 我们可以⾃⼰实现. 当然 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.1缓存预热(Cache preheating)

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

热点数据可以基于之前介绍的统计的⽅式⽣成即可. 这份热点数据不⼀定⾮得那么 "准确", 只要能帮助 MySQL 抵挡⼤部分请求即可. 随着程序运⾏的推移, 缓存的热点数据会逐渐⾃动调整, 来更适应当前情况

4.2缓存穿透(Cache penetration)

什么是缓存穿透？

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

为什么会产生缓存穿透？

业务设计不合理. ⽐如缺少必要的参数校验环节, 导致⾮法的 key 也被进⾏查询了
开发/运维误操作. 不⼩⼼把部分数据从数据库上误删了
⿊客恶意攻击

解决方案

针对要查询的参数进⾏严格的合法性校验. ⽐如要查询的 key 是⽤⼾的⼿机号, 那么就需要校验当前 key 是否满⾜⼀个合法的⼿机号的格式
针对数据库上也不存在的 key , 也存储到 Redis 中, ⽐如 value 就随便设成⼀个 "". 避免后续频繁访问数据库
使⽤布隆过滤器先判定 key 是否存在, 再真正查询

将数据库中的能够唯一标识某个数据保存在布隆过滤器中，当我们需要查找某个key的时候，就先到布隆过滤器中查询，如果存在那就去数据库中查找，如果不存在，那就直接返回了，不去数据库中查找了。

4.3缓存雪崩(Cache avalanche)

什么是缓存雪崩？

短时间内⼤量的 key 在缓存上失效, 导致数据库压⼒骤增, 甚⾄直接宕机，比如：本来 Redis 是 MySQL 的⼀个护盾，帮 MySQL 抵挡了很多外部的压⼒. ⼀旦护盾突然失效了, MySQL ⾃⾝承担的压⼒骤增, 就可能直接崩溃

为什么会产生缓存雪崩？

Redis服务器挂了
Redis 上的⼤量的 key 同时过期

redis中key同时过期的情况一般是由于某一时间段内redis存储了大量的key，并设置了相同的过期时间

解决方案

部署⾼可⽤的 Redis 集群, 并且完善监控报警体系
不给 key 设置过期时间或者设置过期时间的时候添加随机时间因⼦，避免大量key过期时间一样

4.4缓存击穿(Cache breakdown)

什么是缓存击穿？

当前key是一个热点key（例如一个秒杀活动），并发量非常大，重建缓存不能在短时间完成，可能是一个复杂计算，例如复杂的SQL、多次IO、多个依赖等。在缓存失效的瞬间，有大量线程来重建缓存，造成后端负载加大，甚至可能会让应用崩溃

解决方案

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