应对Redis缓存污染问题，你应该知道这些内容

站长

2022年11月21日 15:13 · 阅读数 16

本文正在参加「金石计划 . 瓜分6万现金大奖」

前言

我们在使用Redis做为缓存时，能加速我们对于热点数据的查询。但是如果缓存中有大量的数据不再热门了，从而占据着大量的内存空间，那么我们的Redis性能就会收到很大影响。该如何解决这个问题呢？本文给你答案。

什么是缓存污染

就是在redis的数据，如果被访问的次数极少，在缓存中起到的作用就不大，若不处理的话，还会占用缓存空间。这就是缓存污染。

当这些污染数据不多时，对缓存系统影响不大。但污染数据变得很多之后，缓存空间就堆积了大量无用数据。这个时候我们要再往缓存写数据，就得将这些数据淘汰掉。这个淘汰过程又会带来额外的开销，影响Redis的性能。

缓存污染解决方案

说到底，解决缓存污染的根本方式就是将这些访问极少的数据找出来删掉就行了。问题就在于如何筛选出污染数据。联想到Redis的八大缓存淘汰策略，我们来看看用哪种淘汰策略最合适。

淘汰策略	策略释义
noeviction	不会数据淘汰：缓存满了不再接收写请求，返回错误
volatile-random	对设置了过期时间的数据随机删除
volatile-ttl	根据过期时间的先后删除设置了过期时间的
volatile-lru	使用LRU算法筛选设置了过期时间的数据然后删除
volatile-lfu（Redis 4.0 后）	使用LFU算法筛选设置了过期时间的数据然后删除
allkeys-lru	使用LRU算法对所有数据筛选后删除
allkeys-random	随机对所有数据筛选后删除
allkeys-lfu(Redis4.0后)	使用LFU算法对所有数据筛选后删除

先剔除掉几个策略：

noeviction策略：noeviction策略是不淘汰数据，因此不能作为缓存污染问题的策略。
volatile-random 和 allkeys-random策略：都是采用随机筛选数据淘汰，不会因为数据是否访问来筛选。因此若热门数据被随机选中删除了，后续访问会出现缓存缺失，并解决不了问题。因此也不适合。
volatile-ttl策略：筛选的是设置了过期时间的数据。但距离过期时间的长短，并不能体现出数据的访问情况。淘汰数据后也还是容易出现缓存缺失问题。所以也不适合。

这样一来，8大策略就被我们排除了4个策略，也就剩下了volatile-lru、allkeys-lru、volatile-lfu、allkeys-lfu四种策略，按照淘汰算法来看就剩lru策略和lfu策略了。下面分别分析下lru和lfu在缓存污染问题上是否适用。

LRU淘汰策略

首先我们看看LRU算法策略的定义就是：认为最近使用过的数据是有用的，淘汰的是那些最近没被使用的数据。

Redis根据LRU这个算法策略，在每个数据的 RedisObject结构体中设计了一个lru字段，这个字段会记录数据最近一次访问的时间戳。 当触发了数据淘汰的动作时，如果我们用的是volatile-lru或者allkeys-lru策略，Redis就会在候选的数据集合中筛选出lru字段最小的数据（也就是时间戳最小，被访问的时间最早）。

我们知道了Redis LRU是如何淘汰数据的，再来分析一下LRU是否在缓存污染问题上适用。

LRU策略只关注数据的访问时间，而缓存污染问题主要关注数据的访问频次。因此，在缓存污染问题上，LRU淘汰策略也不是最合适的。 用个图例来看看吧。

应对Redis缓存污染问题，你应该知道这些内容

如上面图例，数据5写到缓存之后，一直没有被访问。经过3次数据淘汰之后，数据5依然还在缓存中，这就是缓存污染问题还没解决。因此，使用LRU策略，在这种缓存污染问题上效果不好。

在实际应用中，有些数据只是偶尔查询少数几次，后续就基本不查了。比如订单数据有很多，通常缓存中保留的是最近订单数据。我们排查某些订单问题时，有条去年的订单会取出来看看具体数据情况，查完解决问题后基本就不用了。如果用的是LRU策略，这条数据就可能在缓存中保留很长一段时间。

这样看来，LRU策略也不是很擅长解决缓存污染问题，最后再来看看LFU淘汰策略。

LFU淘汰策略

LFU淘汰策略，它是redis4.0之后才加入的淘汰策略。它的出现就是旨在解决LRU策略在数据访问频次的缺陷的。

LFU淘汰策略的定义就是筛选出最近时间最少使用的数据。 根据这段定义，我们大概就能知道LFU策略就适用于解决缓存污染问题了。那么我们来看看redis的LFU是如何设计的。

通过上文LRU的解释，我们都知道Redis数据的RedisObject 结构有一个lru字段。在LFU策略中，并没有在RedisObject 结构上新增类似lfu的字段，而是在lru字段上做了额外动作。lru字段大小为24bit，lfu的实现是这样的：

ldt值：lru字段前16位保存的是数据最近访问的时间戳；
counter值：lru字段后8位用来保存数据的访问次数。

应对Redis缓存污染问题，你应该知道这些内容

通过对lfu字段的剖析，很容易分析得出：当使用LFU淘汰策略时，Redis在候选数据集中，会根据lru字段的counter值筛选最小的数据出来。如果存在多个counter值相同的数据，就再比较lru字段的ldt值，取出ldt值最小的数据出来淘汰。

LFU counter计数策略

还有个问题就是：8位的数值最大就到255，lru的counter值只能到255吗？那超过255的不就无法比较了？显然不是，Redis在记录数据counter值的时候，并不是每访问一次，就给counter+1。具体做法是这样的：

/* Logarithmically increment a counter. The greater is the current counter value
 * the less likely is that it gets really implemented. Saturate it at 255. */
uint8_t LFULogIncr(uint8_t counter) {
    if (counter == 255) return 255;
	// 随机生成一个0-1之间的浮点数r
    double r = (double)rand()/RAND_MAX;
	// 当前counter减去常量LFU_INIT_VAL（默认为5）
    double baseval = counter - LFU_INIT_VAL;
    if (baseval < 0) baseval = 0;
	// server.lfu_log_factor是配置项
    double p = 1.0/(baseval*server.lfu_log_factor+1);
	// 如果随机数r<p，counter+1
    if (r < p) counter++;
    return counter;
}

由上面Redis LFU源码（源码位于redis目录下的/src/evict.c文件）可以得知数据被访问是counter的变化：

生成一个0-1之间的随机浮点数r;
用数据当前的counter - LFU_INIT_VAL得到值baseval（LFU_INIT_VAL默认为5）；
用上面得到的 baseval * 配置项lfu_log_factor + 1，然后取倒数，这样就得到了值p；
最后比较p和随机数r，只有p>r时，counter才会加1。

通过源码分解，我们就能知道counter值不是简单的累加了，而是通过配置项 lfu_log_factor和随机数的对比来控制counter的累加的 。我们可通过配置lfu_log_factor值来控制计数器counter的增长速度，lfu_log_factor设置的越大，counter增长速度越慢。

应对Redis缓存污染问题，你应该知道这些内容

上图是Redis官方文档中lfu_log_factor取值为0、1、10、100时，数据被访问次数对应的counter值。比如lfu_log_factor设置为10时，访问次数达到1百万时，counter值才达到255。我们普通的应用，将lfu_log_factor设置为10就基本够用了。

我们有些业务场景，部分数据在一段时间内会被大量的访问，之后就几乎不访问了。如果只有上述策略，counter值会一直很大，从而在缓存中一直留着。

为了解决这个问题，Redis LFU除了访问次数counter的优化，LFU还有用配置项 lfu_decay_time 来控制访问次数的衰减，这就是衰减访问次数策略。

衰减访问次数策略

unsigned long LFUDecrAndReturn(robj *o) {
    unsigned long ldt = o->lru >> 8;
	// 获取当前的访问次数
    unsigned long counter = o->lru & 255;
    // 计算衰减因子
    unsigned long num_periods = server.lfu_decay_time ? LFUTimeElapsed(ldt) / server.lfu_decay_time : 0;
    if (num_periods)
	// 若衰减因子不等于0，且衰减因子 > 访问次数，则访问次数=0；否则访问次数置为 当前访问次数-衰减因子
        counter = (num_periods > counter) ? 0 : counter - num_periods;
    return counter;
}

上图是Redis LFU衰减因子部分源码，简单来说就是用当前时间戳和最近一次访问的时间ldt的差值（差值要转换为分钟单位），然后这个差值 / lfu_decay_time就是衰减因子。 然后用这个衰减因子和当前计数counter比较，若衰减因子 > 访问次数，则访问次数=0；否则访问次数置为当前访问次数-衰减因子。

lfu_decay_time默认值为1，举个例子来说，比如数据A上一次被访问在10分钟前，衰减因子就= 10 / 1 = 10。如果当前计数counter=11，然后经过衰减策略之后，计数counter就是11 - 9 = 2。

通过衰减访问次数的策略，就能更快的衰减掉那些短时间内高频访问后续少访问的数据了。通过以上分析，解决缓存污染问题用LFU淘汰策略就比较适合了。

小结

本文总结了如何去解决redis缓存污染问题，通过分析Redis 8大淘汰策略对缓存污染问题的适用性，重点解析了Redis LRU淘汰策略和LFU淘汰策略，最后选择了LFU淘汰策略来解决缓存污染问题。