redis的save规则是“时间窗内写入量达标即触发”，非固定周期执行；默认save 900 1在高写入场景下易失效；多条规则为“或”关系，满足任一即触发rdb；配置需兼顾写入特征与fork开销。

save 规则不是时间间隔，而是“写入量 + 时间窗”的组合条件

很多人误以为 save 60 10000 是“每 60 秒执行一次”，其实它表达的是：**过去 60 秒内，至少有 10000 个 key 被修改过，才触发 RDB**。只要没达到这个写入量，哪怕等一小时也不会落盘。默认的 save 900 1（15 分钟 1 个变更）在高写入场景下基本形同虚设——业务每秒改几百个 key，但某次小批量操作只改了 1 个，就卡住不快照。

• 多个 save 规则是“或”关系，满足任一即触发，不是叠加生效
• 用 CONFIG GET save 查运行时配置，别只看 redis.conf，动态改过可能已失效
• 若业务写入平稳（如每秒 2k key 变更），配 save 30 5000 比 save 60 10000 更可靠
• 若存在明显波峰（如整点报表生成、秒杀后批量更新），加一条短周期规则，例如 save 5 1000 应对突发

RDB 频率过高会 fork 延迟，尤其内存 >4GB 且启用了 THP

每次 RDB 触发都要 fork() 子进程复制内存页表。如果实例内存超 4GB，又没关透明大页（THP），fork() 延迟可能飙到秒级，直接拖慢写入吞吐。这不是 Redis 本身慢，是内核层面的页表拷贝开销。

Redis Skill - 高性能缓存管理

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

下载

• 必须执行：echo never > /sys/kernel/mm/transparent_hugepage/enabled（重启后失效，建议写进 /etc/rc.local）
• save 配得太密（比如 save 10 100）会导致高频 fork，主线程抖动明显，监控里能看到 latency spikes
• 禁用所有自动 save（设为 save ""），改用外部调度 + INFO Persistence 检查 rdb_bgsave_in_progress:0 后再调 BGSAVE，更可控

混合持久化（aof-use-rdb-preamble）只在 AOF 文件 >500MB 时真有用

开启 aof-use-rdb-preamble yes 后，AOF 重写会先写一段 RDB 格式头部，再接增量命令。它不减小 AOF 体积，但能显著缩短启动加载时间——前提是 AOF 文件够大、命令历史够杂（比如大量 LPOP/HSET 交错）。

• 仅当 appendonly yes 且 AOF 文件常超 500MB 时启用；小实例（
• 重写期间内存临时增加约 1.2 倍（RDB 头 + AOF 增量缓冲），得预留足够余量
• Redis 7.0+ 默认开启，但老版本需手动配；升级后务必用 CONFIG GET aof-use-rdb-preamble 确认是否被覆盖

从 RDB 恢复前，必须验证文件完整性

RDB 文件写入未完成时，可能只落盘了前半部分，导致 redis-server 启动报 Wrong RDB header 或静默加载失败。不能只靠文件存在就认为可用。

• 检查文件末尾是否为 REDIS 魔数 + 有效校验和（可用 od -c dump.rdb | tail 快速扫一眼）
• 生产环境恢复前，先用 redis-check-rdb dump.rdb 校验，返回 OK 才可信
• 若用定时脚本备份，记得把 cp 换成 mv 原子替换，避免备份过程中读到截断文件

实际部署时，最易被忽略的是 THP 和 RDB 文件校验这两步——前者让快照变慢却不报错，后者让恢复变成“赌运气”。其他参数再怎么调，也绕不开这两个硬门槛。