禁用 RDB 的正确方式是配置 save ""，而非删除或注释；禁用 AOF 需同步执行三步：配置 appendonly no、删除对应 AOF 文件、运行时执行 CONFIG SET appendonly no；关闭所有持久化后数据仅存内存，进程退出或断电即丢失。
Redis 禁用 RDB 的正确配置方式
直接改 save 配置项为无值，不是删掉它，更不是注释掉——否则 Redis 启动时会加载默认策略（如 save 900 1），导致 RDB 意外触发。
必须在 redis.conf 中显式清空所有 save 行：
save ""
这是唯一被 Redis 识别为“禁用 RDB”的写法。其他常见错误包括：
- 留着
# save 900 1注释 —— Redis 仍按默认策略执行 - 写成
save 0 0或save ""加了空格 —— 启动报错Invalid argument - 只改了
dbfilename却没动save—— 文件名再怎么改，快照照样生成
彻底关闭 AOF 的三步操作
AOF 不像 RDB 那样只靠一个配置项就能关掉；它有运行时状态、配置开关、以及残留文件三个层面需要同步处理。
缺一不可的操作顺序是：
- 设置
appendonly no（配置文件中） - 确保
appendfilename对应的文件（如appendonly.aof）不存在，或已手动删除 - 如果 Redis 正在运行且 AOF 已开启，先执行
CONFIG SET appendonly no，再确认CONFIG GET appendonly返回"no"
漏掉第二步会导致重启后 Redis 自动加载残留的 appendonly.aof 文件并重新启用 AOF；漏掉第三步则可能因配置未热生效，AOF 继续写入。
为什么不能只关配置、不删文件？
Redis 启动逻辑是：先读配置，再检查磁盘上是否存在 appendfilename 指定的 AOF 文件。只要该文件存在，即使 appendonly 是 no，Redis 也会强制加载它，并自动把 appendonly 切成 yes。
这个行为在官方文档里叫 “AOF auto-reload on startup”，不是 bug，是设计如此。所以：
- 生产环境每次禁用 AOF 前，必须确认
dir目录下没有appendonly.aof（或你自定义的appendfilename） -
CONFIG REWRITE不会自动清理已存在的 AOF 文件，它只重写配置文件 - 容器化部署时，注意挂载卷里是否残留旧 AOF 文件 —— 这是最容易被忽略的隐性恢复点
禁用持久化后的内存与崩溃风险提醒
关掉 RDB 和 AOF 后，Redis 变成纯内存服务：所有数据仅存于 RAM，进程退出即丢失，机器断电等于全量清零。
这不是性能优化的终点，而是取舍的起点。你需要确认：
- 业务能接受缓存击穿后重建延迟（比如 DB 查询 + 写回缓存耗时 200ms）
- 没有依赖 Redis 做轻量级消息队列或任务暂存（因为
LPUSH+BRPOP数据也会消失） - 集群模式下，主从复制仍在工作，但故障转移后新主节点仍是空的 —— 除非你配了
replica-serve-stale-data yes并接受脏读
真正难的不是怎么关，而是关完之后，谁来兜底那部分“本该由持久化扛住”的数据可靠性问题。
