根本原因是cow导致rss内存暴涨触碰maxmemory上限而被迫淘汰；bgsave时fork子进程触发copy-on-write，父进程修改内存页即复制物理页，临近maxmemory时瞬时内存增长直接触发淘汰。
Redis 在 bgsave 期间触发大量 evicted_keys，根本原因不是淘汰策略本身有问题，而是 COW 导致 RSS 内存暴涨，触碰 maxmemory 上限后被迫淘汰——这不是“该不该淘汰”，而是“内存被 COW 吃光了”。
为什么 bgsave 会突然拉高淘汰数？
执行 bgsave 时，Redis fork 出子进程，内核启用 Copy-On-Write。父进程每修改一个内存页，就复制一页物理内存。若此时内存已接近 maxmemory，COW 引发的瞬时内存增长会直接越过阈值，触发淘汰逻辑（尤其是 volatile-lru 或 allkeys-lru 等策略）。
常见诱因包括：
- 高频小 key 更新（如计数器
INCR）——看似轻量，但每个修改都可能触发一页复制 - 大 value 的部分写（如对 10MB 的
HASH执行单个HSET）——只改一个字段，却复制整页 -
DEL+SET替换大 key ——旧对象未立即释放（lazyfree 未完成），新对象又占内存，COW 雪上加霜
如何用 INFO memory 和 /proc/<pid>/statm</pid> 实时判断 COW 压力？
别看 top 或 ps 的 RSS：它们显示父子进程总和，无法分离 COW 开销。真正关键的是：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先获取主进程 PID：
redis-cli INFO server | grep process_id - 查
/proc/<pid>/statm</pid>第六列（WriteCopy），单位是内存页数 - 乘以
getconf PAGESIZE（通常为 4096）得字节数 - 若该值在几秒内从 0 跳到 >500MB，说明正在密集复制脏页——此时
evicted_keys必然飙升
同时观察 INFO stats 中的 evicted_keys 和 expired_keys：若二者在 bgsave 开始后突增，基本可确认是 COW 挤占内存所致。
保留多少内存冗余才够安全？
没有固定百分比，取决于你的写负载特征和实例大小。实测经验：
- 64GB 实例，写入压力中等（QPS ~2k），建议预留 ≥15%（即至少 9.6GB）不计入
maxmemory - 若存在大量 >1MB 的 hash/list/set，或频繁
HSET/HMSET，冗余需提高至 20–25% - 用
MEMORY USAGE <key></key>定期扫描，识别“逻辑已删、物理未释放”的大 key，它们会持续占用冗余空间 - 启用
active-defrag可缓解碎片导致的虚假内存紧张，但不能替代真实冗余
为什么 noeviction 不是万能解？
设 maxmemory-policy noeviction 确实能阻止淘汰，但代价是：一旦 COW + 当前写入突破 maxmemory，后续写命令直接返回 (error) OOM command not allowed when used memory > 'maxmemory'.。业务是否能容忍这种硬失败，比“丢几个 key”更难评估。更务实的做法是：保留冗余 + 控制写行为 + 拆分实例，三者配合，而非依赖单一策略。
COW 的本质是时间换空间，而 Redis 生产环境最缺的往往既不是时间，也不是空间，是确定性——那些在 bgsave 秒级窗口里突然翻倍的内存页，才是真正咬人的地方。
