Redis持久化RDB与AOF：配置、恢复与避坑实操

Redis默认把数据放在内存里，重启服务或服务器后数据会全部丢失。
RDB和AOF是两种把数据保存到磁盘的机制，RDB定期生成数据快照，AOF记录每次写命令。
新手先搞懂区别，再按步骤配置验证，就能避免重启丢数据。

两种持久化机制到底存了什么

RDB（Redis Database）在指定时间间隔内，把当前内存中的数据集快照写入磁盘文件，默认叫dump.rdb。
它恢复速度快，文件体积小，适合做备份和灾难恢复，但两次快照之间如果服务崩溃，这段时间的写入会丢失。

AOF（Append Only File）把每个写操作追加到文件末尾，默认叫appendonly.aof。
它数据安全性更高，可以做到每秒同步甚至每次写命令都同步，但文件体积大，恢复速度比RDB慢。

两种机制可以同时开启，Redis重启时会优先用AOF恢复数据，因为AOF通常记录得更完整。

动手配置前先确认这几项

确认Redis版本和配置文件路径。
大多数Linux发行版通过包管理器安装后，配置文件在/etc/redis/redis.conf。
用源码编译安装的话，通常在安装目录下。
执行以下命令确认：

redis-server --version
ps aux | grep redis-server

找到实际加载的配置文件路径，后续修改才对生效。
如果使用宝塔面板，可以在软件商店的Redis管理界面直接修改配置，路径通常是/www/server/redis/redis.conf。

修改配置前先备份原文件：

cp /etc/redis/redis.conf /etc/redis/redis.conf.bak

RDB持久化怎么配置和验证

打开配置文件，找到save开头的行。
默认配置类似：

save 900 1
save 300 10
save 60 10000

意思是900秒内至少1个键被修改、300秒内至少10个键被修改、60秒内至少10000个键被修改时，触发快照保存。
新手可以保持默认，或者根据数据重要程度调整。

找到dbfilename和dir两项，确认RDB文件存放位置：

dbfilename dump.rdb
dir /var/lib/redis

改完后重启Redis：

systemctl restart redis

验证是否生效，进入Redis命令行手动触发一次保存：

redis-cli
127.0.0.1:6379> BGSAVE

看到Background saving started说明后台保存已启动。
等几秒后检查文件是否生成：

ls -lh /var/lib/redis/dump.rdb

再执行redis-cli INFO persistence，查看rdb_last_bgsave_status:ok表示上次保存成功。

AOF持久化开启步骤与刷盘策略

在配置文件中找到appendonly，改为：

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

appendfsync有三个可选值：

• always：每条写命令都同步到磁盘，最安全但性能最差。
• everysec：每秒同步一次，兼顾性能和安全，推荐生产环境使用。
• no：由操作系统决定何时同步，性能最好但可能丢较多数据。

重启Redis使配置生效：

systemctl restart redis

验证AOF是否工作，写入一个测试键：

redis-cli SET testkey hello

然后检查AOF文件是否变大：

ls -lh /var/lib/redis/appendonly.aof

执行redis-cli INFO persistence，看到aof_enabled:1和aof_last_write_status:ok说明AOF正常。

数据恢复与常见报错处理

重启Redis后如果数据没回来，先查日志：

tail -n 50 /var/log/redis/redis-server.log

常见情况有三种：

RDB文件损坏：日志提示Short read or OOM loading DB。
可以用redis-check-rdb工具检查：

redis-check-rdb /var/lib/redis/dump.rdb

如果文件损坏且没有备份，数据可能无法完全恢复。
所以定期备份dump.rdb和appendonly.aof很重要。

AOF文件末尾不完整：Redis启动时提示Bad file format reading the append only file。
可以用以下命令修复：

redis-check-aof --fix /var/lib/redis/appendonly.aof

修复会截断不完整的末尾命令，可能丢失最后几条写入。

权限问题：Redis进程用户没有读写dir目录的权限。
用chown redis:redis /var/lib/redis修正，再重启服务。

生产环境选型与避坑建议

如果数据量不大且能接受分钟级丢失，只开RDB够用。
如果对数据安全性要求高，建议同时开启RDB和AOF。
AOF用everysec策略，RDB保留一份定期快照用于备份和快速恢复。

几个容易踩的坑：

• 改了配置文件但忘记重启Redis，配置不生效。
• dir目录磁盘空间不足，导致持久化失败但服务不报错，要监控磁盘使用率。
• 主从架构下，从库默认也会生成RDB和AOF，如果不需要可以关闭从库的AOF以节省资源。
• 不要手动删除appendonly.aof文件，否则重启后AOF为空，Redis会以空数据启动。

验证持久化是否真正可靠，最直接的方法是：写入几条测试数据，重启Redis服务，再查数据是否还在。

redis-cli SET testkey 12345
systemctl restart redis
redis-cli GET testkey

如果返回12345，说明持久化配置生效。

常见疑问

RDB和AOF能同时用吗？
可以，而且推荐生产环境这样配置。Redis重启时优先加载AOF，因为AOF通常数据更完整。

AOF文件越来越大怎么办？
Redis提供AOF重写机制，执行BGREWRITEAOF命令可以压缩AOF文件。也可以在配置文件中设置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size自动触发。

持久化会影响Redis性能吗？
RDB的BGSAVE会fork子进程，fork瞬间可能造成短暂延迟。AOF的everysec策略性能影响很小。如果对延迟极其敏感，需要评估业务能否接受。