Redis持久化机制实战：RDB与AOF策略配置及数据恢复方案

Redis高性能的关键在内存，但内存数据断电即失。持久化策略选错，轻则重启丢数据，重则恢复时阻塞线上服务。RDB与AOF两种机制各有取舍，组合策略决定数据安全上限。本文从配置参数、故障场景到恢复步骤给出完整方案。

RDB快照与AOF日志的机制差异

RDB按时间点生成二进制快照，体积小、加载快，但两次快照之间的数据会丢失；AOF记录每条写命令，默认每秒刷盘（appendfsync everysec），最多丢失1秒数据，但文件体积大、恢复慢。机制对比如下：

持久化配置与参数解析

# RDB配置
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir /data/redis

# AOF配置
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

save 900 1表示900秒内至少1次写就触发快照；appendfsync everysec在性能与数据安全间均衡，生产环境默认推荐。

AOF重写与压缩机制

AOF随写入膨胀，自动重写会在后台把内存当前数据重写为最小命令集，触发条件是体积超过上次重写后的100%且大于64MB。重写期间新写命令进入缓冲，不影响正常服务。

故障恢复场景：从RDB与AOF加载

启动时Redis自动加载数据文件，优先级为AOF优先于RDB。AOF损坏时的恢复流程：

redis-check-aof --fix appendonly.aof
redis-server /etc/redis/redis.conf
redis-cli dbsize

RDB文件损坏用 redis-check-rdb 检测修复。恢复后对比dbsize与预期键数，确认数据完整再切换业务流量。

持久化与性能的取舍

高写入场景下eachsec模式仍有1秒窗口，金融级数据在Redis之上建议增加多副本与同步复制保障。若持久化完全关闭（appendonly no且save全注释），Redis退化为纯缓存，性能最高但重启全部丢失，仅适合可容忍丢数据的场景。

云Redis与自建的选择

云厂商托管Redis自带持久化、自动备份与高可用，运维成本低；自建需自行维护持久化文件、快照与主从同步。生产环境至少开启AOF，并配合主从复制与每日备份。Redis持久化策略要与业务容忍度对齐，先定RPO，再选机制。