redis(缓存)

缓存

缓存(cache) 是计算机中的一个经典概念

核心思路是将 热点数据 放到访问速度更快的地方, 方便随时读取

通常情况下, 访问数据的速度: CPU 寄存器 > 内存 > 硬盘 > 网络

速度快的设备可以作为速度慢的设备的缓存

对于计算机硬件来说, 访问速度越快, 成本越高, 存储空间越小

但是大部分情况下, 缓存只存储一些 热点数据 , 是完全够用的

通常将 redis 作为 关系型数据库 (MySQL, Oracle …) 的缓存

关系型数据库的功能强大, 但是性能不高 (一次操作消耗资源较多)

1. 数据存储在磁盘上, 磁盘的 IO 速度并不快

如果查询不能命中索引, 就需要进行表的遍历, 就会大大增加硬盘 IO 次数

1. 关系型数据库对于 SQL 的执行会做一系列解析, 校验, 优化操作
2. 复杂查询会触发笛卡尔积操作, 效率成指数下降

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

1. 开源: 引入更多机器, 构成数据库集群
2. 节流: 引入缓存, 热点数据通过缓存处理, 可以大大降低数据库的请求数量

经过缓存的业务执行流程

客户端访问业务服务器, 发起查询请求

业务服务器会先查询 缓存

• 如果所需数据在 redis 中已存在, 则不必再访问 MySQL
• 如果 redis 中不存在, 则访问 MySQL

缓存的更新策略

1. 定期生成
   每隔一定周期, 对于访问数据进行统计, 根据访问频率挑选热点数据 (实时性差)
2. 实时生成
   对于每次用户的查询

• 如果在 redis 中查到了, 就返回对应结果
• 如果在 redis 中查询不到, 就从数据库查, 并把查询到的数据也写入 redis

缓存淘汰机制

缓存 的容量是有限的, 对于热点数据的不断插入, 需要把一些 “不是那么热门” 的数据删除, 对此 缓存 拥有几种淘汰机制

FIFO (First In First Out) 先进先出 – 把缓存中存在最久的数据淘汰掉

LRU (Least Recently Used) 淘汰最久未使用的 – 记录每个 key 的最近访问时间, 每次淘汰访问时间最老的 key

LFU (Least Frequently Used) 淘汰访问次数最少的 – 记录每个 key 的访问次数, 每次淘汰访问次数最少的 key

Random 随机淘汰

缓存预热

当 Redis 作为 MySQL 缓存, 刚刚启动的时候, 会有大批 热点数据 生成到 Redis 中, 此时会造成 MySQL 的压力很大

缓存预热就是提前在 Redis 中准备部分热点数据, 让 MySQL 在刚刚启动时的压力没那么大

缓存穿透 (Cache Penetration)

访问的 key 在 Redis 和 数据库中都不存在, 这样的 key 并不会被用户获取到, 也不会被更新到Redis 中, 后续若是仍有此请求, 仍会访问数据库 (会导致数据库压力变大)

问题原因:

1. 业务设计不合理
2. 开发 / 运维误删数据库
3. 黑客恶意攻击

解决:

1. 当在 Redis 和 MySQL 中都查询不到时, 在 redis 中插入 value = “” 的键值对,防止后续频繁访问数据库
2. 布隆过滤器对 key 进行校验
3. 对查询数据做合法性校验 (针对业务上的优化)

缓存雪崩

问题:

• 短时间内 redis 上 key 值大量失效 (redis 挂了 / 多个 key 的过期时间相同), 导致 redis 命中率下降, MySQL 压力骤增

解决:

1. 部署高可用的 Redis 集群, 完善报警机制 (哨兵)
2. 不设置过期时间, 或者对过期时间添加随机因子 (别同时全部过期)

缓存击穿 (Cache Breakdown)

问题:

• 缓存雪崩的一种特殊情况, 热点 key 突然过期, 导致大量请求直接访问数据库

解决:

1. 将热点 key 设置为永不过期
2. 服务降级 (类似于手机省电模式, 适当关闭 MySQL 的非核心功能)