redis启动时只要dir目录下存在dump.rdb（或自定义dbfilename），无论save配置是否为空（如save ""），都会自动加载该文件恢复数据；save ""仅禁用自动快照触发，不阻止rdb文件加载。

能彻底关，但必须同步清理配置、运行时状态和磁盘文件三者，缺一不可；只改 redis.conf 或只执行 CONFIG SET 都会失效。

为什么 save "" 之后 dump.rdb 还会被加载

Redis 启动时的 RDB 加载逻辑是：只要 dir 目录下存在 dump.rdb（或你自定义的 dbfilename），不管 save 配置是否为空，它都会加载该文件并恢复数据——这不是 bug，是设计行为。

• save "" 只禁用自动触发快照，不影响已有 .rdb 文件的加载
• 必须手动删除：redis-cli CONFIG GET dir 查出路径，再 rm /path/to/dump.rdb
• 如果之前启用了 stop-writes-on-bgsave-error yes 且历史 SAVE 失败过，redis-cli ping 可能返回 (error) MISCONF Redis is configured to save RDB snapshots，此时需先 CONFIG SET stop-writes-on-bgsave-error no

为什么 appendonly no 后 AOF 文件仍被重启用

Redis 启动时检查 appendfilename 指向的文件是否存在；只要该文件存在，哪怕配置是 appendonly no，也会强制加载并自动把 appendonly 切成 yes——官方称之为 “AOF auto-reload on startup”。

Redis Skill - 高性能缓存管理

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

下载

• 关闭 AOF 必须三步同步：CONFIG SET appendonly no → 删除磁盘上对应文件（如 appendonly.aof）→ 修改 redis.conf 中 appendonly yes 为 no
• CONFIG REWRITE 不会删文件，也不会清空已存在的 AOF 文件内容
• 容器部署时，挂载卷里残留的旧 appendonly.aof 是最常被忽略的隐性恢复点

纯缓存场景下淘汰策略怎么配才不踩坑

关闭持久化后，maxmemory 和 maxmemory-policy 就成了唯一的数据兜底机制；不配或配错会导致 OOM 或写入失败。

• 必须显式设置 maxmemory，否则 Redis 会无限制吃内存，最终触发系统 OOM killer
• 缓存场景首选 allkeys-lru 或 allkeys-lfu；避免用 noeviction（写操作直接报错）或 volatile-* 系列（要求所有 key 都设 TTL，运维成本高）
• 验证是否生效：写入大量 key 后观察 INFO memory 中 used_memory_human 是否趋近 maxmemory，再看 INFO stats 中 evicted_keys 是否持续增长

真正麻烦的不是配置项本身，而是 Redis 对“残留文件”的强依赖——它不关心你写了什么配置，只认磁盘上有没有那个文件。生产环境每次调整前，务必确认 dir 下既无 dump.rdb，也无 appendonly.aof（或你自定义的文件名）。