save指令控制redis自动触发bgsave的条件，即在指定时间内满足最少修改键数时执行后台快照，仅影响bgsave行为，与阻塞式save命令无关。
save指令到底控制什么
save 指令不是“开启RDB”，而是定义「在什么条件下触发自动快照」。它只对 Redis 的后台 bgsave 行为起作用，和 save 命令（阻塞式保存）无关。很多线上事故就源于混淆这两者——误以为配了 save 900 1 就等于“每15分钟必存一次”，其实它只在满足「900秒内至少有1个key被修改」时才触发。
- 每行
save <seconds><changes></changes></seconds>是独立条件，任意一条匹配即执行bgsave - 如果所有
save行都被注释掉（# save 900 1），Redis 将完全禁用自动 RDB，仅靠 AOF 或手动bgsave - 修改配置后必须
redis-cli config rewrite或重启才生效，config set save "..."不支持动态设置
高写入场景下 save 阈值为什么经常失效
当业务写入非常密集（比如每秒数万次写操作），save 60 10000 这类配置容易变成“永远不触发”：因为 Redis 统计的是「自上次成功 bgsave 后的总变更数」，而高频写入会让这个计数器在几秒内就冲过阈值，但此时上一个 bgsave 可能还没结束——Redis 会跳过新触发，等上一个完成后再重置计数器。结果就是快照间隔远超预期，甚至长达几十分钟。
- 典型现象：
INFO persistence中rdb_last_bgsave_time_sec突然变大，rdb_changes_since_last_save却一直卡在略低于阈值的位置 - 根本原因：RDB 是重量级操作，子进程 fork + 写磁盘，高负载下耗时增加，形成“触发-排队-跳过-再触发”的空转循环
- 更稳的做法是放宽时间窗口，比如
save 300 5000→save 600 10000，用时间换稳定性，避免频繁争抢 fork
和 AOF 共存时 save 配置还有没有意义
有，而且影响比想象中更大。即使启用了 AOF（appendonly yes），只要没关掉 save，Redis 在每次 bgsave 成功后仍会清空 rdb_changes_since_last_save 计数器——这直接干扰 AOF 重写（bgrewriteaof）的触发逻辑。AOF 重写默认策略是「当前 AOF 文件大小 ≥ 上次重写后大小的100% 且 ≥ 64MB」，但如果 bgsave 频繁发生，AOF 重写可能被长期压制。
- 若纯用 AOF，建议显式关闭 RDB 自动触发：
save ""（空字符串）或全部注释掉save行 - 混用模式下，要同步调低 AOF 重写的敏感度：
auto-aof-rewrite-percentage 50，避免因 RDB 干扰导致 AOF 膨胀过快 -
save和appendfsync无直接关系，但两者共同决定磁盘 I/O 峰值——别让bgsave和appendfsync everysec的刷盘时间撞在一起
如何验证当前 save 配置是否生效
别只看 redis.conf 文件，得查运行时实际加载的值。Redis 启动时会把 save 解析成内部数组，但 CONFIG GET save 返回的是原始字符串，不能反映真实行为。
- 用
CONFIG GET save查当前配置值，返回类似1) "save" 2) "300 10 60 10000"，注意它是单个字符串，空格分隔多组参数 - 真正判断是否启用，看
INFO persistence中rdb_bgsave_in_progress和rdb_last_bgsave_status，后者为ok才说明机制跑起来了 - 最直接的验证方式：临时设一个激进阈值
CONFIG SET save "1 1"（不推荐长期用），然后改一个 key，等 1 秒后检查redis-server日志里有没有Background saving started
配置不是设完就完事，关键得盯住 rdb_changes_since_last_save 的波动节奏和 rdb_last_bgsave_time_sec 的稳定性——这两个数字比 conf 文件里的文字更能说明问题。
