Redis持久化怎么配置最好

Redis持久化配置的最佳实践

一 核心原则

• 没有一种配置对所有场景都“最好”，应根据业务对数据安全性、性能、恢复速度和运维复杂度的权衡来选择。
• 默认情况下 Redis 并不会持久化，需要显式开启 RDB 或 AOF；两者也可同时开启，重启时以AOF为准（更完整）。RDB 快照由后台bgsave生成，AOF 通过追加写命令并重写保持文件可控。

二 推荐配置模板

• 通用高可靠（RDB+AOF 混合，优先 AOF 恢复）

  • 适用：对数据丢失敏感、需要快速可靠恢复。
  • 配置要点：
    • RDB：保留默认触发策略（如：save 900 1、save 300 10、save 60 10000），开启压缩与校验，bgsave 失败告警并停止写入。
    • AOF：开启，同步策略用appendfsync everysec（最多丢失约1秒数据），开启自动重写并设置合理阈值。
  • 参考配置片段：

    save 900 1
    save 300 10
    save 60 10000
    stop-writes-on-bgsave-error yes
    rdbcompression yes
    rdbchecksum yes
    dbfilename dump.rdb
    dir /var/lib/redis
    
    appendonly yes
    appendfilename "appendonly.aof"
    appendfsync everysec
    auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb
    

  • 说明：同时开启时，Redis 启动优先加载 AOF 文件进行恢复。

• 极致性能/缓存优先（主库关闭持久化，从库持久化）

  • 适用：可接受故障时丢失少量数据（如纯缓存），追求写入吞吐与低延迟。
  • 配置要点：
    • 主库：关闭 AOF；RDB 可关闭自动快照（如 save ""），或仅在维护窗口手动 bgsave；避免 AOF rewrite 带来的抖动。
    • 从库：开启 AOF（everysec）或仅保留 RDB 快照用于恢复与备份；从库承担持久化与备份职责。
  • 说明：主从异步复制下，主库宕机可能丢失少量未复制数据；此方案在多分片/集群中较常见。

• 只做缓存、允许丢数据

  • 适用：数据可重建、强调极致性能与资源利用。
  • 配置要点：主从均可不启用持久化；配合完善的监控告警与快速重建机制（如从源数据重建缓存）。

三 关键参数与调优要点

• RDB
  • 触发策略：使用多个 save m n 条件（满足任一即触发），如默认 900/1、300/10、60/10000；自动触发本质调用 bgsave。
  • 可靠性与性能：stop-writes-on-bgsave-error yes 可在快照失败时停止写入，避免“假成功”；rdbcompression yes 节省空间但增加 CPU；rdbchecksum yes 提升启动校验可靠性；dbfilename 与 dir 规范命名与落盘路径便于多实例与备份。
• AOF
  • 同步策略：appendfsync everysec 为通用平衡选择；always 安全但吞吐低；no 交由 OS 同步，风险高。
  • 重写机制：auto-aof-rewrite-percentage 与 auto-aof-rewrite-min-size 控制重写触发，避免 AOF 文件无限增长；重写过程会生成新文件并替换旧文件，期间有额外 IO 与短暂抖动。
• 恢复顺序与兼容性
  • 同时开启时，Redis 启动优先加载 AOF；仅启用其一时分别加载对应文件（AOF 或 RDB）。

四 运维与备份建议

• 定期做离线备份：对 RDB 快照与 AOF 文件做周期性拷贝到远程/异地存储；保留多份与多年龄段（如日/周/月）以便回滚。
• 监控与告警：关注 bgsave/AOF rewrite 失败、磁盘空间、IO 延迟、主从复制偏移；异常时及时切换与恢复。
• 变更与演练：调整 save 策略、appendfsync 或重写阈值前在测试环境验证；定期做故障演练与恢复演练，验证 RTO/RPO 是否符合 SLA。