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 的返回值。
