CONFIG SET修改aof-enabled未生效是因为仅禁用后续AOF写入，需同步执行CONFIG SET appendonly no才能真正停止；save规则修改后不会回溯触发RDB，appendfsync热更新无回滚机制且有数据丢失风险；所有CONFIG SET均不持久化，重启失效。

CONFIG SET 修改 aof-enabled 为什么没生效

Redis 的 aof-enabled 是运行时可调参数，但前提是 AOF 功能原本就处于关闭状态（即启动时没加载 AOF 文件、也没在配置里开启）。如果 Redis 已经在运行 AOF 模式，CONFIG SET aof-enabled no 会成功返回 OK，但不会立即停止写 AOF —— 它只禁用后续的 AOF 写入，已打开的 AOF 文件仍保持打开状态，直到你执行 BGREWRITEAOF 或重启。

• 真正停掉 AOF 日志写入，得先 CONFIG SET aof-enabled no，再 CONFIG SET appendonly no（后者是更底层的开关，部分版本必须配对使用）
• 检查是否生效：用 CONFIG GET aof-enabled 和 CONFIG GET appendonly 双重确认
• 常见错误现象：CONFIG SET aof-enabled no 后仍看到 appendfilename 文件持续增长 —— 很可能漏掉了 appendonly 的同步关闭

CONFIG SET 调整 save 规则后 RDB 不触发

save 配置项控制的是“多少秒内多少次修改”才触发 bgsave，但它只是条件之一。Redis 不会在每次满足条件时都立刻 fork 子进程，还要看上一次 RDB 是否还在进行、内存是否足够、是否有其他阻塞操作。

• 执行 CONFIG SET save "900 1 300 10 60 10000" 后，需注意：旧的 save 规则会被完全覆盖，不是追加
• 修改后不会回溯历史写操作，也就是说，刚改完的那几秒内即使满足新规则，也不会补发一次 bgsave
• 验证是否起作用：手动执行 DEBUG SLEEP 1 + INCR testkey 若干次，再观察 INFO persistence 中 rdb_changes_since_last_save 和 rdb_bgsave_in_progress 的变化
• 性能影响：过于激进的 save 规则（比如 "1 1"）会导致频繁 fork，尤其在大实例上易引发延迟毛刺

CONFIG SET 修改 appendfsync 有风险吗

appendfsync 控制 AOF 刷盘策略，热更新它不报错，但行为变化是即时且不可逆的——没有“回滚窗口”，也没有平滑过渡机制。

• appendfsync always → everysec：安全，丢失最多 1 秒数据，吞吐明显提升
• appendfsync everysec → no：危险！系统崩溃时可能丢失上次 fork 后所有 AOF 缓存，且无法预测丢多少
• Linux 内核版本低于 4.4 时，appendfsync no 在某些 I/O 压力下可能导致 AOF 文件损坏，不建议线上启用
• 变更后建议立刻用 redis-cli --rdb /tmp/test.rdb BGSAVE 做一次冷备快照，以防万一

CONFIG SET 生效但重启就丢失

这是最常被忽略的一点：CONFIG SET 只改内存中的运行时配置，不写入 redis.conf 文件。一旦进程重启，所有热更新全部失效，退回到原始配置。

• 想持久化修改，必须手动编辑 redis.conf 并重载（CONFIG REWRITE 可自动更新 conf，但仅限支持该指令的配置项，save 和 appendonly 支持，requirepass 等敏感项不支持）
• CONFIG REWRITE 不会清空注释、格式或未被 Redis 加载的配置行，但会删除所有已被覆盖的重复项
• 生产环境建议：把 CONFIG SET 操作和 CONFIG REWRITE 绑定为原子步骤；若用 Ansible/Terraform 管理配置，禁止依赖 CONFIG SET 做长期配置管理

热更新配置看着方便，但 AOF/RDB 相关参数牵扯到数据安全边界，稍有疏忽就会让“动态”变成“失联”。尤其是 appendonly 和 save 这两个开关，改之前最好先看一眼 INFO persistence 输出里的实际状态，而不是只信 CONFIG GET 的返回值。