Redis RDB持久化之 save 自动备份检查机制

Redis RDB持久化之 save 自动备份检查机制

一、核心概念澄清

1.1 常见误解（滑动时间窗口）

错误理解 ：在过去的 seconds 秒内，如果有 changes 次key变化，则触发备份。

正确理解 ：Redis的save检查是固定时间窗口，以上一次成功RDB保存的时间点为起点。

1.2 实现原理（源码逻辑）

// Redis server.c 中的检查逻辑（简化版）
void serverCron() {
    for (each save_param) {
        if (dirty >= save_param->changes &&  
            (current_unixtime - lastsave_time) >= save_param->seconds) {
            rdbSaveBackground();
            break;
        }
    }
}

• dirty：自上次保存以来发生变化的key数量（写入、更新、删除都算）
• lastsave_time：上次成功RDB保存的时间戳
• 条件 ：时间差 ≥ 配置秒数 且 脏数据量 ≥ 配置变化次数

二、工作流程详解

2.1 变量初始化

• 服务器启动：lastsave_time = 当前时间戳，dirty = 0
• 每次写操作：dirty++
• 每次成功保存后：lastsave_time = 当前时间戳，dirty = 0

2.2 检查时机

• Redis在serverCron中周期性检查（默认10次/秒）
• 也响应客户端命令（如BGSAVE、SAVE）
• 每次写操作后不会立即检查，而是通过定时任务

2.3 配置语法

save <seconds> <changes>   # 注意：不带"s"后缀
save 900 1      # 900秒内至少1次变化
save 300 10     # 300秒内至少10次变化
save 60 10000   # 60秒内至少10000次变化

三、实例分析与对比

3.1 场景示例（配置：save 10 2）

时间线：

• T=0s：服务器启动，lastsave_time=0，dirty=0
• T=5s：SET key1 → dirty=1
  检查：5-0=5s < 10s 或 dirty=1 < 2 → 不触发
• T=16s：SET key2 → dirty=2
  检查：16-0=16s ≥ 10s ✅ 且 dirty=2 ≥ 2 ✅ → 触发备份

3.2 与滑动窗口的对比

检查方式	条件	场景（T=5s 1次，T=16s 1次）	结果
滑动窗口（错误理解）	任意连续10秒内≥2次变化	每个窗口都只有1次 → 不触发	❌
固定窗口（Redis实际）	从上次保存起≥10秒且累计≥2次	16-0=16≥10，dirty=2≥2 → 触发	✅

四、注意事项与调试

4.1 多条件并行检查

Redis会检查所有save配置，只要任意一个条件满足就触发。

4.2 查看当前状态

redis-cli INFO persistence
redis-cli CONFIG GET save
redis-cli LASTSAVE   # 返回上次保存时间戳

4.3 调试日志（Redis 6.0+）

redis-cli CONFIG SET loglevel verbose
tail -f /var/log/redis/redis-server.log | grep -i save

五、最佳实践建议

5.1 配置策略

• 高频写入业务 ：较大时间窗口，如 save 60 10000
• 关键数据 ：较严格条件，如 save 900 1 + save 300 5
• 无自动备份 ：save ""（但建议开AOF）

5.2 避免常见误区

1. 语法错误 ：save 5s 2 ❌ → save 5 2 ✅
2. 认为修改配置需要重启 ：使用CONFIG SET save "..."动态修改
3. 忽略持久化监控：定期检查RDB文件生成时间和大小

六、延伸阅读

• Redis持久化配置：redis.conf中的save、rdbcompression、dbfilename等
• RDB与AOF混合持久化：Redis 4.0+支持
• 持久化监控指标：rdb_last_save_time、rdb_changes_since_last_save

---

最后提醒：Redis的save检查是"从上一次备份点开始计时"的固定窗口，不是滑动窗口。理解这一点对合理配置备份策略至关重要。