彻底禁用 RDB 自动触发需注释或设为 save ""，重启或 CONFIG REWRITE 后 CONFIG GET save 返回 ["save", ""]，且 rdb_changes_since_last_save 持续增长即生效。
如何彻底禁用 RDB 自动触发（save 规则）
直接注释掉所有 save 行，或设为 save ""，就能让 Redis 完全不因时间/写入量自动执行 BGSAVE。这不是“关闭功能”，而是清空触发条件列表——Redis 启动后会读取配置，发现没有一条 save 规则，就跳过所有自动快照逻辑。
-
save 900 1、save 300 10这类行必须全部删除或注释（# 开头），只留save ""也有效 - 改完配置后必须重启 Redis 或执行
CONFIG REWRITE（仅当启用了CONFIG SET写入配置文件权限时才生效） - 验证是否生效：执行
CONFIG GET save，返回结果应为["save", ""]；再查INFO persistence中的rdb_last_bgsave_status应长期为ok（没被触发过）或no（从未成功），但关键是rdb_changes_since_last_save会持续增长，说明无人干预
手动触发备份时，SAVE 和 BGSAVE 到底怎么选
SAVE 在生产环境必须禁用——它会阻塞整个 Redis 实例，期间所有读写请求排队等待，超时、报错、雪崩都可能发生。而 BGSAVE 是唯一安全的手动触发方式，它靠 fork() 子进程完成序列化，主进程照常服务。
- 线上严禁执行
SAVE；若配置中还存在该命令调用（比如脚本里硬编码了），立刻替换成BGSAVE -
BGSAVE不是“绝对无感”：fork()瞬间会短暂阻塞主线程（毫秒级），内存越大、页表越复杂，阻塞越明显；若 Redis 占用 20GB 内存，fork可能卡住 5–20ms - 连续多次调用
BGSAVE无效：第二次发起时，若前一个子进程还在跑，Redis 直接返回Background save already in progress，不会排队
为什么 SHUTDOWN 会让“刚备份的数据消失”
很多人以为 SHUTDOWN 是“优雅关机+加载上次快照”，其实它会在退出前强制执行一次 BGSAVE（除非显式加 NOSAVE 参数）。如果此时数据已被 FLUSHALL 清空，那这次强制快照就是空的——直接覆盖掉你之前存好的 dump.rdb。
- 正确做法：
SHUTDOWN NOSAVE跳过最后保存；或先CONFIG SET save ""临时禁用自动规则，再SHUTDOWN - 想保留某次快照用于恢复？别依赖
dump.rdb文件名，立刻cp dump.rdb dump_$(date +%s).rdb备份，否则下次BGSAVE或SHUTDOWN就可能把它盖掉 - Redis 启动时只加载当前
dir下的dbfilename文件（默认dump.rdb），它不识别历史备份，也不会“智能选最新有效快照”
禁用 RDB 后，真的就一劳永逸了吗
禁用 save 规则 ≠ 关闭所有持久化行为。Redis 仍可能在某些场景下意外写入 RDB 文件，比如主从复制中从节点首次同步时生成快照、或 AOF 重写期间启用 appendfsync always 且配置了 auto-aof-rewrite-percentage，都可能间接触发 BGSAVE。
- 确认完全无 RDB 写入：监控
INFO persistence中的rdb_last_bgsave_time是否长期不变，rdb_last_bgsave_status是否始终为ok（说明没失败）但rdb_changes_since_last_save持续上涨（说明真没被触发） - 如果只用 Redis 做纯缓存，建议同时关闭 AOF（
appendonly no），并确保stop-writes-on-bgsave-error设为no，避免某次失败的后台保存意外中断写入 - 最保险的“零持久化”组合：
save ""+appendonly no+stop-writes-on-bgsave-error no，但请清楚承担断电即丢数据的风险
Redis 的 RDB 配置看着简单，真正踩坑都在“以为关掉了，其实没关干净”和“以为保存了，其实被覆盖了”这两处。尤其是 SHUTDOWN 的隐式快照行为，几乎每个团队都至少翻过一次车。
