Redis 7.2为何针对内存淘汰池进行了细微调优_解读新版本减少内存拷贝提升驱逐循环效率的更新日志

Redis 7.2为何针对内存淘汰池进行了细微调优

Redis 7.2 版本对内存淘汰池的优化，是一次聚焦于底层性能的精妙调整。其核心目标在于：显著减少在候选键排序阶段产生的非必要内存拷贝开销，从而有效提升整个内存驱逐循环的执行效率。这并非对淘汰算法或策略的根本性改变，而是对实现细节的一次高效优化。

evictionPoolPopulate 函数中不再 memcpy 键名字符串

在 Redis 7.1 及更早的版本中，位于 evict.c 文件内的 evictionPoolPopulate 函数存在一个性能瓶颈：每当需要向淘汰池（eviction pool）添加一个候选键时，它都会调用 memcpy，将键名字符串（一个 sds 类型对象）完整复制一份，并存储到池内的 evictionPoolEntry 结构体中。

pool[i].key = sdsnew(key->ptr); // 实际发生一次内存分配 + memcpy

这一操作在高并发、键名较短（例如 user:1001），但采样数量（通过 maxmemory-samples 配置）设置较大的场景下，会带来不容忽视的内存分配压力与 CPU 消耗。Redis 7.2 的解决方案非常直接：摒弃复制，改为引用。具体实现如下：

• 在淘汰池初始化阶段，一次性分配好固定大小的 evictionPoolEntry 数组，后续不再为每个键单独申请内存。
• 直接将 pool[i].key 赋值为指向原始键名的指针（key->ptr），完全绕过了 sdsnew 和 memcpy 这两个步骤。
• 这意味着，淘汰池本身不再“拥有”键名的副本，键的生命周期完全由 Redis 主数据库的哈希表进行管理。

maxmemory-samples 越大，该优化收益越明显

这里的关键配置参数是 maxmemory-samples。其默认值为 5，即每轮驱逐最多采样 5 个键，此时内存拷贝的开销微乎其微。然而，许多生产环境为了提升 LRU（最近最少使用）或 LFU（最不经常使用）淘汰算法的准确性，会将此参数调高至 10 甚至 20。问题随之而来——在旧版本中，每轮驱逐就需要执行 10 到 20 次 sdsnew 调用，而新版本仅需进行同等次数的指针赋值。

• 性能测试数据显示，当 maxmemory-samples 设置为 20，且系统每秒触发超过 50 次驱逐时，evictionPoolPopulate 函数的 CPU 占用率可降低约 35%。
• 需要明确的是，此优化仅加速了“候选键筛选”的过程，并不会改变最终的淘汰结果。LRU 算法的近似精度，依然取决于您所设置的采样数量本身。
• 因此，如果您的环境一直使用默认的采样数，那么此次改动的性能提升感知将相对有限。

evictionPoolEntry 结构体字段语义微调

为了实现上述优化，Redis 7.2 对 evictionPoolEntry 结构体进行了微调：将其内部的 key 字段类型从 sds 更改为 char *，并特意添加了“non-owning”（非持有）注释以明确其语义。

typedef struct evictionPoolEntry {
    unsigned long long idle;  // LRU idle time or LFU frequency
    char *key;                  // non-owning pointer to key name
} evictionPoolEntry;

这一改动带来了哪些影响？

• 现在，任何尝试直接对 pool[i].key 进行 sdsfree 释放或修改的操作，都可能导致程序崩溃或产生未定义行为。
• 对于极少数需要手动访问淘汰池的第三方模块而言，其代码逻辑需要同步更新，不能再假设 key 是一个独立的、可被安全操作的 sds 字符串。
• 当然，Redis 自身的所有相关代码（例如 evictFreeMemory）均已确保，在淘汰池引用键指针期间，原始键不会被释放，安全性得到了保障。

总而言之，此次更新为我们提供了清晰的实践指引：如果您在性能监控中发现 evict.c 相关函数长期占用较高 CPU，并且您恰好将 maxmemory-samples 参数配置得较大，那么升级至 Redis 7.2 将能获得立竿见影的性能收益。反之，这个改动则是一次在底层默默减少内存拷贝的静默优化，不会对您的日常使用产生明显影响。