前言
Redis 缓存使用内存来保存数据,避免业务应用直接从数据库读取数据,可以提升应用的访问速度。但是,我们又没有办法做到把所有的数据都放入缓存,因为这样做的性价比不高,而且缓存也存不下数据库中的所有数据。
例如,Mysql 中有 1TB 的数据,如果使用 Redis 把这些数据都缓存起来,虽然应用都能在内存中访问数据了,但是这样配置并不合理,因为性价比低。一方面内存的价格比磁盘的价格贵很多。另一方面,数据访问都是有局部性的,也就是“二八原理”,80% 的请求实际只访问了 20% 的数据。所以,用 1TB 的内存做缓存,并没有必要。
所以,缓存的容量必然小于数据库的总量。有限的缓存空间也不可避免的会被写满。此时就要涉及到缓存系统的一个重要机制了,即缓存数据的淘汰机制。淘汰机制分为两步:
- 根据一定的策略,选出对应用访问来说“不重要”的数据;
- 将这些数据从缓存中删除,为新来的数据腾出空间;
缓存满了之后的数据淘汰机制,也叫作缓存替换机制。了解缓存淘汰机制和相应的策略,才可以选择合理的 Redis 配置,提高缓存命中率,提升应用的访问性能。
在学习淘汰策略之前,我们首先要知道设置缓存容量的依据和方法。毕竟,在实际使用缓存时,我们需要决定用多大的空间来缓存数据。
1.设置多大的缓存合适
缓存容量设置的是否合理,会直接影响到使用缓存的性价比。我们通常希望以最小的代价去获得最大的收益,所以,把昂贵的内存资源用在关键的地方就非常重要了。
实际应用中的数据访问是有局部性的。如果按照“二八原理”来设置缓存空间容量,也就是把缓存空间容量设置为总数据量的 20% ,就有可能拦截到 80% 的访问。
为什么说是“有可能”呢?这是因为,“八二原理”是对大量实际应用的数据访问情况做了统计后,得出的一个统计学意义上的数据量和访问量的比例。具体到一个应用来说,数据访问的规律会和具体的业务场景有关。对于最常被访问的 20% 的数据来说,它们贡献的访问量,既有可能超过 80%,也有可能达不到 80%。
在商品促销时,热门商品的信息可能只占到总商品数量的 5%,而这些商品信息承载可能超过 90% 的访问请求。这时,我们只要缓存这 5% 的数据,就能获得很好的性能收益。
另一方面,如果业务应用要对所有商品信息进行查询统计,这时候,即使按照“八二原理”缓存了 20% 的商品数据,也不能获得很好的访问性能,因为 80% 的数据仍然需要从后端数据库中获取。
正式因为 20% 的数据不一定能贡献 80% 的访问量,我们不能简单地按照“总数据量的 20%”来设置缓存最大空间容量。在实践过程中,我看到过的缓存容量占总数量的比例,从 5% 到 40% 的都有。这个容量规划不能一概而论,需要结合应用数据实际访问特征和成本开销来综合考虑的。
系统的设计选择是一个权衡的过程:大容量缓存是能带来性能加速的收益,但是成本也会更高,而小容量缓存不一定就起不到加速访问的效果。一般来说,我会建议把缓存容量设置为总数据量的 15% 到 30%
,兼顾访问性能和内存空间开销。
对于 Redis 来说,一旦确定了缓存最大容量,比如 4GB,你可以使用下面这个命令来设定缓存的大小了:
127.0.0.1:6379> config set maxmemory 4gb
OK
不过,缓存被写满是不可避免的。即使你精挑细选,确定了缓存容量,还是要面对缓存写满时的替换操作。缓存替换需要解决两个问题:决定淘汰哪些数据,如何处理那些被淘汰的数据。
2.Redis 缓存的淘汰策略
Redis 4.0 之前一共实现了 6 种内存淘汰策略,在 4.0 之后,又增加了 2 种策略。我们可以按照是否会进行数据淘汰把他们分成两类:
- 不进行数据淘汰策略,只有
noeviction
这一种。 - 会进行淘汰的 7 种其他策略。
会进行淘汰的 7 种策略,我们可以再进一步根据淘汰候选数据集的范围,把它们分成两类:
- 在设置了过期时间的数据中进行淘汰,包括
volatile-random
、volatile-ttl
、volatile-lru
、volatile-lfu
(Redis 4.0 后新增) - 在所有数据范围内进行淘汰,包括
allkeys-random
、allkeys-lru
、allkeys-lfu
(Redis 4.0 后新增)
默认情况下,Redis 在使用的内存空间超过 maxmemory
值时,并不会淘汰数据,也就是设定的设定的 noeviction 策略
。也就是指,一旦缓存被写满了,再有写请求来时,Redis 不在提供服务,而是直接返回错误。
再来分析下 volatile-random
、volatile-ttl
、volatilr-lru
、volatile-lfu
这四种淘汰策略。它们只会淘汰 已经设置了过期时间的键值对 上。即使缓存没有写满,这些数据过期了,也会被删除。
例如,使用 EXPIRE
命令对一批键值对设置了过期时间后,无论这些键值对过期时间是快到了,还是 Redis 的内存使用量达到了 maxmemory
阈值,Redis 都会按照 volatile-random
、volatile-ttl
、volatilr-lru
、volatile-lfu
这四种淘汰策略进行淘汰。
volatile-random
在设置了过期时间的键值对中,进行随机删除。volatile-ttl
针对设置了过期时间的键值对,根据时间先后顺序进行删除,越早过期的越先被淘汰。volatile-lru
会使用LRU
算法筛选设置了过期时间的键值对。volatile-lfu
会使用LFU
算法筛选设置了过期时间的键值对。
volatile-random
、volatile-ttl
的淘汰规则比较简单,而volatilr-lru
涉及了LRU
算法,会在稍后的allkeys-lru
进行解释。volatilr-lfu
使用了LFU
算法,我们会在后续的 Redis 缓存污染章节进行解释。现在,你只要知道,LFU
算法是在LRU
算法的基础上,同时考虑了数据的访问时效和数据的访问次数,可以看作是对淘汰策略的优化。
allkeys-random
、 allkeys-lru
、allkeys-lfu
是在所有键值对中进行淘汰,无论这些键值对是否设置了过期时间。
allkeys-random
,从所有键值对中随机选择并删除数据allkeys-lru
,使用LRU
算法在所有键值对中进行筛选allkeys-lfu
,使用LFU
算法在所有键值对中进行筛选
接下来,一起看看 volatile-lru
和 allkeys-lru
策略都用到的 LRU 算法。
LRU
算法的全称是 Least Recently Used
,即按照最近最少使用的原则来淘汰数据。把最不常用的数据筛选出来,而最近频繁使用的数据则会留在缓存中。
LRU
是如何筛选数据的呢?
LRU
会把所有的数据组织成一个链表,链表的头和尾分别表示 MRU 端
和 LRU 端
,分别代表最近常使用的数据和最近不常用的数据。我们看一个例子:
我们现在有数据 【6、3、9、20、5】。如果 20 和 3 被先后访问,它们都会从现有的链表位置移到 MRU端
,而在它之前的数据则相应地往后移动一位。因为,LRU
算法选择删除数据时,都是从 LRU 端
开始,所以把刚刚访问过的数据移到 MRU 端
,就可以让它们尽可能地留在缓存中。
如果一个新数据 15 要被写入缓存,但此时已经没有缓存空间了,也就是链表没有空余位置了,那么 LRU
算法做两件事:
- 数据 15 是被刚被访问的,所以它会被放到
MRU 端
。 - 算法把
LRU 端
的数据 5 从缓存中删除
其实,LRU
算法背后的原理很朴实:它仍为刚刚被访问的数据,肯定还会被再次访问,所以把它放到 MRU 端
;长久不访问的数据,肯定不会再被访问,所以就让它逐渐后移到 LRU 端
,在缓存满时,就先删除它。
不过,
LRU
算法在实际实现时,需要用链表管理所有的缓存数据,这会带来额外的空间开销。而且,当有数据被访问时,需要在链表上把数据移动到MRU 端
,如果有大量的数据被访问,就会带来很多链表移动操作,会耗时,进而降低 Redis 缓存性能。
在 Redis 中,LRU
算法被做了简化,以减轻数据淘汰对缓存性能的影响。具体来说,Redis 默认会记录每个数据最近一次访问的时间戳(由键值对数据结构 RedisObject 中的 lru 字段记录)。然后,Redis 在决定淘汰数据时,第一次会随机选出 N 个数据,把它们作为一个候选集合。接下来,Redis 会比较这 N 个数据的 lru 字段,把 lru 字段值最小的数据从缓存中淘汰出去。
Redis 提供了一个配置参数 maxmemory-samples
,这个参数就是 Redis 选出数据的个数 N。例如,执行下面命令,可以让 Redis 选出 100 个数据作为候选数据集:
CONFIG SET maxmemory-samples 100
当需要再次淘汰数据时,Redis 需要挑选数据进入第一次淘汰时创建的候选集合。挑选标准是:能进入候选集的数据的 lru 字段值必须小于候选集合中最小的 lru 值。当有新数据进入候选数据集后,如果候选数据集中的数据个数达到了 maxmemory-samples
,Redis 就把候选数据集中 lru 字段值最小的数据淘汰出去。
这样一来,Redis 缓存不用为所有数据维护一个大表,也不用在每次数据访问时都移动链表项,提升了缓存的性能。
这里总结了三个淘汰策略的使用建议:
- 优先使用 allkeys-lru 策略。这样充分利用 LRU 这一经典算法的优势,把最近最常访问的数据留在缓存中,提升应用的访问性能。如果你的业务数据中有明显的冷热数据区分,我建议你使用
allkeys-lru
策略。 - 如果业务应用中的数据访问频率相差不大,没有明显的冷热数据区分,建议使用
allkeys-random
策略,随机选择淘汰的数据就行。 - 如果你的业务中有置顶的需求,比如说置顶新文、置顶视频,那么,可以使用
volatile-lru
策略,同时不给这些置顶数据设置过期时间。这样一来,这些需要置顶的数据一直不会被删除,而其他的数据会在过期时根据 LRU 规则进行筛选。
3.如何处理被淘汰的数据
一般来说,一旦被淘汰的数据选定后,如果这个数据是干净数据,那么我们就直接删除;如果是脏数据,我们需要把它写回数据库,如下所示:
干净数据和脏数据的区别在于,和最初后后端数据库例读取时的值相比,有没有被修改过。干净数据是没有被修改过,所以后端数据库的数据也是最新的。在替换时,它可以被直接删除。
而脏数据就是被修改过的,已经和数据库中的数据不一致了。此时,如果不把脏数据写回到数据库中,这个数据的最新值就丢失了,就会影响应用的正常使用。
这么一来,缓存替换既腾出了缓存空间,用来缓存新的数据,同时,将脏数据写回数据库,也保证了最新数据不会丢失。
不过,对于 Redis 来说,它决定了被淘汰的数据后,会把它们删除。即使淘汰的数据是脏数据,Redis 也不会把它们写回数据库。所以,我们在使用 Redis 缓存时,如果数据被修改了,需要在数据修改时就将它写回数据库。否则,这个脏数据被淘汰时,会被 Redis 删除,而数据库里也没有最新的数据了。