Redis系列 - 缓存淘汰策略

在使用Redis时，我们一般会为Redis的缓存空间设置一个大小，不会让数据无限制的放入Redis缓存。

对于 Redis 来说，一旦确定了缓存最大容量，比如 4GB，你就可以使用下面这个命令来设定缓存的大小了：

CONFIG SET maxmemory 4gb

Redis设置了缓存的容量大小，那么缓存被写满是不可避免的。我们需要面对缓存写满时的替换操作。缓存替换需要解决两个问题：决定淘汰哪些数据，如何处理那些被淘汰的数据。

Redis有哪些淘汰策略

  • noevction：一旦缓存被写满了，再有写请求来时，Redis 不再提供服务，而是直接返回错误。Redis 用作缓存时，实际的数据集通常都是大于缓存容量的，总会有新的数据要写入缓存，这个策略本身不淘汰数据，也就不会腾出新的缓存空间，我们不把它用在 Redis 缓存中。
  • volatile-ttl 在筛选时，会针对设置了过期时间的键值对，根据过期时间的先后进行删除，越早过期的越先被删除。
  • volatile-random 就像它的名称一样，在设置了过期时间的键值对中，进行随机删除。
  • volatile-lru 会使用 LRU 算法筛选设置了过期时间的键值对。
  • volatile-lfu 会使用 LFU 算法选择设置了过期时间的键值对。
  • allkeys-random 策略，从所有键值对中随机选择并删除数据。
  • allkeys-lru 策略，使用 LRU 算法在所有数据中进行筛选。
  • allkeys-lfu 策略，使用 LFU 算法在所有数据中进行筛选。

通常情况下推荐优先使用 allkeys-lru 策略。这样，可以充分利用 LRU 这一经典缓存算法的优势，把最近最常访问的数据留在缓存中，提升应用的访问性能。如果你的业务数据中有明显的冷热数据区分，我建议你使用 allkeys-lru 策略。如果业务应用中的数据访问频率相差不大，没有明显的冷热数据区分，建议使用 allkeys-random 策略，随机选择淘汰的数据就行。

Redis中的LRU和LFU算法

LRU算法

LRU 算法的全称是 Least Recently Used，从名字上就可以看出，这是按照最近最少使用的原则来筛选数据，最不常用的数据会被筛选出来，而最近频繁使用的数据会留在缓存中。

LRU 会把所有的数据组织成一个链表，链表的头和尾分别表示 MRU 端和 LRU 端，分别代表最近最常使用的数据和最近最不常用的数据。我们看一个例子。

redis替换成hutool redis缓存替换策略_Redis

如果有一个新数据 45 要被写入缓存，但此时已经没有缓存空间了，也就是链表没有空余位置了，那么，LRU 算法做两件事：数据 45 是刚被访问的，所以它会被放到 MRU 端；算法把 LRU 端的数据 5 从缓存中删除，相应的链表中就没有数据 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 缓存不用为所有的数据维护一个大链表，也不用在每次数据访问时都移动链表项，提升了缓存的性能。

LFU算法

LFU是在Redis4.0后出现的，LRU的最近最少使用实际上并不精确，考虑下面的情况，如果在|处删除，那么A距离的时间最久，但实际上A的使用频率要比B频繁，所以合理的淘汰策略应该是淘汰B。LFU就是为应对这种情况而生的。

LFU (Least Frequently Used) ：最近最少使用，跟使用的次数有关，淘汰使用次数最少的。

LRU (Least Recently Used): 最近最不经常使用，跟使用的最后一次时间有关，淘汰最近使用时间离现在最久的。

~~~~~A~~~~~A~~~~~A~~~~A~~~~~A~~~~~A~~|
~~R~~R~~R~~R~~R~~R~~R~~R~~R~~R~~R~~R~|
~~~~~~~~~~C~~~~~~~~~C~~~~~~~~~C~~~~~~|
~~~~~D~~~~~~~~~~D~~~~~~~~~D~~~~~~~~~D|

每个波浪号代表一秒，A 每五秒，R 每两秒，C 和 D 每十秒 （如果不是等宽字体，看上去长度可能不一致，实际字符数是一样的）， 最近被访问的字符是 D，但显然按照现有的规律，下一个被访问的更可能是 R 而不是 D。

LRU 实现上比较简单，最简单的只需要 链表和Map 就够了，移除元素时直接从链表队尾移除，增加时加到头部就可以了。

但实际上 Redis 的实现并不是这样， Redis 的实现非常直接，几乎就是 LRU 本身的意思。Redis 本身有全局的时钟 server.lruclock（单位为秒,24位，190多天会溢出），然后随机采样 N 个 key 的访问时间，离现在最久的，淘汰之。

redis 对象（简单理解为一个 key-value）定义如下：

typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
                            * LFU data (least significant 8 bits frequency
                            * and most significant 16 bits access time). */
    int refcount;
    void *ptr;
} robj;

LFU 实现更为复杂，需要考虑几个问题：

  1. 如果实现为链表，当对象被访问时按访问次数移动到链表的某个有序位置可能是低效的，因为可能存在大量访问次数相同的 key，最差情况是O(n) （链表无法直接用二分查找,可以用 跳表？）
  2. 某些 key 访问次数可能非常之大，理论上可以无限大，但实际上我们并不需要精确的访问次数
  3. 访问次数特别大的 key 可能以后都不再访问了，但是因为访问次数大而一直占用着内存不被淘汰，需要一个方法来逐步“驱除”（有点 LRU的意思），最简单的就是逐步衰减访问次数

本着能省则省的原则，Redis 只用了 24bit （server.lruclock 也是24bit）来记录上述的信息，是的不是 24byte，连32位指针都放不下！

16bit : 上一次递减时间 （解决第三个问题）

8bit : 访问次数 （解决第二个问题）

访问次数的计算如下：

uint8_t LFULogIncr(uint8_t counter) {
    if (counter == 255) return 255;
    double r = (double)rand()/RAND_MAX;
    double baseval = counter - LFU_INIT_VAL;
    if (baseval < 0) baseval = 0;
    double p = 1.0/(baseval*server.lfu_log_factor+1);
    if (r < p) counter++;
    return counter;
}

核心就是访问次数越大，访问次数被递增的可能性越小，最大 255，此外你可以在配置 redis.conf 中写明访问多少次递增多少。

由于访问次数是有限的，所以第一个问题也被解决了，直接一个255数组或链表都可以。

16bit 部分怎么用呢？保存的是时间戳的后16位（分钟），表示上一次递减的时间，算法是这样执行，随机采样N个key(与原来的版本一样)，检查递减时间，如果距离现在超过 N 分钟（可配置），则递减或者减半（如果访问次数数值比较大）。

此外，由于新加入的 key 访问次数很可能比不被访问的老 key小，为了不被马上淘汰，新key访问次数设为 5。