Redis 持久化到磁盘配置说明

一、持久化概述

Redis 是内存数据库，数据默认仅存储在内存中，重启后会丢失。持久化机制通过将数据写入磁盘，确保 Redis 重启后能恢复数据。Redis 支持两种核心持久化方式：

• RDB（Redis DataBase）：生成内存数据的快照（二进制文件），适用于数据备份和快速恢复。
• AOF（Append Only File）：记录所有写操作命令（文本文件），适用于数据高可用性场景。

二、RDB 持久化配置

1. 原理

RDB 通过快照机制，在指定时间点将内存中的所有数据保存到磁盘的 .rdb 文件中。触发方式分为自动触发和手动触发。

2. 核心配置（redis.conf）

找到 Redis 配置文件（默认 redis.conf），修改以下参数：

# 1. 自动触发快照的条件（格式：save <秒数> <修改次数>）
# 示例：60秒内有1000次修改、300秒内有10次修改、900秒内有1次修改，满足任一条件触发快照
save 60 1000
save 300 10
save 900 1

# 2. 关闭自动触发（如需禁用RDB，注释所有save配置，或添加：save ""）
# save ""

# 3. RDB文件存储路径（默认当前目录，建议指定绝对路径）
dir /var/lib/redis/

# 4. RDB文件名（默认dump.rdb）
dbfilename dump.rdb

# 5. 快照时是否压缩数据（默认yes，压缩可减小文件体积，轻微消耗CPU）
rdbcompression yes

# 6. 快照后是否校验数据完整性（默认yes，防止文件损坏，轻微消耗CPU）
rdbchecksum yes

# 7. 快照失败时是否停止Redis写入（默认no，建议保持no，避免影响业务）
stop-writes-on-bgsave-error no

3. 手动触发快照

通过 Redis 客户端执行以下命令：

• SAVE：同步执行快照，阻塞 Redis 服务（不推荐生产环境）。
• BGSAVE：异步执行快照（后台fork子进程处理），不阻塞服务（推荐生产环境）。
  示例：

redis-cli BGSAVE  # 异步生成RDB快照

4. 数据恢复

Redis 重启时，会自动加载 dir 目录下的 dbfilename 指定的 RDB 文件。如需手动恢复：

1. 停止 Redis 服务。
2. 将备份的 .rdb 文件放入 dir 配置的目录。
3. 启动 Redis 服务，自动加载数据。

5. 优缺点

优点：

• 文件体积小，恢复速度快（适合大规模数据）。
• 对性能影响小（BGSAVE 仅在 fork 子进程时短暂阻塞）。

缺点：

• 数据安全性低：若 Redis 崩溃，会丢失最后一次快照后的所有数据（如配置 save 60 1000，可能丢失60秒内的数据）。
• 不适合实时数据备份场景。

三、AOF 持久化配置

1. 原理

AOF 记录 Redis 所有写操作命令（如 SET、HSET、DEL），以文本格式追加到 .aof 文件中。Redis 重启时，通过重新执行文件中的命令恢复数据。

2. 核心配置（redis.conf）

# 1. 启用AOF（默认no，改为yes启用）
appendonly yes

# 2. AOF文件存储路径（与RDB共用dir目录，建议统一指定）
dir /var/lib/redis/

# 3. AOF文件名（默认appendonly.aof）
appendfilename "appendonly.aof"

# 4. AOF文件同步策略（关键！平衡性能和数据安全性）
#   - always：每执行1条写命令，立即同步到磁盘（最安全，性能最差）
#   - everysec：每秒同步1次（默认，平衡安全和性能，最多丢失1秒数据）
#   - no：由操作系统决定同步时机（性能最好，数据安全性最差）
appendfsync everysec

# 5. 同步时是否延迟写入（默认no，仅在appendfsync=always时有效）
no-appendfsync-on-rewrite no

# 6. AOF文件重写触发条件（避免文件过大）
#   - 当AOF文件大小超过上次重写后的100%（即翻倍）时触发
auto-aof-rewrite-percentage 100
#   - 当AOF文件大小至少达到64MB时才触发重写（避免小文件频繁重写）
auto-aof-rewrite-min-size 64mb

# 7. 重写时是否忽略错误命令（默认yes，防止因错误命令导致重写失败）
aof-rewrite-incremental-fsync yes

# 8. AOF文件损坏时的恢复策略（Redis 4.0+）
#   - yes：尝试修复损坏的AOF文件（默认）
#   - no：直接报错，需手动修复
aof-load-truncated yes

3. 手动操作

• 查看AOF文件内容（文本格式，可直接打开）：

  cat /var/lib/redis/appendonly.aof
  

• 手动触发AOF重写（优化文件体积）：

  redis-cli BGREWRITEAOF  # 异步执行，不阻塞服务
  

• 修复损坏的AOF文件（如文件末尾缺失导致加载失败）：

  redis-check-aof --fix /var/lib/redis/appendonly.aof  # Redis自带修复工具
  

4. 数据恢复

1. 确保 appendonly yes 已配置。
2. 停止 Redis 服务，将备份的 appendonly.aof 文件放入 dir 目录。
3. 启动 Redis 服务，自动执行 AOF 文件中的命令恢复数据。

5. 优缺点

优点：

• 数据安全性高：默认每秒同步，最多丢失1秒数据；always 模式可实现零数据丢失。
• 文件可读性强，便于手动排查问题。

缺点：

• AOF 文件体积比 RDB 大（记录命令而非数据快照）。
• 恢复速度比 RDB 慢（需重新执行所有命令）。
• 高并发写场景下，appendfsync everysec 可能对性能有轻微影响。

四、RDB 与 AOF 混合使用（推荐生产环境）

1. 配置方式

同时启用 RDB 和 AOF，配置如下：

# 启用RDB（保留自动快照）
save 60 1000
save 300 10
save 900 1
dbfilename dump.rdb

# 启用AOF（核心数据保障）
appendonly yes
appendfsync everysec
appendfilename appendonly.aof

2. 工作机制

• 日常通过 AOF 保证数据高可用（最多丢失1秒数据）。
• 定期通过 RDB 生成快照（如每小时），用于数据备份和快速恢复（重启时优先加载 AOF，若 AOF 不存在则加载 RDB）。

3. 优势

• 兼顾数据安全性（AOF）和恢复速度（RDB）。
• 避免单一持久化机制的缺陷（如 RDB 数据丢失、AOF 恢复慢）。

五、关键注意事项

1. 存储路径权限：确保 Redis 运行用户（如 redis）对 dir 目录有读写权限（建议 chmod 755 /var/lib/redis）。
2. 磁盘空间：定期清理过期的 RDB/AOF 备份文件，避免磁盘占满。
3. 性能优化：
   • RDB：使用 BGSAVE 而非 SAVE，避免阻塞服务。
   • AOF：默认 appendfsync everysec 已足够，无需盲目追求 always（除非业务要求零数据丢失）。
4. 备份策略：
   • 定期（如每天）备份 RDB 和 AOF 文件到异地存储（如云盘、备份服务器）。
   • 避免在 Redis 高峰时段执行手动快照或 AOF 重写（可能加重 CPU 负担）。
5. 版本兼容性：
   • RDB 文件兼容所有 Redis 版本（跨版本恢复可靠）。
   • AOF 文件在 Redis 4.0+ 支持重写优化，低版本需注意兼容性。

六、总结

根据业务需求选择合适的持久化方案，生产环境建议混合使用 RDB 和 AOF，既保证数据安全，又兼顾恢复效率。