Redis 持久化 速览

Redis 持久化是确保数据安全性的关键机制，通过将内存中的数据保存到磁盘，防止服务器故障导致数据丢失。Redis 支持两种持久化方式：RDB（Redis Database Backup）和 AOF（Append-Only File），以及混合持久化模式。以下是 Redis 持久化的详细解析：

一、RDB 持久化

1. 定义与原理

• 定义：RDB 持久化通过快照（Snapshot）将内存中的数据保存到磁盘，生成一个二进制文件（dump.rdb）。
• 原理：Redis 在指定条件下（如时间间隔、写操作次数）触发快照保存，将内存数据序列化到磁盘。

2. 工作流程

• 自动触发：

  • 通过 save 参数配置自动保存条件（如 save 900 1 表示 900 秒内至少 1 次写操作）。
  • 当条件满足时，Redis 触发 bgsave 命令，fork 子进程执行快照保存。

• 手动触发：

  • 通过 SAVE 命令同步执行快照保存（阻塞主进程，不推荐生产环境使用）。
  • 通过 BGSAVE 命令异步执行快照保存（fork 子进程，不阻塞主进程）。

3. 配置参数

• save：配置自动保存条件（如 save 900 1）。
• stop-writes-on-bgsave-error：当 bgsave 失败时，是否阻止写操作（默认 yes）。
• rdbcompression：是否启用 RDB 文件压缩（默认 yes，使用 LZF 算法）。
• rdbchecksum：是否启用 RDB 文件校验和（默认 yes，确保文件完整性）。
• dbfilename：配置 RDB 文件名（默认 dump.rdb）。
• dir：配置 RDB 文件保存路径。

4. 优点与缺点

• 优点：

  • 文件紧凑：RDB 文件紧凑，适合备份和传输。
  • 恢复速度快：恢复数据时，只需加载 RDB 文件到内存。
  • 性能影响小：通过 bgsave 异步执行，对主进程影响较小。

• 缺点：

  • 数据丢失风险：两次快照间隔内的写操作可能丢失。
  • fork 开销：频繁 bgsave 可能增加系统负载（fork 子进程需要内存拷贝）。

二、AOF 持久化

1. 定义与原理

• 定义：AOF 持久化通过记录所有写操作命令到磁盘文件（appendonly.aof），确保数据安全性。
• 原理：Redis 将每个写操作命令追加到 AOF 缓冲区，再根据配置策略同步到磁盘。

2. 工作流程

• 命令追加：

  • 每个写操作命令（如 SET、LPUSH）被追加到 AOF 缓冲区。

• 文件同步：

  • 通过 appendfsync 参数配置同步策略：
    • always：每次写操作都同步到磁盘（安全性高，性能低）。
    • everysec：每秒同步一次（默认，平衡安全性和性能）。
    • no：由操作系统决定同步时机（性能高，安全性低）。

• 文件重写：

  • 通过 bgrewriteaof 命令或自动触发（当 AOF 文件过大时），重新生成一个更小的 AOF 文件。
  • 文件重写过程：
    1. fork 子进程，读取当前内存数据。
    2. 生成新的 AOF 文件，包含重建当前数据集所需的最小命令集合。
    3. 原子替换旧 AOF 文件。

3. 配置参数

• appendonly：是否启用 AOF 持久化（默认 no）。
• appendfsync：配置 AOF 文件同步策略（如 everysec）。
• no-appendfsync-on-rewrite：在 AOF 重写期间，是否暂停同步（默认 no）。
• auto-aof-rewrite-percentage：配置 AOF 重写触发条件（如 100 表示文件增长 100% 时触发）。
• auto-aof-rewrite-min-size：配置 AOF 重写最小文件大小（如 64mb）。
• aof-load-truncated：当 AOF 文件损坏时，是否加载剩余部分（默认 yes）。
• aof-use-rdb-preamble：是否启用混合持久化（默认 no）。

4. 优点与缺点

• 优点：

  • 数据安全性高：所有写操作都被记录，故障时最多丢失 1 秒数据（everysec 策略）。
  • 可追加日志：支持通过追加日志恢复数据，适合需要高数据安全性的场景。

• 缺点：

  • 文件体积大：AOF 文件体积通常大于 RDB 文件。
  • 恢复速度慢：恢复数据时，需重新执行所有写操作命令。
  • 性能影响：频繁的文件同步可能增加 I/O 开销。

三、混合持久化

1. 定义与原理

• 定义：混合持久化结合 RDB 和 AOF 的优点，先执行 RDB 快照，再记录 AOF 日志。
• 原理：在 AOF 重写时，先写入 RDB 格式的数据，再追加 AOF 日志，确保数据安全性和恢复速度。

2. 工作流程

• AOF 重写：

  • 通过 bgrewriteaof 命令触发 AOF 重写。
  • 子进程读取当前内存数据，生成 RDB 格式的数据。
  • 将 RDB 数据和后续的 AOF 日志追加到新 AOF 文件。

• 数据恢复：

  • 加载 RDB 数据到内存。
  • 重新执行 AOF 日志中的写操作命令。

3. 配置参数

• aof-use-rdb-preamble：是否启用混合持久化（默认 no，需设置为 yes）。

4. 优点与缺点

• 优点：

  • 平衡性能和数据安全性：结合 RDB 的快速恢复和 AOF 的数据安全性。
  • 减少 AOF 文件体积：通过 RDB 快照减少 AOF 日志量。

• 缺点：

  • 配置复杂：需同时配置 RDB 和 AOF 参数。
  • 兼容性问题：混合持久化生成的 AOF 文件可能与旧版本 Redis 不兼容。

四、持久化策略选择

1. 根据业务需求选择

• 数据安全性要求高：选择 AOF 持久化（appendfsync everysec）。
• 性能要求高：选择 RDB 持久化（save 900 1）。
• 平衡两者：选择混合持久化（aof-use-rdb-preamble yes）。

2. 典型场景配置

• 缓存场景：

  • 允许数据丢失：关闭持久化（save ""，appendonly no）。
  • 允许少量数据丢失：启用 RDB 持久化（save 900 1）。

• 数据库场景：

  • 高数据安全性：启用 AOF 持久化（appendfsync everysec）。
  • 平衡性能和数据安全：启用混合持久化（aof-use-rdb-preamble yes）。

五、持久化优化

1. 调整配置参数

• RDB 优化：

  • 调整 save 参数平衡自动保存频率和性能。
  • 调整 stop-writes-on-bgsave-error 参数避免阻塞写操作。

• AOF 优化：

  • 调整 appendfsync 参数平衡安全性和性能。
  • 调整 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 参数优化重写触发条件。

• 混合持久化优化：

  • 确保 aof-use-rdb-preamble 参数启用。

2. 监控持久化状态

• RDB 监控：

  • 通过 INFO persistence 命令查看 rdb_last_save_time 和 rdb_changes_since_last_save。
  • 通过 LASTSAVE 命令查看最后一次 RDB 保存时间。

• AOF 监控：

  • 通过 INFO persistence 命令查看 aof_last_bgrewrite_status 和 aof_current_size。
  • 通过 INFO stats 命令查看 aof_delayed_fsync 计数。

3. 故障恢复

• 从 RDB 文件恢复：

  • 停止 Redis 服务器。
  • 备份当前 dump.rdb 文件。
  • 将备份的 dump.rdb 文件复制到 dir 配置的路径。
  • 启动 Redis 服务器，加载 RDB 文件。

• 从 AOF 文件恢复：

  • 停止 Redis 服务器。
  • 备份当前 appendonly.aof 文件。
  • 将备份的 appendonly.aof 文件复制到 dir 配置的路径。
  • 启动 Redis 服务器，加载 AOF 文件。

• 从混合持久化文件恢复：

  • 停止 Redis 服务器。
  • 备份当前 appendonly.aof 文件。
  • 启动 Redis 服务器，加载混合持久化文件。

六、总结

Redis 持久化通过 RDB、AOF 和混合持久化三种方式确保数据安全性。RDB 适合备份和快速恢复，AOF 适合高数据安全性场景，混合持久化平衡两者。用户可根据业务需求选择合适的持久化策略，并通过调整配置参数和监控持久化状态优化性能。在故障恢复时，需根据持久化方式选择合适的恢复流程。