redis key删除策略

 复制粘贴

Key eviction | Redis

 
Redis 键驱逐策略（LRU、LFU 等）概述

当 Redis 用作缓存时，让它在您添加新数据时自动驱逐旧数据通常很方便。 此行为在开发人员社区中众所周知，因为它是流行的 memcached 系统的默认行为。

本页涵盖了用于将内存使用量限制为固定数量的 Redis maxmemory 指令的更一般主题。 它还广泛涵盖了 Redis 使用的 LRU 逐出算法，它实际上是精确 LRU 的近似值。

最大内存配置指令
maxmemory 配置指令将 Redis 配置为对数据集使用指定数量的内存。 您可以使用 redis.conf 文件设置配置指令，或者稍后在运行时使用 CONFIG SET 命令。

例如，要配置 100 兆字节的内存限制，您可以在 redis.conf 文件中使用以下指令：

最大内存 100mb
将 maxmemory 设置为零会导致没有内存限制。 这是 64 位系统的默认行为，而 32 位系统使用 3GB 的隐式内存限制。

当达到指定的内存量时，逐出策略的配置方式决定了默认行为。 Redis 可以为可能导致使用更多内存的命令返回错误，或者它可以逐出一些旧数据以在每次添加新数据时返回到指定的限制。

驱逐政策
当达到最大内存限制时，Redis 遵循的确切行为是使用 maxmemory-policy 配置指令配置的。

可以使用以下策略：

noeviction：达到内存限制时不保存新值。 当数据库使用复制时，这适用于主数据库
allkeys-lru：保留最近使用的密钥； 删除最近最少使用 (LRU) 键
allkeys-lfu：保留常用键； 删除最不常用 (LFU) 键
volatile-lru：删除过期字段设置为 true 的最近最少使用的密钥。
volatile-lfu：删除过期字段设置为 true 的最不常用的键。
allkeys-random：随机删除键以为添加的新数据腾出空间。
volatile-random：随机删除 expire 字段设置为 true 的密钥。
volatile-ttl：删除过期字段设置为 true 且剩余生存时间 (TTL) 值最短的密钥。
如果没有与先决条件相匹配的逐出键，策略 volatile-lru、volatile-lfu、volatile-random 和 volatile-ttl 的行为类似于 noeviction。

根据应用程序的访问模式选择正确的逐出策略很重要，但是您可以在应用程序运行时在运行时重新配置策略，并使用 Redis INFO 输出监控缓存未命中和命中的次数以调整您的设置。

一般来说，根据经验：

当您希望请求的受欢迎程度呈幂律分布时，请使用 allkeys-lru 策略。 也就是说，您期望元素的一个子集将比其余元素更频繁地被访问。 如果您不确定，这是一个不错的选择。

如果您有连续扫描所有密钥的循环访问，或者当您希望分布均匀时，请使用 allkeys-random。

如果您希望能够在创建缓存对象时通过使用不同的 TTL 值向 Redis 提供关于哪些内容适合过期的提示，请使用 volatile-ttl。

volatile-lru 和 volatile-random 策略主要在您希望使用单个实例进行缓存和拥有一组持久键时有用。 然而，运行两个 Redis 实例来解决这样的问题通常是更好的主意。

还值得注意的是，为键设置过期值会消耗内存，因此使用像 allkeys-lru 这样的策略可以提高内存效率，因为在内存压力下不需要对键进行过期配置。

逐出过程的工作原理

请务必了解逐出过程的工作方式如下：

• 客户端运行新命令，导致添加更多数据。
• Redis 检查内存使用情况，如果大于限制，它会根据策略逐出密钥。maxmemory
• 执行新命令，依此类推。

因此，我们不断跨越内存限制的边界，越过它，然后逐出密钥以返回到限制以下。

如果命令导致在一段时间内使用大量内存（如存储在新键中的大集合交集），则可能会明显超过内存限制。

近似 LRU 算法

Redis LRU 算法不是精确的实现。这意味着 Redis 是 无法选择驱逐的最佳候选人，即 过去最远的访问。相反，它将尝试运行一个近似值 的 LRU 算法，通过对少量密钥进行采样，并逐出 一个是采样密钥中最好的（具有最旧的访问时间）。

但是，自 Redis 3.0 以来，该算法得到了改进，也获得了良好的池子。 驱逐候选人。这提高了算法的性能，使 它能够更接近真实 LRU 算法的行为。

Redis LRU 算法的重要之处在于，您可以通过更改要检查每个逐出的样本数来调整算法的精度。此参数由以下配置指令控制：

maxmemory-samples 5

Redis 不使用真正的 LRU 实现的原因是因为它 花费更多内存。但是，对于 使用Redis的应用程序。这个数字比较 Redis 使用的真实 LRU 的 LRU 近似值。

生成上述图表的测试用给定数量的密钥填充了 Redis 服务器。密钥是从第一个到最后一个访问的。第一个密钥是使用 LRU 算法逐出的最佳候选项。后来添加了更多的 50% 的密钥，以强制驱逐一半的旧密钥。

您可以在图表中看到三种点，形成三个不同的条带。

• 浅灰色条带是被逐出的对象。
• 灰色条带是未被逐出的对象。
• 绿色条带是已添加的对象。

在理论上的 LRU 实现中，我们预计，在旧密钥中，前半部分将过期。Redis LRU 算法只会在概率上使旧密钥过期。

如您所见，与 Redis 3.0 相比，Redis 5.2 在处理 8 个样本时做得更好，但是 Redis 2.8 仍然保留了最新访问的大多数对象。在 Redis 10.3 中使用样本大小 0，近似值非常接近 Redis 3.0 的理论性能。

请注意，LRU 只是一个模型，用于预测将来访问给定密钥的可能性。此外，如果您的数据访问模式非常接近 类似于幂律，大多数访问将在键集中 LRU近似算法可以很好地处理。

在模拟中，我们发现使用幂律访问模式，真正的 LRU 和 Redis 近似之间的差异很小或不存在。

但是，您可以将样本大小提高到 10，但代价是一些额外的 CPU 用法接近真实 LRU，并检查这是否会产生 缓存未命中率的差异。

使用 命令非常简单。

CONFIG SET maxmemory-samples <count>

新的 LFU 模式

从 Redis 4.0 开始，可以使用最不常用的逐出模式。此模式可能会更好地工作（提供更好的 命中/未命中率）在某些情况下。在 LFU 模式下，Redis 将尝试跟踪 访问项目的频率，因此很少使用的项目被逐出。这意味着 使用的密钥通常更有可能保留在内存中。

要配置 LFU 模式，可以使用以下策略：

• volatile-lfu在设置了过期的密钥中使用近似的 LFU 逐出。
• allkeys-lfu使用近似 LFU 逐出任何密钥。

LFU的近似值类似于LRU：它使用一个概率计数器，称为莫里斯计数器，仅使用每个对象的几位来估计对象访问频率，并结合衰减周期，以便计数器随着时间的推移而减少。在某些时候，我们不再希望将密钥视为频繁访问，即使它们在过去也是如此，以便算法可以适应访问模式的变化。

该信息的采样类似于 LRU （如本文档上一节所述）选择逐出候选项的情况。

然而，与LRU不同的是，LFU具有某些可调参数：例如，速度 如果一个频繁的项目不再被访问，它的排名是否应该降低？还可以调整莫里斯计数器范围，以更好地使算法适应特定用例。

默认情况下，Redis 配置为：

• 使计数器饱和，大约一百万个请求。
• 每分钟衰减一次计数器。

这些应该是合理的值，并且经过实验测试，但用户可能希望使用这些配置设置来选择最佳值。

有关如何调整这些参数的说明可以在源代码分发的示例文件中找到。简而言之，它们是：redis.conf

lfu-log-factor 10
lfu-decay-time 1

衰减时间是显而易见的，它是计数器在采样并发现早于该值时应该衰减的分钟数。手段的特殊价值：我们永远不会腐烂计数器。0

计数器对数因子更改使频率计数器饱和所需的命中次数，该频率计数器仅在 0-255 范围内。系数越高，达到最大值所需的访问次数就越多。系数越低，低访问计数器的分辨率越好，如下表所示：

+--------+------------+------------+------------+------------+------------+
| factor | 100 hits   | 1000 hits  | 100K hits  | 1M hits    | 10M hits   |
+--------+------------+------------+------------+------------+------------+
| 0      | 104        | 255        | 255        | 255        | 255        |
+--------+------------+------------+------------+------------+------------+
| 1      | 18         | 49         | 255        | 255        | 255        |
+--------+------------+------------+------------+------------+------------+
| 10     | 10         | 18         | 142        | 255        | 255        |
+--------+------------+------------+------------+------------+------------+
| 100    | 8          | 11         | 49         | 143        | 255        |
+--------+------------+------------+------------+------------+------------+

因此，基本上，该因素是在更好地区分低访问的项目与区分具有高访问的项目之间进行权衡。示例文件中提供了更多信息。redis.conf