24 | 替换策略：缓存满了怎么办？

---

Redis核心技术与实战

实践篇

24 | 替换策略：缓存满了怎么办？

设置多大的缓存容量合适？

蓝线表示的是 “八二原理”，有 20% 的数据贡献了 80% 的访问，而剩余的数据虽然体量很大，但只贡献了 20% 的访问量，这 80% 的数据在访问量上就形成了一条长长的尾巴，称为 “长尾效应”。

如果按照“八二原理”来设置缓存空间容量，也就是把缓存空间容量设置为总数据量的 20% 的话，就有可能拦截到 80% 的访问。

红线上 80% 的数据贡献的访问量，超过了传统的长尾效应中 80% 数据能贡献的访问量。原因在于，用户的个性化需求越来越多，在一个业务应用中，不同用户访问的内容可能差别很大，所以，用户请求的数据和它们贡献的访问量比例，不再具备长尾效应中的“八二原理”分布特征。也就是说，20% 的数据可能贡献不了 80% 的访问，而剩余的 80% 数据反而贡献了更多的访问量，称之为 “重尾效应”。
正是因为 20% 的数据不一定能贡献 80% 的访问量，所以不能简单地按照“总数据量的 20%”来设置缓存最大空间容量。这个容量规划不能一概而论，是需要结合应用数据实际访问特征和成本开销来综合考虑的。

Redis 设置缓存最大容量的命令如下：

CONFIG SET maxmemory 4gb

缓存被写满是不可避免的。

Redis 缓存有哪些淘汰策略？

Redis 4.0 之前一共实现了 6 种内存淘汰策略，在 4.0 之后，又增加了 2 种策略。

按照是否会进行数据淘汰把它们分成两类：

• 不进行数据淘汰的策略，只有 noeviction 这一种。
• 会进行淘汰的 7 种其他策略。

会进行淘汰的 7 种策略，可以再进一步根据淘汰候选数据集的范围把它们分成两类：

• 在设置了过期时间的数据中进行淘汰，包括 volatile-random、volatile-ttl、volatile-lru、volatile-lfu（Redis 4.0 后新增）四种。
• 在所有数据范围内进行淘汰，包括 allkeys-lru、allkeys-random、allkeys-lfu（Redis 4.0 后新增）三种。

默认情况下，Redis 在使用的内存空间超过 maxmemory 值时，并不会淘汰数据，也就是设定的 noeviction 策略（在redis3.0之前，默认是volatile-lru；在redis3.0及之后，默认淘汰策略则是noeviction）。 对应到 Redis 缓存，也就是指，一旦缓存被写满了，再有写请求来时，Redis 不再提供服务，而是直接返回错误。

volatile-random、volatile-ttl、volatile-lru 和 volatile-lfu 这四种淘汰策略筛选的候选数据范围，被限制在已经设置了过期时间的键值对上。即使缓存没有写满，这些数据如果过期了，也会被删除。

• volatile-ttl：针对设置了过期时间的键值对，根据过期时间的先后进行删除，越早过期的越先被删除。
• volatile-random：在设置了过期时间的键值对中，进行随机删除。
• volatile-lru： 使用 LRU 算法筛选设置了过期时间的键值对。
• volatile-lfu： 使用 LFU 算法选择设置了过期时间的键值对。

allkeys-lru、allkeys-random、allkeys-lfu 这三种淘汰策略的备选淘汰数据范围，就扩大到了所有键值对，无论这些键值对是否设置了过期时间。它们筛选数据进行淘汰的规则是：

• allkeys-random：从所有键值对中随机选择并删除数据。
• allkeys-lru：使用 LRU 算法在所有数据中进行筛选。
• allkeys-lfu：使用 LFU 算法在所有数据中进行筛选。

如果一个键值对被删除策略选中了，即使它的过期时间还没到，也需要被删除。当然，如果它的过期时间到了但未被策略选中，同样也会被删除。

LRU 算法

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

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

LRU 算法在实际实现时，需要用链表管理所有的缓存数据，这会带来额外的空间开销。而且，当有数据被访问时，需要在链表上把该数据移动到 MRU 端，如果有大量数据被访问，就会带来很多链表移动操作，会很耗时，进而会降低 Redis 缓存性能。

Redis 对 LRU 算法被做了简化，以减轻数据淘汰对缓存性能的影响。 Redis 默认会记录每个数据的最近一次访问的时间戳（由键值对数据结构 RedisObject 中的 lru 字段记录）。然后，Redis 在决定淘汰的数据时，第一次会随机选出 N 个数据，把它们作为一个候选集合。接下来，Redis 会比较这 N 个数据的 lru 字段，把 lru 字段值最小的数据从缓存中淘汰出去。

Redis 提供了一个配置参数 maxmemory-samples，指的就是 Redis 选出的数据个数 N。

CONFIG SET maxmemory-samples 100

关于 RedisObject 的结构推荐查看博客 Redis源码剖析和注释（八）— 对象系统(redisObject)。

当需要再次淘汰数据时，Redis 需要挑选数据进入第一次淘汰时创建的候选集合。挑选标准是：能进入候选集合的数据的 lru 字段值必须小于候选集合中最小的 lru 值。当有新数据进入候选数据集后，如果候选数据集中的数据个数达到了 maxmemory-samples，Redis 就把候选数据集中 lru 字段值最小的数据淘汰出去。

Redis 缓存不用为所有的数据维护一个大链表，也不用在每次数据访问时都移动链表项，提升了缓存的性能。

在实际运行时，每次往候选集中插入的数据可能不止一个，而在淘汰数据时，也是会根据使用内存量超过 maxmemory 的情况，来决定要淘汰的数据量，所以可能也不止一个数据被淘汰。候选集的作用是先把符合条件（lru 值小）的数据准备好。候选集本身是会按照 lru 值大小排序，等待要淘汰时，会根据要淘汰的量，从候选集中淘汰数据。所以，并不是刚进入候选集就立马被淘汰。准备候选集和淘汰数据实际是两个解耦的逻辑操作。

第一次被选中进入淘汰候选集的数据可能不会被淘汰。第一次进入候选集合的数据是随机选取的，数据的 lru 值可能大可能小。第二次及后续再进入候选集的数据的 lru 值需要小于候选集中的最小 lru 值。同时，候选集的实现是一个链表，数据是按照 lru 值排序的，链表头是 lru 值最大的，链表尾是 lru 值最小的。当第二次及后续进入候选集的数据 lru 更小，但是候选集中已经没有空位置时，候选集链表头的数据会被移出候选集，把位置空出来，给新进入的数据，而这个被移出的数据就不会作为被淘汰的候选数据了。

缓存淘汰策略使用建议：

• 优先使用 allkeys-lru 策略。这样，可以充分利用 LRU 这一经典缓存算法的优势，把最近最常访问的数据留在缓存中，提升应用的访问性能。如果业务数据中有明显的冷热数据区分，建议使用 allkeys-lru 策略。
• 如果业务应用中的数据访问频率相差不大，没有明显的冷热数据区分，建议使用 allkeys-random 策略，随机选择淘汰的数据就行。
• 如果业务中有置顶的需求，比如置顶新闻、置顶视频，那么，可以使用 volatile-lru 策略，同时不给这些置顶数据设置过期时间。这样一来，这些需要置顶的数据一直不会被删除，而其他数据会在过期时根据 LRU 规则进行筛选。

如何处理被淘汰的数据？

一般来说，一旦被淘汰的数据选定后，如果这个数据是干净数据，就直接删除；如果这个数据是脏数据，就需要把它写回数据库，如下图所示：

干净数据和脏数据的区别就在于，和最初从后端数据库里读取时的值相比，有没有被修改过。
干净数据一直没有被修改，所以后端数据库里的数据也是最新值。在替换时，它可以被直接删除。而脏数据就是被修改过了，已经和后端数据库中保存的数据不一致。此时，如果不把脏数据写回到数据库中，这个数据的最新值就丢失了，影响应用的正常使用。

对于 Redis 来说，它决定了被淘汰的数据后，会把它们删除。即使淘汰的数据是脏数据，Redis 也不会把它们写回数据库。所以，在使用 Redis 缓存时，如果数据被修改了，需要在数据修改时就将它写回数据库。否则，这个脏数据被淘汰时，会被 Redis 删除，而数据库里也没有最新的数据。（针对同步直写策略，而异步写回策略是等到数据从缓存中淘汰时，再写回数据库）