• 【Redis 进阶】Redis 典型应用 —— 缓存（cache）

    一、什么是缓存

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

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

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

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

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

    二、使用 Redis 作为缓存

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

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

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

    为什么并发量高了就会宕机？

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

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

    核心思路主要是两个：

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

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

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

    Redis 访问速度比 MySQL 快很多，或者说处理同⼀个访问请求，Redis 消耗的系统资源比 MySQL 少很多，因此 Redis 能支持的并发量更大。

    • Redis 数据在内存中，访问内存比硬盘快很多。
    • Redis 只是支持简单的 key-value 存储，不涉及复杂查询的那么多限制规则。

    就像一个 “护盾” 一样，把 MySQL 给罩住了：

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

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

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

    三、缓存的更新策略

    到底哪些数据才是 “热点数据” 呢？

    1、定期生成

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

    以搜索引擎为例：用户在搜索引擎中会输入一个 “查询词”，有些词是属于高频的，大家都爱搜（鲜花、蛋糕、交友...），有些词就属于低频的，大家很少搜。

    搜索引擎的服务器会把哪个用户在什么时间搜了什么词，都通过日志的方式记录的明明白白，然后每隔一段时间对这期间的搜索结果进行统计（日志的数量可能非常巨大，这个统计的过程可能需要使用 hadoop 或者 spark 等方式完成），从而就可以得到 “高频词表”。

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

    2、实时生成

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

    • 如果在 Redis 查到了，就直接返回。
    • 如果 Redis 中不存在，就从数据库查，把查到的结果同时也写入 Redis。（经过一段时间的 “动态平衡”，redis 中的 key 就逐渐成了热点数据）

    如果缓存已经满了（达到上限），就触发缓存淘汰策略，把⼀些 “相对不那么热门” 的数据淘汰掉。按照上述过程持续一段时间之后 Redis 内部的数据自然就是 “热门数据” 了。

    通用的淘汰策略主要有以下几种：

    下列策略并非局限于 Redis，其他缓存也可以按这些策略展开。

    （1）FIFO（First In First Out）先进先出

    把缓存中存在时间最久的（也就是先来的数据）淘汰掉。

    （2）LRU（Least Recently Used）淘汰最久未使用的

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

    （3）LFU（Least Frequently Used）淘汰访问次数最少的

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

    （4）Random 随机淘汰

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

    （5）理解四种淘汰策略

    想象你是个皇帝，有后宫佳丽三千。虽然你是 “真龙天子”，但是经常宠幸的妃子也就那么寥寥数人（精力有限）。后宫佳丽三千相当于数据库中的全量数据，经常宠幸的妃子相当于热点数，是放在缓存中的。今年选秀的一批新的小主，其中有一个被你看上了。宠信新人自然就需要有旧人被冷落，到底谁是哪个要被冷落的人呢？

    • FIFO：皇后是最先受宠的，现在已经年老色衰了，皇后失宠。
    • LRU: 统计最近宠幸时间：皇后（一周前）、熹妃（昨天）、安答应（两周前）、华妃(一个月前），那么华妃失宠。
    • LFU: 统计最近⼀个⽉的宠幸次数，皇后（3 次）、熹妃（15 次）、安答应（1 次）、华妃（10 次），那么安答应失宠。
    • Random：随机挑⼀个妃子失宠。这⾥的淘汰策略, 我们可以⾃⼰实现. 当然 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” 做分别处理。

    四、缓存预热、缓存穿透、缓存雪崩和缓存击穿

    1、关于缓存预热（Cache preheating）

    （1）什么是缓存预热

    使用 Redis 作为 MySQL 的缓存的时候，当 Redis 刚刚启动或者 Redis 大批 key 失效之后，此时由于 Redis 服务器是没有什么缓存数据的，那么所有的请求就会打给 MySQL，MySQL 就可能直接被访问到，从而造成较大的压力。随着时间的推移，redis 上的数据积累的越来越多，MySQL 承担的压力也就越来越小。因此就需要提前把热点数据准备好，直接写入到 Redis 中，使 Redis 可以尽快为 MySQL 撑起保护伞。

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

    2、关于缓存穿透（Cache penetration）

    （1）什么是缓存穿透

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

    （2）为什么会产生缓存穿透

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

    （3）如何解决缓存穿透

    • 针对要查询的参数进行严格的合法性校验，比如要查询的 key 是用户的手机号，那么就需要校验当前 key 是否满足⼀个合法的手机号的格式。
    • 针对数据库上也不存在的 key , 也存储到 Redis 中，比如 value 就随便设成⼀个 ""，避免后续频繁访问数据库。
    • 使用布隆过滤器先判定 key 是否存在，再真正查询。 
    可以通过引入布隆过滤器，每次查询 redis / mysql 之前都先判定一下 key 是否在布隆过滤器上是否存在（把所有的 key 都插入到布隆过滤器中）。布隆过滤器本质上是结合了 hash + bitmap 的思想，以较少的空间开销，比较快的时间速度，判定 key 是否存在。

    3、关于缓存雪崩（Cache avalanche）

    （1）什么是缓存雪崩

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

    （2）为什么会产生缓存雪崩

    大规模 key 失效，其可能性主要有两种：
    1. Redis 挂了。
    2. Redis 上的大量的 key 同时过期。
    为什么会出现大量的 key 同时过期?

    这种和可能是短时间内在 Redis 上缓存了大量的 key，并且设定了相同的过期时间。

    （3）如何解决缓存雪崩

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

    4、关于缓存击穿（Cache breakdown）

    （1）什么是缓存击穿

    此处把 breakdown 翻译成 “击穿”，我以为并非是⼀个好的选择，容易和缓存穿透混淆，翻译成 “瘫痪” / “崩溃” 也许更合适一些。

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

    （2）如何解决缓存击穿

    • 基于统计的方式发现热点 key，并设置永不过期。
    • 进行必要的服务降级。例如访问数据库的时候使用分布式锁，限制同时请求数据库的并发数。
  • 相关阅读:
    Spring 从入门到精通 (九) 配置文件参数化
    Vue组件定义
    （附源码）springboot 中小学餐饮配送系统 毕业设计645661
    C++(七）——STL
    基于Springboot实现社区维修平台管理系统演示【项目源码+论文说明】
    SpringBoot和MyBatis常见注解
    史上最全的mysql数据类型汇总（下）
    go 通道的运用
    华为机试真题 C++ 实现【探索地块建立】【2022.11 Q4 新题】
    基于Android健身预约系统APP开发
  • 原文地址：https://blog.csdn.net/weixin_74531333/article/details/140893071