Redis持久化配置被修改不生效？正确使用CONFIG REWRITE命令
不少运维朋友都踩过这个坑：明明用 CONFIG SET 改了配置，也执行了 CONFIG REWRITE，可重启 Redis 后，改动却“神奇”地消失了。打开 redis.conf 一看，内容纹丝未动，或者只改了几行无关紧要的。这背后到底是怎么回事？今天咱们就来把这事儿彻底捋清楚。
CONFIG REWRITE 为什么没保存到 redis.conf 文件
先说结论：CONFIG REWRITE 命令的行为，和很多人直觉中的“实时保存”完全不是一回事。
Redis 的设计很明确：配置文件只在服务启动时被读取一次。运行期间，你用 CONFIG SET 做的任何修改，都只作用于内存，不会自动同步回磁盘文件。那么 CONFIG REWRITE 是干嘛的？它其实是一个“手动快照”工具——只负责将当前内存中那些被修改过、并且支持持久化的配置项，按照特定格式重写回你启动时用的那个配置文件里。
这里就有几个关键前提了：第一，Redis 必须是通过指定配置文件路径（比如 redis-server /path/to/redis.conf）启动的；第二，Redis 进程对那个配置文件得有写入权限。缺了任何一条，命令要么直接失败，要么静默无效。
所以，当你发现 CONFIG REWRITE 返回了 OK，但文件没变时，不妨按这个清单排查一下：
- 启动方式不对：如果当初是直接用
redis-server无参数启动（使用了内置默认配置），那 Redis 运行时根本就没有关联任何配置文件。这时执行CONFIG REWRITE，它会直接报错：(error) ERR The server is running without a config file。 - 权限不足：这是非常典型的场景。比如用 systemd 以
redis用户启动服务，但配置文件/etc/redis/redis.conf的所有者是 root，且目录权限没放开写权限。命令执行了，但进程没权限写文件，自然就静默失败了。 - 配置项不支持：不是所有能用
CONFIG SET改的参数，都能被写回文件。Redis 内部有一个白名单机制，有些参数（尤其是一些启动参数）修改后必须重启才生效，CONFIG REWRITE根本不会去动它们。
哪些配置项能被 CONFIG REWRITE 保存
这就涉及到 Redis 配置项的分类了。CONFIG REWRITE 很“聪明”，它不会把整个配置文件重写一遍，而是只处理那些既能在运行时动态修改，又在配置文件中有明确对应项的参数。
简单来说，可以这么区分：
- 支持持久化的（常见项）：比如
requirepass（密码）、maxmemory（最大内存）、maxmemory-policy（淘汰策略）、timeout（客户端超时）、tcp-keepalive、以及所有持久化相关配置，如sa ve（RDB规则）、appendonly、appendfilename、appendfsync。 - 通常不支持持久化的：像
bind、port、daemonize、pidfile、logfile这类参数，属于“启动即定型”。改了它们，必须重启服务，所以CONFIG REWRITE会直接忽略。
这里有个特别需要注意的“陷阱”：sa ve 参数。如果你在运行时执行 CONFIG SET sa ve "" 来关闭 RDB 持久化，那么 CONFIG REWRITE 会删除配置文件中所有的 sa ve 行。反过来，如果你新增了一条规则，比如 sa ve 60 1000，它会在文件末尾追加一行，而不是覆盖原来的。这个行为逻辑需要格外留意。
CONFIG REWRITE 的正确执行流程
理解了原理，正确的操作流程就清晰了。你不能把它当成一个黑盒命令，执行完就了事。它更像是一次“生成式覆盖”，必须配合人工校验。
一个稳妥的流程应该是这样的：
- 第一步，确认启动源：连上 Redis，执行
ps aux | grep redis，看看启动命令里是否包含了配置文件路径。或者，通过CONFIG GET dir获取工作目录，配置文件通常就在其上级或同级目录。 - 第二步，检查权限：找到配置文件后，用
ls -l确认 Redis 进程用户（如 redis）对其有写权限。记住，有时需要对文件所在目录也有写权限。 - 第三步，先备份，再操作：这是铁律。执行前，先用一条命令备份原配置：
cp /etc/redis/redis.conf /etc/redis/redis.conf.bak.$(date +%s)。 - 第四步，执行并立刻验证：执行
CONFIG REWRITE返回 OK 后，别急着走。马上用diff命令对比新旧配置文件，看看具体改动了哪些行，是否符合预期。 - 第五步，重点检查高危项：对于
sa ve和appendonly这类开关型配置，要逐字核对。一旦写错一个符号（比如多了一个引号），下次 Redis 启动就会直接报错退出，导致服务无法启动。
持久化配置修改后仍不生效的典型场景
最让人头疼的情况来了：明明 CONFIG REWRITE 执行成功，文件也确认修改了，可重启服务后，配置还是没变。别慌，大概率是下面这几种情况之一：
- 加载了错误的配置文件：这是头号元凶。比如，systemd 的 service 文件里写死了
ExecStart=/usr/bin/redis-server /etc/redis/6379.conf，而你一直修改的却是/etc/redis/redis.conf。Redis 重启时，当然只认 service 文件里指定的那个。 - 配置被“包含”了：如果主配置文件中使用了
include指令，引入了其他子配置文件，而你要改的项正好在子文件里定义。那么抱歉，CONFIG REWRITE只会写入主文件，不会跨文件去修改子文件的内容。 - AOF文件损坏：你修改了
appendonly yes并成功写回配置，但磁盘上已有的 AOF 文件（由appendfilename指定）已经损坏。Redis 启动时尝试加载 AOF 失败，出于安全考虑，会自动回退到 RDB 模式。这时候，你需要手动运行redis-check-aof --fix来修复文件。 - 容器化部署的路径问题：在 Docker/K8s 环境里，问题更复杂。可能是配置文件被挂载为只读（
:ro），导致写不进去；也可能是挂载路径错位——你修改的是宿主机的/opt/redis.conf，但容器内 Redis 进程读取的却是/usr/local/etc/redis.conf。
最后，必须牢记 Redis 配置加载的优先级顺序：启动命令行参数 > 配置文件 > include 子文件 > 默认值。这是一个链条，高级别的设置会覆盖低级别的。也就是说，哪怕你的 redis.conf 文件被 CONFIG REWRITE 改得完全正确，只要启动命令里带了 --appendonly yes 这样的参数，那么命令行参数永远说了算。这才是很多配置“死活不生效”的终极原因。
