RDB快照推高used_memory_peak_human源于fork后COW机制：主线程写入触发内存页复制，导致虚拟内存映射膨胀；应禁用自动save（设save ""），改用低峰期手动BGSAVE调度。

为什么RDB快照会推高used_memory_peak_human？

RDB本身不直接“占用更多内存”，但fork子进程后，Redis主线程持续写入会触发Copy-On-Write（COW）机制：每次修改被快照引用的内存页，内核就得复制一份物理页。如果快照期间有大量写操作（比如批量更新、过期键集中清理、哈希表rehash），就会在短时间内生成大量副本页，导致used_memory_peak_human飙升——这其实是虚拟内存映射膨胀，不是数据本身变大。

禁用自动save + 用BGSAVE手动调度是唯一可控路径

自动save配置（如save 60 10000）靠写操作触发，根本不可控；你无法预知哪次SET或HSET会成为压垮骆驼的最后一根稻草。真正能限制峰值的方式，是把触发权完全收回来：

• 在redis.conf中明确设为save ""（空字符串），而不是注释掉——否则默认规则仍生效
• 用cron在业务低峰（如凌晨2:30）调用redis-cli BGSAVE，确保此时instantaneous_ops_per_sec
• 若主节点必须承担快照，先执行redis-cli info memory | grep used_memory_peak_human确认当前峰值未逼近物理内存上限

从节点做RDB比主节点更安全

主节点响应延迟敏感，而从节点通常只读，写压力归零，COW开销自然大幅降低。但要注意几个硬性前提：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 从节点不能配置slave-read-only no，否则可能被误写，污染dump.rdb
• 确保repl-backlog-size足够大，避免主从断连后全量同步又触发一次意外fork
• 从节点RDB文件路径应与主节点隔离（改dbfilename和dir），避免覆盖或权限冲突

rdbcompression和rdbchecksum不是可选开关，而是CPU放大器

这两个配置默认开启，但它们在fork后的子进程中执行，会延长快照时间窗口，间接拉长COW敏感期：

• rdbcompression yes → 启用LZF压缩，CPU占用翻倍，尤其对小key-value效果微弱
• rdbchecksum yes → 每个RDB文件末尾加8字节CRC校验，看似安全，实则强制子进程多跑一轮遍历
• 生产环境建议统一关掉：config set rdbcompression no、config set rdbchecksum no，再BGSAVE

真正难的是判断“低峰”是否真的低峰——监控cmdstat_set和evicted_keys趋势比看时间更可靠；而used_memory_peak_human一旦接近maxmemory的90%，哪怕在凌晨三点，也该跳过本次快照。