机器的内存大小毕竟有限,随着要缓存的数据量越来越大,有限的缓存空间不可避免地会被写满。
解决这个问题就涉及缓存系统的一个重要机制,即缓存数据的淘汰机制。简单来说,数据淘汰机制包括两步:
- 根据一定策略,筛选出对应用系统来说“不重要”的数据。
- 将这些数据从缓存中删除,为新来的数据腾出空间。
缓存容量设置
操作系统的缓存容量是有限的,而且也不可能完全都分配给 Redis 使用,这就需要考虑设置多大的缓存容量合适呢?缓存容量设置得是否合理,会直接影响到使用缓存得性价比。我们通常都希望以最小的代价去获取最大的收益,内存资源是昂贵的,合理分配就显得很重要了。
缓存容量的划分是需要结合应用数据实际访问特征和成本开销总和考虑的。
系统的设计选择是一个权衡的过程:大容量缓存是不能带来加速的收益的,且成本也会更高,而小容量缓存不一定就起不到加速访问的效果。一般来说,建议把缓存容量设置为总数据量的 15% ~ 30%,兼顾访问性能和内存空间开销。
即使设置了合理的缓存容量,缓存被写满也是不可避免的,一旦被写满了就需要淘汰部分数据腾出空间,不过淘汰数据前会面临两个问题:
- 淘汰哪些数据。
- 如果处理这些被淘汰的数据。
Redis 有哪些淘汰策略
截止到目前版本 Redis 一共提供了 8 种内存淘汰策略:
noenviction | 禁止淘汰策略,这也是默认策略。这种策略下 Redis 不再提供服务,而是直接返回错误。 |
volatile-lru | 从已设置过期时间的数据集中选出最近最少使用的数据淘汰 |
volatile-ttl | 从已设置过期时间的数据集中选出将要过期的数据淘汰,根据过期时间为依据,越早过期的越先被删除 |
volatile-random | 从已设置过期时间的数据集中随机选择数据淘汰 |
volatile-lfu | 从已设置过期时间的数据集中选出使用频率最低的数据淘汰 |
allkeys-lru | 从数据集中选出最近最少使用的数据淘汰 |
allkeys-lfu | 从数据集中选出使用频率最低的数据淘汰 |
allkeys-random | 从数据集中随机选出数据淘汰 |
分类
我们可以对这些淘汰策略进行下分类,按照是否会进行数据淘汰分为两类:
- 不进行数据淘汰的策略,只有 noeviction。
- 剩下 7 种都是会进行数据淘汰的。
会进行数据淘汰的策略,根据淘汰候选数据集的范围分为两类:
- 设置了过期时间的数据中进行淘汰,包括:volatile-lru、volatile-ttl、volatile-random、volatile-lfu,即使缓存没有写满,如果数据过期了也会被删除。
- 在所有数据范围内进行淘汰,包括:allkeys-lru、allkeys-random、allkeys-lfu,如果一个键值对被删除策略选中了,即使它的过期时间还没到,也需要被删除。如果过期时间到了没有被策略选中,也会被删除。
LRU 算法
volatile-lru 和 allkeys-lru 策略都用到了 LRU 算法,那就一块了解下 LRU(Least Recently Used) 算法吧。
LRU 算法是按照最近最少使用的原则来筛选数据,最不常用的数据会被筛选出来,而最近频繁使用的数据会留在缓存中。
具体怎么筛选呢?LRU 会把所有的数据组织成一个链表,链表的头和尾分别表示 MRU 端和 LRU 端,分别代表最近最常使用的数据和最近最不常使用的数据。
根据 LRU 算法,刚被访问过的数据会被移到 MRU 端,就尽可能地留在缓存中了。
如果是有一个新数据要被写入缓存,当此时已经没有了缓存空间,也就是链表没有空余位置了,那么 LRU 算法会做两件事:
- 如果有刚被访问的数据会放到 MRU 端。
- 算法会把 LRU 端的一个数据从缓存中删除,这个数据在链表中就不存在了,就腾出了空间。
Redis 近似 LRU 算法
LRU 算法在实现时,需要用链表来管理所有的缓存数据,这会带来额外的空间开销,而且还会进行数据移动,会很耗时,会对性能有影响。
Redis 就对 LRU 算法做了简化。Redis 默认会记录每个数据的最近一次访问的时间戳。然后 Redis 在决定淘汰数据时,第一次会随机选出 N 个数据,把它们作为一个候选集合。接下来,Redis 会比较这 N 个数据的 lru 字段,把 lru 字段值最小的数据从缓存中淘汰出去。
这个参数 N 是可以设置的:
maxmemory-samples 100
或者
config set maxmemory-samples 100
当再次淘汰数据时,Redis 需要选出数据进入第一次淘汰时创建的候选集合,挑选标准是:能进入候选集合的数据的 lru 字段必须小于候选集合中最小的 lru 值。当有新数据进入候选数据集后,如果候选数据集数据个数达到了 maxmemory-samples,Redis 就把候选数据集中 lru 字段最小的数据淘汰出去。 但是有一点需要说明下,如果候选集链表没有空间了,后续还有比链表中更小的 lru 值时,候选集链表头的数据就会被移出候选集(并不是淘汰了),给新数据腾出空间。
LFU 缓存策略
LFU 缓存策略是在 LRU 策略基础上,为每个数据增加了一个计数器。当使用了 LFU 策略筛选淘汰数据时,首先会根据数据的访问次数进行筛选,把访问次数最低的数据淘汰出缓存。如果两个数据的访问次数相同,LFU 策略再比较两个数据的访问时效性,把举例上一次访问时间更久的数据淘汰出缓存。
Redis LRU 策略是用 RedisObject 结构来保存数据的,RedisObject 结构中设置了一个 lru 字段,用来记录数据的访问时间戳。Redis 在实现 LFU 策略时,只是把原来 24bit 大小的 lru 字段拆分为了两部分:
- ldt 值:lru 字段的前 16bit,表示数据的访问时间戳。
- counter 值:lru 字段的后 8bit,表示数据的访问次数,每次访问都会加 1。
counter 值是 8bit 最大记录是 255,一个数据可能会被访问成千上万次,每次都加 1,超过了 255,那么多个数据被访问过后,counter 都变成了 255。
在实现 LFU 策略时,Redis 并没有采用数据每被访问一次就加 1 的技术规则,而是采用了一个更优化的规则。是根据有个配置项 lfu_log_factor
来进行计算的,可以控制计数器值增加的速度。
LFU 策略的计数规则是:
每当数据被访问一次时,首先,用计数器当前的值乘以配置 lfu_log_factor
再加 1,再取其倒数,得到一个 p 值;然后,把 p 值和一个取值范围在(0, 1) 间的随机数 r 值比大小,只有 p 值大于 r 值时,计数器才加 1。
这张图就是 log_lfu_factor
不同取值时,计数器值增加的速度,在应用 LFU 策略时,一般可以将 lfu_log_factor
取值为10。
counter 值衰减机制
有些数据在短时间内被大量访问后就不会在被访问了,再按照访问次数来筛选的话,这些数据会被留存在缓存中,但不会提升缓存命中率。
Redis 在实现 LFU 策略时,还设计了一个衰减机制。
LFU 策略使用衰减因子配置项 lfu_decay_time
来控制访问次数的衰减。LFU 策略会计算当前时间和最近一次访问时间的差值,并把这个差值换算成以分钟为单位。然后,LFU 策略再把这个差值除以 lfu_decay_time
值,所得的结果就是数据 counter 要衰减的值。
比如说,假设 lfu_decay_time
为 1,如果数据在 N 分钟内没有被访问,那么它的访问次数就要减 N。如果 lfu_decay_time
取值更大,那么相应的衰减值会变小,衰减效果也会减弱。
如果业务中有短时高频访问的数据话,建议 lfu_decay_time
设置为 1,LFU 策略在他们不再被访问后,会较快地衰减访问次数,尽早的从缓存中淘汰出去。
使用建议:
- 优先使用 allkeys-lru 策略。充分利用 LRU 算法的优势,把最近最常访问的数据留在缓存中。如果业务有明显的冷热数据区分,建议使用。
- 如果业务中数据访问频率差别不大,没有明显冷热数据区分,建议使用 allkeys-random,随机选择淘汰。
- 如果业务中有置顶的需求,可以使用 volatile-lru 策略,同时置顶数据不设置过期时间,这些数据就一直不被删除,会淘汰其他设置过期时间的数据。
- 如果业务中有短时高频访问的数据,可以使用 allkeys-lfu 或 volatile-lfu 策略。