在我的博客阅读本文
文章目录
基于Redis实现缓存系统的注意点与一些常见问题
1. 从计算机系统的缓存开始
在计算机系统中,默认有两种缓存:
- CPU 里面的末级缓存,即 LLC,用来缓存内存中的数据,避免每次从内存中存取数据;
- 内存中的高速页缓存,即 page cache,用来缓存磁盘中的数据,避免每次从磁盘中存取数据。
LLC一般几MB,page cache一般几GB,磁盘一般几TB,可以看出缓存系统有以下特征:
- 在一个层次化的系统中,缓存一定是一个快速子系统,数据存在缓存中时,能避免每次从慢速子系统中存取数据。
- 缓存系统的容量大小总是小于后端慢速系统的,我们不可能把所有数据都放在缓存系统中。
2. Redis的缓存策略
所谓缓存,就是将需要多次读取的数据暂存起来,这样在后面,应用程序需要多次读取的时候,就不必从数据源重复加载数据了,这样就可以降低数据源的计算负载压力,提高数据响应速度。
一般来说,有三种策略:
- **旁路缓存(Cache Aside)策略:读操作命中缓存直接返回,否则从后端数据库加载到缓存再返回,并写入缓存中。写操作直接更新数据库,然后删除缓存。这种策略的优点是一切以后端数据库为准,可以保证缓存和数据库的一致性。缺点是写操作会让缓存失效,再次读取时需要从数据库中加载。**Redis一般都是使用这个策略。
- **通读缓存(Read Throught)策略:应用层读写只需要操作缓存,不需要关心后端数据库。应用层在操作缓存时,缓存层会自动从数据库中加载或写回到数据库中,这种策略的优点是,缓存中拥有最新的数据,对于应用层的使用非常友好,只需要操作缓存即可,缺点是需要缓存层支持和后端数据库的联动。**Redis无法自动与Mysql等后端数据库联动,需要额外写业务代码来实现这个策略。
- 写回策略(Write Back)策略:这里主要是指异步写回策略,同步就是通读缓存了。写操作只写入缓存,等数据就要过期(淘汰)时写入到数据库中。优点是写入飞快,缺点是数据丢失风险较大。
3. 缓存大小的设置
一般遵循“八二原理”设置为总数据量的 15% 到 30%,兼顾访问性能和内存空间开销。
4. 缓存删除方案
Redis的内存总是会满的,因此我们需要设置相应的的删除方案,对内存数据进行清理。
总结来说就是三块:
- 定期删除
- 惰性删除
- 内存淘汰
4.1. 定期删除
Redis每隔一端时间会检查一部分已经过期的key进行删除。
4.2. 惰性删除
Redis会在获取某个Key时检查是否过期,过期就删除
4.3. 内存淘汰(内存驱逐)
需要注意,volatile-lfu和allkeys-lfu是Redis 4.0 后新增的。
- noevction不进行数据淘汰
- volatile-ttl 在筛选时,会针对设置了过期时间的键值对,根据过期时间的先后进行删除,越早过期的越先被删除。
- volatile-random 就像它的名称一样,在设置了过期时间的键值对中,进行随机删除。
- volatile-lru 会使用 LRU 算法筛选设置了过期时间的键值对。
- volatile-lfu 会使用 LFU 算法选择设置了过期时间的键值对。
- allkeys-random 策略,从所有键值对中随机选择并删除数据;
- allkeys-lru 策略,使用 LRU 算法在所有数据中进行筛选。
- allkeys-lfu 策略,使用 LFU 算法在所有数据中进行筛选。
注意:
- LRU算法,全称Least recently used,即最近最少使用
- LFU算法,全称Least Frequently Used,即最不经常使用
LRU 会把所有的数据组织成一个链表,链表的头和尾分别表示 MRU 端和 LRU 端,分别代表最近最常使用的数据和最近最不常用的数据:
LRU 算法背后的想法非常朴素:它认为刚刚被访问的数据,肯定还会被再次访问,所以就把它放在 MRU 端;长久不访问的数据,肯定就不会再被访问了,所以就让它逐渐后移到 LRU 端,在缓存满时,就优先删除它。
在 Redis 中,LRU 算法被做了简化,以减轻数据淘汰对缓存性能的影响(否则需要维护链表)。具体来说,Redis 默认会记录每个数据的最近一次访问的时间戳(由键值对数据结构 RedisObject 中的 lru 字段记录)。然后,Redis 在决定淘汰的数据时,第一次会随机选出 N 个数据,把它们作为一个候选集合。接下来,Redis 会比较这 N 个数据的 lru 字段,把 lru 字段值最小的数据从缓存中淘汰出去。
LFU 缓存策略是在 LRU 策略基础上,为每个数据增加了一个计数器,来统计这个数据的访问次数。当使用 LFU 策略筛选淘汰数据时,首先会根据数据的访问次数进行筛选,把访问次数最低的数据淘汰出缓存。如果两个数据的访问次数相同,LFU 策略再比较这两个数据的访问时效性,把距离上一次访问时间更久的数据淘汰出缓存。
总结来看:
- LRU策略是只有时间维度因素,更加关注数据的时效性
- LFU策略按优先级,有访问次数纬度因素 + 时间维度因素,更加关注数据的访问频次。
特别注意,在设置数据的过期时间时,尽量指定过期时间,而不是指定多久后后删除,在主从环境中会出现不一致的情况(从库保留数据时间 = 从库同步到数据 + 过期时间,而从库同步到数据的时间 在 主库写入数据的时间之后)
5. 缓存使用过程中的一些问题
5.1. Redis缓存与数据库不一致问题
这里用蒋德钧老师的一张图:
重点说下一个容易造成困惑的概念:
- 延迟双删:在线程 A 更新完数据库值以后,让它先 sleep 一小段时间,再进行一次缓存删除操作,这样后续访问的线程就可以触发缓存缺失,进而将新数据写入缓存。
5.2. 缓存雪崩
缓存雪崩是指大量的应用请求无法在 Redis 缓存中进行处理,紧接着,应用将大量请求发送到数据库层,导致数据库层的压力激增。
可能有两个原因:
- 缓存中有大量数据同时过期,导致大量请求无法得到处理。
- Redis服务器宕机。
针对第1点,有以下方案:
- 调整过期时间,适当加一个随机数时间避免同时过期
- 服务降级(核心业务直接访问数据库 | 非核心业务返回空值等)
针对第2点,有以下方案:
- 是在业务系统中实现服务熔断或请求限流机(暂停业务应用对缓存系统的接口访问,直接返回)。
- 事前预防,搭建高可用的主从集群
5.3. 缓存击穿
缓存击穿是指,针对某个访问非常频繁的热点数据的请求,无法在缓存中进行处理,紧接着,访问该数据的大量请求,一下子都发送到了后端数据库,导致了数据库压力激增,会影响数据库处理其他请求。
一般考虑是对于访问特别频繁的热点数据,不设置过期时间。
5.4. 缓存穿透
缓存穿透是指要访问的数据既不在 Redis 缓存中,也不在数据库中,导致请求在访问缓存时,发生缓存缺失,再去访问数据库时,发现数据库中也没有要访问的数据。
有以下方案:
- 缓存设置空值或缺省值。
- 布隆过滤器快速判断数据是否存在,避免从数据库中查询数据是否存在,减轻数据库压力。
- 前端请求检测
下面重点说以下布隆过滤器,这是一个概率学的算法实现,布隆过滤器有以下特点:
符合布隆过滤器不一定存在,不符合布隆过滤器一定不存在。
布隆过滤器由一个初值都为 0 的 bit 数组和 N 个哈希函数组成,可以用来快速判断某个数据是否存在。当我们想标记某个数据存在时(例如,数据已被写入数据库),布隆过滤器会通过三个操作完成标记:
- 首先,使用 N 个哈希函数,分别计算这个数据的哈希值,得到 N 个哈希值。
- 然后,我们把这 N 个哈希值对 bit 数组的长度取模,得到每个哈希值在数组中的对应位置。
- 最后,我们把对应位置的 bit 位设置为 1,这就完成了在布隆过滤器中标记数据的操作。
这样,当应用想要查询 X 时,只要 比较原来为1的位置 是否包含于 x计算后为1的位置中,一旦又一个不符合(为0),则不在缓存中,否则可能在。
5.5. 缓存污染
在一些场景下,有些数据被访问的次数非常少,甚至只会被访问一次。当这些数据服务完访问请求后,如果还继续留存在缓存中的话,就只会白白占用缓存空间。这种情况,就是缓存污染。
需要根据业务设置合适的缓存淘汰(驱逐)策略。
5.6. 数据倾斜
在Redis切片集群中比较容易遇到的一个问题:数据倾斜:
- 数据量倾斜:在某些情况下,实例上的数据分布不均衡,某个实例上的数据特别多。
- 数据访问倾斜:虽然每个集群实例上的数据量相差不大,但是某个实例上的数据是热点数据,被访问得非常频繁。
这里po一个表格:
6. 参考
- 李智慧的极客时间课程
- 水滴与银弹的博客
- Redis的过期策略有哪些