绝大多数redis持久化配置修改后必须重启服务才能生效，包括save、appendonly、dir、dbfilename、appendfilename和appendfsync等核心参数；仅bgsave等命令可热执行，但不改变配置规则本身。

绝大多数 Redis 持久化相关配置修改后，必须重启服务才能生效。这不是可选项，而是设计使然——Redis 启动时一次性读取并固化配置，运行中无法动态加载 RDB/AOF 的核心开关和路径参数。

哪些持久化配置改了就得重启？

以下配置项写在 redis.conf 里，只要改动，就必须重启：

• save（RDB 触发条件）：比如把 save 900 1 改成 save 60 1，不重启，旧规则继续跑
• appendonly yes/no：开或关 AOF，改完不重启，CONFIG GET appendonly 看到的是新值，但实际不写日志
• dir（工作目录）：改了路径却不重启，RDB 还往老目录写，AOF 也追加到旧位置
• dbfilename 和 appendfilename：文件名变了，但进程仍用启动时加载的原始名字创建/追加文件
• appendfsync（AOF 刷盘策略）：设成 always 或 everysec，不重启，它还是按启动时的策略执行

有没有能热生效的持久化配置？

极少，且仅限运行时命令控制的局部行为：

• BGSAVE 和 BGREWRITEAOF 是即时触发命令，不用重启，但它们只影响“这一次”操作，不改变配置规则本身
• CONFIG SET save "60 1" 在某些 Redis 版本（如 6.2+）可能临时生效，但重启后丢失，且部分旧版本根本不支持该命令修改 save
• CONFIG SET appendonly yes 能打开 AOF，但要求：appendfilename 和 dir 必须已正确配置，否则会报错 ERR Append only file already exists and is not empty

注意：CONFIG SET 不是万能补丁，它不能替代重启来确保所有路径、权限、子进程行为一致。

Redis Skill - 高性能缓存管理

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

下载

Windows 下特别容易踩的坑

Windows 用户常忽略双配置文件问题：

• 如果你用 redis-server.exe redis.windows.conf 双击启动，只改 redis.windows.conf 就够了
• 如果你注册为 Windows 服务（redis-server --service-install），则必须同步修改 redis.windows-service.conf，否则服务启动时加载的是旧配置
• 改完配置后，别只用 redis-cli shutdown，它不会重新加载配置；得用 net stop Redis + net start Redis 或任务管理器彻底重启服务

验证是否真生效了？

重启后别急着信配置文件，直接查运行时状态：

• RDB 是否启用：CONFIG GET save 返回非空数组，且 INFO persistence 中 rdb_changes_since_last_save 在变动
• AOF 是否真在写：CONFIG GET appendonly 返回 yes，且 ls -l appendonly.aof（Linux）或 dir appendonly.aof（Windows）看到文件大小在增长
• 文件位置对不对：CONFIG GET dir 和 CONFIG GET dbfilename 拼出的完整路径，去文件系统里确认该文件是否存在、可写

最隐蔽的失败点是权限——尤其 Windows 上，服务账户对 dir 目录没写入权，会导致 RDB/AOF 静默失败，日志里只有一行 Can't open the dump.rdb file: Permission denied，但进程照常运行。