Redis 的持久化方案有哪些？

Redis是一个内存数据库，持久化机制可将数据保存到磁盘，防止宕机时数据丢失。主要有两种持久化方案：

1. RDB（Redis Database）内存快照

• 原理：定期生成数据集的二进制快照文件（如 dump.rdb），保存指定时间点的全部数据。
  • 触发方式：
    • 手动触发：SAVE命令（阻塞Redis进程）； BGSAVE命令（后台异步执行，非阻塞）。
    • 自动触发：配置规则在 redis.conf文件中。例如：

       save 900 1    # 15分钟内至少1次修改  
       save 300 10   # 5分钟内至少10次修改  
       save 60 10000 # 1分钟内至少10000次修改  
      

  • 恢复方式：Redis启动时自动加载RDB文件恢复数据。
  • 优点：
    • 二进制文件体积小（压缩格式），恢复速度快（适合大规模数据）。
    • 运行性能影响小（fork子进程处理快照，主进程无I/O负担）。
  • 缺点：
    • 可能丢失最后一次快照后的数据（取决于备份频率）。
    • fork操作可能导致短暂主进程阻塞（尤其大内存数据集）。

2. AOF（Append-Only File）增量日志

• 原理：记录所有写操作命令为文本日志（存储在 appendonly.aof文件中），重启时重放命令重建数据库状态。
  • 日志同步策略：在 redis.conf中通过 appendfsync设置：
    • always：每条命令同步磁盘，确保安全但性能最低。
    • everysec（推荐）：每秒刷一次磁盘，平衡安全与性能（最多丢失1秒数据）。
    • no：由操作系统控制，性能最好但可能丢失更多数据。
  • 重写机制：通过 BGREWRITEAOF压缩AOF文件：
    • 自动触发条件（如 auto-aof-rewrite-percentage 100）。
    • 生成最小命令集代替旧文件，消除冗余写入。
  • 优点：
    • 数据安全性高（秒级数据丢失防护）。
    • 日志文件可读性强，方便错误排查。
  • 缺点：
    • 文件体积通常较大（需定期重写优化）。
    • 恢复速度比RDB慢（逐条命令重放）。

持久化方案对比与最佳实践

特性	RDB	AOF
数据安全	可能丢失分钟级数据	最多丢失1秒数据
文件大小	较小（压缩格式）	较大（需重写优化）
恢复速度	快（直接加载快照）	慢（重放命令耗时）
性能影响	fork操作短暂阻塞	写策略决定I/O压力
容错性	文件损坏可能导致不可用	支持修复工具 redis-check-aof

推荐生产环境配置

同时启用RDB和AOF以兼顾安全性与效率：

# RDB设置  
save 900 1  
save 300 10  
save 60 10000  
stop-writes-on-bgsave-error yes  # 备份失败停止写入  

# AOF设置  
appendonly yes  
appendfsync everysec  # 采用每秒同步策略  
auto-aof-rewrite-percentage 100  # 自动重写条件  
auto-aof-rewrite-min-size 64mb  

这确保数据持久化的同时最小化性能开销。