Redis 缓存 - 技术栈

文章目录

1.什么是缓存
2.缓存更新策略
- 2.1定期生成
- [2.2 实时生成](#2.2 实时生成)
3.缓存使用注意事项
- [3.1缓存预热(cache preheating)](#3.1缓存预热(cache preheating))
- [3.2 缓存穿透(cache penetration)](#3.2 缓存穿透(cache penetration))
- [3.3 缓存雪崩（cache avalanche)](#3.3 缓存雪崩（cache avalanche))
- [3.4 缓存击穿(cache breakdown)](#3.4 缓存击穿(cache breakdown))
4.小结

redis的主要用途：

1）存储数据（内存数据库）

2）缓存（redis最常用的场景）

3）消息队列

1.什么是缓存

缓存的本质是 "用更快的存储设备，暂存慢设备的数据，减少慢设备的访问压力"。生活中最常见的例子就是 "浏览器缓存"------ 把你之前访问过的网页图片、JS 文件存在本地硬盘，下次再打开同一网页时，直接从本地读，不用再从远程服务器下载，加载速度快很多。

在后端系统中，缓存的核心价值是解决 "速度不匹配" 的问题：

MySQL 等数据库数据存在硬盘，读写速度约 100-1000 次 / 秒；
Redis 数据存在内存，读写速度约 10 万 - 100 万次 / 秒；
当用户请求量达到每秒几万次时，直接访问 MySQL 会瞬间把数据库压垮，而 Redis 能轻松扛住。

所以，Redis 作为 MySQL 的缓存，工作流程很简单：

客户端查询数据时，先去 Redis 查；
Redis 有数据（命中）：直接返回，不碰 MySQL；
Redis 没数据（未命中）：去 MySQL 查，查到后把数据存到 Redis，再返回给客户端。

2.缓存更新策略

2.1定期生成

把访问的数据，以日志的形式存储起来，每隔一定的周期（一天/一周/一月）对数据进行统计，选出频次高的数据作为缓存。

比如搜索引擎，就是关注"查询词"，通过日志，每天统计一整天每个词出现的频率，根据频率取出前20%的词作为"热点词"，放入缓存中。

可以写一套离线的流程来完成（shell/python 写脚本代码）

a)完成热点词的统计
b)根据热点词，搜索到对应的数据
c) 把缓存数据同步到缓存服务器上
d）控制缓存服务器自动重启

优点：实现简单，过程可控，方便排查问题

缺点：缺乏实时性，如果突发热点事件，突然出现很多新的热词，可能就会给后面的数据库带来较大的压力。（缓存里还没有这些热词，会直接在数据库中搜索）

2.2 实时生成

查询数据时，先在redis中查询，找到直接返回。

redis中没有，去数据库中找，找到了返回并把结果写入缓存。

这样的话缓存中的数据就会越来越多---》就会引发内存淘汰策略

FIFO（First In First Out，先进先出）：淘汰缓存中存在时间最久（最先进入缓存）的数据。
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 算法删除。
allkeys-lfu（4.0 版本新增）：内存不足时，从所有 key 中用 LFU 算法淘汰。
volatile-random：内存不足时，从设置了过期时间的 key 中随机淘汰。
allkeys-random：内存不足时，从所有 key 中随机淘汰。
volatile-ttl：在设置了过期时间的 key 中，按过期时间淘汰，越早过期越优先。
noeviction（默认策略）：内存不足时，新写入操作会报错，且不适合实时更新缓存场景。

3.缓存使用注意事项

3.1缓存预热(cache preheating)

缓存中的数据

1）定期生成（不涉及"预热"）

2）实时生成

redis服务器首次接入后，缓存中没有数据，客户端查redis，没有--》继续查MySQL，查到后返回并写入缓存。

一开始缓存中没有数据，数据库的请求就会很多，随着redis上数据积累，MySQL的压力就小了。

措施：

结合定期生成和实时生成。先统计一下数据，把热点数据提前导入缓存，减少数据库的压力。--》随时间推移，逐渐新的热点数据就代替旧的热点数据了。

3.2 缓存穿透(cache penetration)

如果某个key，在redis上没有，在数据库中也没有，每次查询时都会访问到数据库，给MySQL带来很大的压力。

措施：

1）如果发现这个key在redis上和MySQL上都不存在，就写入到redis中，value值设置为一个非法值（比如" "）

2）引入布隆过滤器，每次查询时，提前判断存不存在。

3.3 缓存雪崩（cache avalanche)

短时间内，redis上大规模的key失效，导致命中率陡然下降，进而MySQL的压力迅速上升，甚至宕机。

1）redis直接挂了（redis宕机/redis集群中大量节点宕机）

2）redis在运行，可能短时间内设置了很多带过期时间的key，然后这批key同时过期了。（大量key同时过期）---》导致大量访问传送到了数据库上。

解决措施：

1）加强监控报警，加强redis集群可用性的保证

2）不给key设置过期时间/设置过期时间时避免同一时刻

3.4 缓存击穿(cache breakdown)

热点key突然过期，导致大量请求直接访问到数据库上，甚至引起数据库宕机。

解决措施：

1）基于统计方法发现热点key，设置永不过期

2）进行必要的服务降级，使用分布式锁，限制同时请求数据库的并发数。

分布式锁---》限制数据库访问频率

服务降级---》保留核心，关闭一些不重要的功能

4.小结

选对更新策略：数据固定用 "定期生成"，数据多变用 "实时生成 + 内存淘汰"；
必做缓存预热：冷启动前导入热点数据，避免 MySQL 承压；
防穿透：用 "空值缓存" 或 "布隆过滤器" 拦截无效请求；
防雪崩：错开过期时间，用 Redis 集群提高可用性；
防击穿：热点 key 永不过期，或用分布式锁限制并发。