Redis持久化配置完全指南
Redis作为一款高性能的内存数据库，其数据持久化能力是生产环境中不可或缺的特性。本文将详细讲解Redis的两种核心持久化机制——RDB和AOF，以及它们的配置方式、参数详解和最佳实践。
一、Redis持久化概述
Redis默认将数据存储在内存中，一旦进程退出或服务器宕机，所有数据将丢失。持久化机制可以将内存中的数据保存到磁盘，以便在重启后恢复数据。Redis提供了两种持久化方案：
RDB（Redis Database）：基于时间点的快照持久化
AOF（Append Only File）：基于操作日志的持久化
在Redis 4.0及以上版本，还支持混合持久化，结合了RDB和AOF的优点。
二、RDB持久化配置
2.1 RDB工作原理
RDB持久化会在指定的时间间隔内，将当前内存中的数据生成一份完整的快照（snapshot）保存到磁盘文件（默认为dump.rdb）。Redis通过fork一个子进程来完成快照的生成，主进程继续处理客户端请求，因此对性能影响较小。
2.2 RDB配置文件详解
RDB相关的配置项位于redis.conf文件中，以下是最常用的配置参数：
| 配置项 | 默认值 | 说明 |
|---|---|---|
| save | save 900 1 save 300 10 save 60 10000 | 设置触发RDB快照的条件，格式为：save <秒数> <变更次数> |
| dbfilename | dump.rdb | RDB文件的名称 |
| dir | ./ | RDB文件及AOF文件存放的目录 |
| rdbcompression | yes | 是否对RDB文件进行压缩（LZF算法） |
| rdbchecksum | yes | 是否在RDB文件末尾写入校验和，用于数据完整性校验 |
| stop-writes-on-bgsave-error | yes | 当RDB持久化失败时，是否停止写入操作 |
2.3 RDB配置示例
# 开启RDB持久化，设置快照触发条件 # 900秒内至少有1个key发生变化 # 300秒内至少有10个key发生变化 # 60秒内至少有10000个key发生变化 save 900 1 save 300 10 save 60 10000 # RDB文件名称 dbfilename dump.rdb # 文件存放目录 dir /var/lib/redis # 启用压缩 rdbcompression yes # 启用校验和 rdbchecksum yes # 当bgsave出错时停止写入 stop-writes-on-bgsave-error yes
2.4 RDB手动触发命令
SAVE：阻塞式保存，由主进程直接生成RDB文件，期间不处理任何请求（生产环境慎用）BGSAVE：后台保存，fork子进程生成RDB文件，主进程继续提供服务LASTSAVE：查看最近一次成功生成RDB文件的时间戳
2.5 禁用RDB
如果只想使用AOF持久化，可以完全禁用RDB：
# 注释所有save配置 # save 900 1 # save 300 10 # save 60 10000 # 或者使用空配置 save ""
三、AOF持久化配置
3.1 AOF工作原理
AOF持久化会记录每次对Redis数据进行修改的命令（如SET、HSET、LPUSH等），将这些命令追加到AOF文件的末尾。当Redis重启时，会重新执行AOF文件中的所有命令，从而恢复数据。
3.2 AOF配置文件详解
| 配置项 | 默认值 | 说明 |
|---|---|---|
| appendonly | no | 是否开启AOF持久化 |
| appendfilename | appendonly.aof | AOF文件的名称 |
| appendfsync | everysec | fsync策略：always（每次写入都同步）、everysec（每秒同步一次）、no（由操作系统决定同步时机） |
| no-appendfsync-on-rewrite | no | 在AOF重写期间是否暂停fsync，避免磁盘I/O冲突 |
| auto-aof-rewrite-percentage | 100 | 触发AOF重写的增长率阈值（当前文件大小相比上次重写时的增长百分比） |
| auto-aof-rewrite-min-size | 64mb | 触发AOF重写的最小文件大小 |
| aof-load-truncated | yes | 当AOF文件末尾被截断时，是否加载已存在的部分数据 |
| aof-use-rdb-preamble | yes（Redis 5.0+） | 是否开启混合持久化（RDB与AOF混合） |
3.3 AOF配置示例
# 开启AOF持久化 appendonly yes # AOF文件名称 appendfilename "appendonly.aof" # fsync策略：每秒同步一次，兼顾性能与数据安全 appendfsync everysec # 在AOF重写期间暂停fsync，减少磁盘压力 no-appendfsync-on-rewrite yes # AOF自动重写条件 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 允许加载截断的AOF文件（末尾损坏部分忽略） aof-load-truncated yes # 开启混合持久化（RDB + AOF） aof-use-rdb-preamble yes
3.4 三种fsync策略对比
| 策略 | 数据安全性 | 性能 | 说明 |
|---|---|---|---|
| always | 最高 | 最慢 | 每个写命令都执行fsync，最多丢失一个命令 |
| everysec | 较高 | 较快 | 每秒执行一次fsync，最多丢失1秒的数据（推荐） |
| no | 最低 | 最快 | 由操作系统决定何时同步，可能丢失大量数据 |
3.5 AOF重写机制
AOF文件会随着操作增多而不断膨胀。Redis通过AOF重写机制来压缩文件体积：将内存中的当前数据直接转换为命令集，替换掉旧的AOF文件。
手动触发AOF重写命令：
# 手动触发AOF重写 BGREWRITEAOF
AOF重写自动触发条件由以下配置控制：
# 当AOF文件大小比上次重写时增长了100%时触发 auto-aof-rewrite-percentage 100 # 只有当AOF文件大小超过64MB时才触发重写 auto-aof-rewrite-min-size 64mb
四、混合持久化
4.1 什么是混合持久化
从Redis 4.0开始，引入了混合持久化模式（RDB与AOF混合）。当开启此模式后，AOF重写操作生成的AOF文件将包含两部分：
前缀部分：RDB格式的二进制数据（当前内存快照）
后缀部分：增量AOF命令（重写期间产生的新修改）
4.2 混合持久化的优势
更快的恢复速度：加载时直接解析RDB快照，比逐条执行AOF命令快得多
更小的文件体积：RDB快照部分体积远小于等量的AOF命令
更好的数据安全性：RDB快照之后的部分仍然以AOF格式记录，保证数据完整
4.3 启用混合持久化
# 在redis.conf中设置 aof-use-rdb-preamble yes
启用后，当执行BGREWRITEAOF命令或自动触发AOF重写时，生成的文件将采用混合格式。
五、持久化策略选择建议
5.1 场景一：对数据安全性要求极高
推荐方案：AOF（everysec） + RDB
开启AOF，设置
appendfsync everysec，最多丢失1秒数据同时开启RDB作为补充备份，用于灾难恢复
开启混合持久化（
aof-use-rdb-preamble yes）加快重启速度
5.2 场景二：对性能要求极高，能容忍少量数据丢失
推荐方案：仅RDB
设置合理的save条件，如
save 3600 1（1小时内至少1个key变更触发）RDB对主进程性能影响最小，适合缓存场景
5.3 场景三：内存数据库作为主数据库使用
推荐方案：AOF（always） + RDB
AOF设置为
appendfsync always，保证每个写命令都不丢失RDB作为定期的全量备份，方便数据迁移
注意：此方案对磁盘I/O压力较大，需使用SSD
5.4 配置示例：生产环境推荐配置
# 通用基础配置 daemonize yes port 6379 bind 0.0.0.0 requirepass YourStrongPassword # 持久化配置 # RDB配置 save 900 1 save 300 10 save 60 10000 dbfilename dump.rdb dir /var/lib/redis rdbcompression yes rdbchecksum yes stop-writes-on-bgsave-error yes # AOF配置 appendonly yes appendfilename "appendonly.aof" appendfsync everysec no-appendfsync-on-rewrite yes auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-load-truncated yes # 混合持久化（Redis 5.0+） aof-use-rdb-preamble yes
六、持久化常见问题与解决方案
6.1 AOF文件损坏怎么办
如果AOF文件因意外导致损坏（如写入中断），Redis在启动时会尝试加载。如果加载失败，可以使用redis-check-aof工具修复：
# 检查AOF文件完整性 redis-check-aof /var/lib/redis/appendonly.aof # 修复损坏的AOF文件（将删除损坏部分） redis-check-aof --fix /var/lib/redis/appendonly.aof
6.2 RDB文件损坏怎么办
RDB文件损坏时，可以使用redis-check-rdb工具检查和修复：
# 检查RDB文件 redis-check-rdb /var/lib/redis/dump.rdb # Redis在加载损坏的RDB文件时会自动拒绝加载并记录错误日志
6.3 持久化对性能的影响
RDB影响：fork子进程生成快照时，如果数据量极大（超过10GB），fork操作本身可能造成毫秒级的延迟
AOF影响：
appendfsync always会对每个写命令执行磁盘同步，在高并发写入场景下性能下降明显优化建议：使用
appendfsync everysec，并将AOF和RDB文件放在SSD上
6.4 监控持久化状态
通过以下命令可以查看持久化状态：
# 查看持久化相关信息 INFO Persistence # 输出示例 # Persistence # loading:0 # rdb_changes_since_last_save:0 # rdb_bgsave_in_progress:0 # rdb_last_save_time:1634567890 # rdb_last_bgsave_status:ok # aof_enabled:1 # aof_rewrite_in_progress:0 # aof_last_rewrite_time_sec:0 # aof_last_bgrewrite_status:ok
七、总结
Redis的持久化配置需要根据业务场景权衡数据安全性和性能：
RDB：适合对数据一致性要求不高、需要快速备份和恢复的场景
AOF：适合对数据安全性要求高、能接受一定性能损耗的场景
混合持久化：推荐用于大多数生产环境，兼顾了RDB的快速恢复和AOF的数据安全性
建议在生产环境中至少保留一个RDB备份，并结合AOF的everysec策略，同时开启混合持久化。此外，定期手动执行BGREWRITEAOF和BGSAVE，并配合外部备份策略（如定时将持久化文件备份到远程存储），可以最大程度地保障数据安全。