Redis - 缓存
文章目录
目录
文章目录
1. 什么是缓存？
2. 使用Redis作为缓存
2.1 关系型数据库的缺点
3. 缓存的更新策略
3.1 定期生成
3.2 实时生成
缓存淘汰策略
4. 缓存预热, 缓存穿透, 缓存雪崩 和 缓存击穿
缓存预热
缓存穿透
缓存雪崩
缓存击穿
总结
1. 什么是缓存？
缓存 (cache) 是计算机中的一个经典的概念. 在很多场景中都会涉及到. 核心思路就是把一些常用的数据放到触手可及(访问速度更快)的地方, 方便随时读取。
对于计算机硬件来说，往往访问速度越快的设备，成本越高，存储空间越小。
缓存是很快，但是空间上往往不足以存储所有数据， 因此大部分时候， 缓存只存放一些热点数据。
二八定律
20%的热点数据，能够应对80%的访问场景。
因此只需要把这少量的热点数据缓存起来，就可以应对大多数场景，从而在整体上有明显的性能提升。
2. 使用Redis作为缓存
2.1 关系型数据库的缺点
在一个网站中，我们常常会使用Mysql这类关系型数据库来存储数据。关系型数据库虽然功能强大，但是有一个非常严重的缺点： 性能不高
- 数据库把数据存储在硬盘上, 硬盘的 IO 速度并不快. 尤其是随机访问.
- 如果查询不能命中索引, 就需要进行表的遍历, 这就会大大增加硬盘 IO 次数.
- 关系型数据库对于 SQL 的执行会做一系列的解析, 校验, 优化工作.
- 如果是⼀些复杂查询, 比如联合查询, 需要进行笛卡尔积操作, 效率更是降低很多
遵从二八定律，我们可以使用Redis作为缓存层，这样打到Mysql数据库的请求就会少很多，降低了数据库的压力，同时提高了总体响应速度。
缓存是用来加快 "读操作" 的速度的. 如果是 "写操作", 还是要老老实实写数据库, 缓存并不能提高其性能.
3. 缓存的更新策略
3.1 定期生成
每隔一定的周期(比如⼀天/⼀周/⼀个月), 对于访问的数据频次进行统计. 挑选出访问频次最高的前 N% 的数据保存进入Redis。
这种做法实时性较低. 对于一些突然情况应对的并不好。
比如春节期间, "春晚" 这样的词就会成为非常高频的词. 而平时则很少会有人搜索 "春晚"。
3.2 实时生成
先给缓存设定容量上限(可以通过 Redis 配置文件的 maxmemory 参数设定)。
接下来把用户每次查询:
- 如果在 Redis 查到了, 就直接返回。
- 如果 Redis 中不存在, 就从数据库查, 把查到的结果同时也写入 Redis。
如果缓存已经满了(达到上限), 就触发缓存淘汰策略, 把一些 "相对不那么热门" 的数据淘汰掉。
按照上述过程, 持续一段时间之后 Redis 内部的数据自然就是 "热门数据" 了。
缓存淘汰策略
FIFO (First In First Out) 先进先出： 把缓存中存在时间最久的 (也就是先来的数据) 淘汰掉.
LRU (Least Recently Used) 淘汰最久未使用的： 记录每个 key 的最近访问时间. 把最近访问时间最老的 key 淘汰掉.
LFU (Least Frequently Used) 淘汰访问次数最少的：记录每个 key 最近⼀段时间的访问次数. 把访问次数最少的淘汰掉.
Random 随机淘汰：从所有的 key 中抽取幸运儿被随机淘汰掉.
4. 缓存预热, 缓存穿透, 缓存雪崩 和 缓存击穿
缓存预热
缓存预热是指在系统上线或流量高峰之前，主动将一些常用的数据预先加载到缓存中，以减少首次请求时的延迟和数据库的压力。
缓存穿透
缓存穿透是指请求的数据在缓存和数据库中都不存在，导致每次请求都直接访问数据库，造成数据库压力增大。通常是由于恶意请求或错误的请求参数引起的。
原因：
业务设计不合理。比如缺少必要的参数校验环节, 导致非法的 key 也被进行查询了。
黑客恶意攻击。
解决：
1. 针对要查询的参数进行严格的合法性校验。 比如要查询的 key 是用户的手机号, 那么就需要校验当前 key 是否满足⼀个合法的手机号的格式。
2. 针对数据库上也不存在的 key , 也存储到 Redis 中, 比如 value 就随便设成⼀个 "". 避免后续频繁访问数据库.
3. 使用布隆过滤器先判定 key 是否存在, 再真正查询.
缓存雪崩
缓存雪崩是指在某个时间点，大量缓存数据同时过期，导致大量请求直接访问数据库，造成数据库瞬间负载过高，可能导致服务崩溃。
原因：
Redis挂了。
Redis中大量key同时过期。
解决：
1. 部署高可用的 Redis 集群, 并且完善监控报警体系。
2. 不给 key 设置过期时间 或者 设置过期时间的时候添加随机时间因子。
缓存击穿
缓存击穿是指某个热点数据在缓存中失效，导致大量请求同时访问数据库，造成数据库瞬间负载过高。与缓存雪崩不同的是，缓存击穿通常是针对单个热点数据的情况。
解决：
1. 基于统计的方式发现热点 key, 并设置永不过期.
2. 进行必要的服务降级. 例如访问数据库的时候使用分布式锁, 限制同时请求数据库的并发数。
总结
以上就是这篇博客的主要内容了,大家多多理解,下一篇博客见!