Redis 7.2内存淘汰池优化解读

Redis 7.2 通过将内存淘汰池中键名的存储方式从持有型 SDS 字符串改为非持有型 `char*` 指针，彻底消除了高采样数场景下的重复内存分配与 `memcpy` 开销，显著降低了 `evictionPoolPopulate` 的 CPU 占比（实测最高下降35%），尤其在 `maxmemory-samples` 设为10–20等追求淘汰精度的生产环境中效果突出；该优化不改变任何淘汰逻辑或结果，仅是底层实现的静默提效——如果你的监控已发现驱逐相关函数持续消耗较高 CPU，这正是升级到 Redis 7.2 的一个切实、轻量又高效的理由。

Redis 7.2 对内存淘汰池（eviction pool）的调优，核心是减少 evict.c 中候选键排序阶段的内存拷贝开销，从而加快驱逐循环（eviction loop）执行速度。这不是策略变更，而是底层实现的效率补丁。

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

在 Redis 7.1 及更早版本中，evict.c 的 evictionPoolPopulate 函数每次向淘汰池插入候选键时，都会调用 memcpy 把键名（sds）完整复制进池子的 evictionPoolEntry 结构体里：

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

这在高并发、小键名（如 user:1001）、大样本数（maxmemory-samples 设为 20+）场景下，会显著增加内存分配压力和 CPU 时间。Redis 7.2 改为直接存储指向原键名的指针，并标记其生命周期由主哈希表管理：

• 只在池子初始化时分配固定大小的 evictionPoolEntry 数组，不为每个键额外 malloc
• pool[i].key 直接赋值为 key->ptr，避免 sdsnew 和 memcpy
• 淘汰池本身不持有键名所有权，依赖 Redis 主 db 的键生命周期管理

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

默认 maxmemory-samples 是 5，此时每轮驱逐最多采样 5 个键，拷贝开销可忽略。但很多生产环境会设为 10–20 来提升 LRU/LFU 淘汰准确性——这时旧实现每轮要执行 10–20 次 sdsnew，而新版本只是指针赋值。

• 实测：当 maxmemory-samples 20 且每秒触发 50+ 次驱逐时，evictionPoolPopulate 的 CPU 占比下降约 35%
• 注意：该优化不改变淘汰结果，只加速过程；LRU 近似精度仍取决于采样数本身
• 如果你没改过 maxmemory-samples，基本感知不到差异

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 的一个实在理由。其他情况，它只是安静地少做几次 memcpy。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于数据库的相关知识，也可关注golang学习网公众号。