Redis：Redis键值淘汰策略

文章目录

键值淘汰策略
- 使用 maxmemory 配置指令
- 为复制或持久化实例设置 maxmemory
- 淘汰策略
- 使用 INFO 命令
- 近似 LRU 算法
- LFU 淘汰

键值淘汰策略

Redis 常被用作缓存，以加速对较慢服务器或数据库的读取访问。由于缓存条目是持久存储数据的副本，当缓存内存不足时，淘汰它们通常是安全的（必要时将来可以再次缓存）。

Redis 允许你指定一个淘汰策略，当缓存大小超过设定的内存限制时自动淘汰键。每当客户端运行一个向缓存添加更多数据的新命令时，Redis 会检查内存使用情况。如果超过限制，Redis 会根据选择的淘汰策略淘汰键，直到总内存使用量回到限制以下。

注意，当一个命令向缓存添加大量数据（例如，将一个大集合的交集存储到一个新键中）时，内存可能会暂时大幅度超过限制。

下面的部分解释了如何为缓存配置内存限制，也描述了可用的淘汰策略以及何时使用它们。

使用 maxmemory 配置指令

maxmemory配置指令指定用于缓存数据的最大内存量。你可以在启动时通过redis.conf文件设置maxmemory。例如，要配置 100 兆字节的内存限制，你可以在redis.conf中使用以下指令：

maxmemory 100mb

你也可以使用CONFIG SET在运行时通过redis-cli设置maxmemory：

> CONFIG SET maxmemory 100mb

将maxmemory设置为零表示你不想限制数据集的内存。这是 64 位系统的默认行为，而 32 位系统使用 3GB 的隐式内存限制。当缓存大小超过maxmemory设置的限制时，Redis 将强制执行你选择的淘汰策略，以防止缓存进一步增长。

为复制或持久化实例设置 maxmemory

如果你正在为服务器使用复制或持久化，Redis 会使用一部分 RAM 作为缓冲区，用于存储等待写入副本或 AOF 文件的更新集。此缓冲区使用的内存不包括在用于判断是否需要淘汰的总内存中。

这是因为淘汰键本身也会生成必须添加到缓冲区的更新。如果更新被计入已用内存，那么在某些情况下，通过淘汰键节省的内存会立即被添加到缓冲区的更新数据消耗掉。这反过来会触发更多的淘汰，产生的反馈循环可能会不必要地从缓存中淘汰许多项目。

如果你正在使用复制或持久化，我们建议你设置maxmemory以留出一点空闲 RAM 来存储缓冲区。注意，对于noeviction策略，这并非必要（有关淘汰策略的更多信息，请参阅下面的部分）。

INFO命令在内存部分返回一个mem_not_counted_for_evict值（你可以使用INFO memory选项仅查看此部分）。这是缓冲区当前使用的内存量。虽然确切数量会有所不同，但你可以使用它来估计在设置maxmemory之前要从总可用 RAM 中减去多少。

下面的示意图展示了在使用复制或 AOF 时，Redis 内存的划分情况，其中“复制缓冲区”不计入maxmemory限制：

淘汰策略

使用maxmemory-policy配置指令来选择当达到maxmemory设置的限制时你想要使用的淘汰策略。以下策略可用：

noeviction：不淘汰键，但当你尝试执行缓存新数据的命令时，服务器将返回错误。如果你的数据库使用复制，则此条件仅适用于主数据库。注意，仅读取现有数据的命令仍然正常工作。
allkeys-lru：淘汰最近最少使用 (LRU) 的键。
allkeys-lfu：淘汰最不经常使用 (LFU) 的键。
allkeys-random：随机淘汰键。
volatile-lru：淘汰设置了过期字段为 true 的键中最近最少使用的键。
volatile-lfu：淘汰设置了过期字段为 true 的键中最不经常使用的键。
volatile-random：仅在键设置了过期字段为 true 时随机淘汰键。
volatile-ttl：淘汰设置了过期字段为 true 且剩余生存时间 (TTL) 值最短的键。

你应该选择一种适合你的应用程序访问键的方式的淘汰策略：

当你期望有一部分元素的访问频率远高于其他元素时，使用allkeys-lru。
根据帕累托原则，这是一个非常常见的情况，所以如果你没有理由更喜欢其他策略，allkeys-lru是一个很好的默认选项。
当你期望所有键的访问频率大致相等时，使用allkeys-random。
例如，当你的应用程序以重复循环的方式读取数据项时。
如果你的代码可以估算哪些键是淘汰的良好候选者并给它们分配较短的 TTL，请使用volatile-ttl。
另请注意，如果你充分利用了键过期，那么你不太可能遇到缓存内存限制，因为键通常会在需要淘汰之前就过期了。
volatile-lru和volatile-random策略主要在你想使用单个 Redis 实例进行缓存和存储一组持久键时有用。
但是，如果可能的话，你应该考虑在这种情况下运行两个独立的 Redis 实例。

另外请注意，为键设置过期值会消耗内存，所以像allkeys-lru这样的策略更节省内存，因为它不需要过期值就能运行。

使用 INFO 命令

INFO命令提供了一些有用的数据来检查缓存的性能。特别是，INFO stats部分包括两个重要的条目，keyspace_hits（在缓存中成功找到键的次数）和keyspace_misses（请求了一个键但不在缓存中的次数）。下面的计算给出了从缓存满足的尝试访问的百分比：

keyspace_hits / (keyspace_hits + keyspace_misses) * 100

检查这是否大致符合你对你应用程序的预期（自然，百分比越高表示缓存性能越好）。

注意：
当EXISTS命令报告键不存在时，这被计为键空间未命中。

如果命中率低于预期，这可能意味着你没有使用最佳的淘汰策略。例如，如果你相信一小部分“热”数据（可以轻松放入缓存）应该占大约 75% 的访问，你可以合理地预期键空间命中百分比在 75% 左右。如果实际百分比较低，请检查evicted_keys的值（也由INFO stats返回）。高比例的淘汰表明你选择的策略过于频繁地淘汰了错误的键（所以allkeys-lru可能是一个不错的选择）。如果evicted_keys的值很低并且你正在使用键过期，请检查expired_keys以查看有多少键已过期。如果这个数字很高，你可能使用的 TTL 太低，或者你选择了错误的键进行过期，这导致键在应该保留之前就从缓存中消失了。
INFO返回的其他有用信息包括：

used_memory_dataset：（内存部分）用于缓存数据的内存量。如果这大于maxmemory，那么差值就是maxmemory被超出的量。
current_eviction_exceeded_time：（统计部分）自缓存上次开始超过maxmemory以来的时间。
commandstats 部分：除其他事项外，这报告了向服务器发出的每个命令被拒绝的次数。如果你正在使用noeviction或volatile_xxx策略之一，你可以使用它来查找哪些命令被maxmemory限制阻止，以及这种情况发生的频率。

近似 LRU 算法

Redis LRU 算法使用最近最少使用的键的近似值，而不是精确计算它们。它随机抽取少量的键，然后淘汰自上次访问以来时间最长的键。

从 Redis 3.0 开始，该算法还跟踪一个良好的淘汰候选池。这提高了算法的性能，使其成为真正的 LRU 算法的接近近似值。

你可以通过maxmemory-samples配置指令更改每次淘汰前要检查的样本数来调整算法的性能：

maxmemory-samples 5

Redis 不使用真正的 LRU 实现是因为它消耗更多的内存。然而，对于使用 Redis 的应用程序来说，该近似值实际上等同于真正的 LRU。该图比较了 Redis 使用的 LRU 近似值与真正的 LRU。下面的示意图展示了 Redis LRU 算法如何通过随机采样来寻找淘汰目标，而不是遍历所有键：