持久化

RDB

Redis Database

1. 机制
   1. 在满足配置条件或手动触发时，将某一时刻的内存数据生成紧凑的二进制快照文件。
   2. Redis 重启时可以载入 RDB 文件恢复数据，但两次快照之间的数据可能丢失。
   3. BGSAVE 使用子进程生成快照，并利用操作系统的 Copy-on-Write；数据量较大时，fork 和内存页复制仍可能造成延迟及额外内存压力。
2. 数据结构

3. 触发条件
   1. 手动触发
      1. SAVE：执行该命令后，主线程运行 rdbSave 函数，服务器进程阻塞，不能处理其他请求
      2. BGSAVE（Background Save）：通过 fork 创建子进程执行 rdbSave，主线程仍可处理新请求。
   2. 自动触发
      1. 配置文件中写入 save m n，代表 m 秒内发生 n 次变化时自动执行 BGSAVE

AOF

Append Only File

1. 机制
   1. 将会修改数据集的命令追加到日志。
   2. Redis 重启时重放 AOF 中的命令以恢复数据。
   3. Redis 7 起使用 Multi-Part AOF，由一个 Base 文件、多个 Incremental 文件和 Manifest 清单组成。
2. 重写与恢复
   1. 文件重写策略，根据当前数据库的状态，创建一个新的AOF文件，以替代原有的冗余AOF文件
   2. 重写根据当前数据状态生成恢复所需的最小命令集合，而不是简单复制旧 AOF 中的冗余命令。

• Redis 恢复策略

• Redis 重写流程

1. 触发条件
   1. 手动触发：BGREWRITEAOF
   2. 自动触发：配置文件中设置 appendonly yes 开启，默认策略是 Everysec
      1. Always：即同步写回，在每个写命令执行完成后，直接将命令落入磁盘文件（数据基本保证可靠性，但是影响Redis的性能）
      2. everysec：通常每秒执行一次 fsync，兼顾性能与持久性；故障时可能丢失约 1 秒、极端情况下接近 2 秒的数据
      3. no：仍然写 AOF，但何时将缓冲区同步到磁盘由操作系统决定，性能影响最小，数据丢失窗口不可控

同时开启 AOF 和 RDB 时，Redis 重启会优先使用数据通常更完整的 AOF 恢复。持久化不等于备份，生产环境仍需把快照复制到独立故障域并定期验证恢复流程。