Redis持久化配置的核心结论：生产环境优先开启AOF并设置appendfsync everysec，同时保留RDB快照用于快速备份，再通过混合持久化降低AOF文件体积，这在性能与数据安全之间最稳妥。
redis持久化配置怎么设置：先认清RDB和AOF的定位
Redis持久化配置主要围绕RDB快照和AOF日志展开，两者不是互斥关系,多数生产环境会同时开启。
- RDB：Redis Database Backup，把某个时间点的内存数据写成二进制文件dump.rdb。
- AOF：Append Only File，把每次写命令追加到appendonly.aof文件。
- 混合持久化：Redis 5.0后，AOF重写时先写RDB格式前缀，再追加增量命令，文件更小,恢复更快。
配置入口通常是redis.conf文件，也能用redis-cli动态修改，运行中的Redis用CONFIG SET改参数后，要执行CONFIG REWRITE写回配置文件,否则重启丢失。
redis rdb和aof持久化区别，生产环境怎么选
| 对比项 | RDB | AOF |
|---|---|---|
| 数据形态 | 二进制压缩快照 | 可读写的命令日志 |
| 触发方式 | save规则或手动BGSAVE | 每条写命令追加 |
| 文件体积 | 较小 | 通常较大，可重写压缩 |
| 恢复速度 | 快，直接加载 | 慢，逐条重放命令 |
| 数据丢失窗口 | 取决于save规则，可能几分钟 | everysec多数情况约1秒 |
| 磁盘写入 | 定期集中写 | 持续顺序写 |
行业共识认为，在线业务对数据丢失更敏感，AOF everysec更合适，RDB适合定期备份、迁移和快速恢复整库。
生产环境redis持久化配置的完整步骤
准备数据目录
先在redis.conf里确认dir路径，
dir /var/lib/redis
dbfilename dump.rdb
appendfilename "appendonly.aof"确保目录存在，且Redis进程有写权限,云服务器或本地部署都不要把数据目录放在临时目录或容器可写层。
开启RDB快照
默认配置通常已有：
save 900 1
save 300 10
save 60 10000含义是：900秒内有1次写操作、300秒内10次写操作、60秒内10000次写操作，任意满足就触发BGSAVE生成RDB，写入频繁的业务可以调大阈值，比如
save 3600 1000,减少频繁fork子进程。
开启AOF并设置刷盘策略
核心参数：
appendonly yes
appendfsync everysecappendfsync三个值：
- always：每次写命令都刷盘，数据最安全,性能下降较大。
- everysec：每秒刷盘一次，性能损失小,通常最多丢约1秒数据。
- no：交给操作系统调度，性能最好,但崩溃可能丢较多数据。
生产环境多数选择everysec，如果业务是金融对账类，数据不允许丢失，可考虑always,但要接受QPS下降。
开启混合持久化
aof-use-rdb-preamble yes这是Redis 5.0后的推荐配置，AOF重写时会把当前内存数据以RDB格式写入文件头部，之后增量命令继续用AOF格式追加，结果就是AOF文件更小,恢复速度接近RDB。
设置AOF重写参数
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb意思是AOF文件超过64MB，并且比上次重写后增长100%时，触发自动重写，目的是压缩AOF体积,避免无限膨胀。
动态生效与验证
如果不想重启,可以运行：
redis-cli CONFIG SET appendonly yes
redis-cli CONFIG SET appendfsync everysec
redis-cli CONFIG SET aof-use-rdb-preamble yes
redis-cli CONFIG REWRITE改完用INFO persistence确认状态。
Redis持久化配置参数详解：save与appendfsync如何取值
save参数
save后面跟两个数字，第一个是时间窗口秒数,第二个是修改次数阈值。
save 900 1：15分钟内有1次修改就生成RDB。save 300 10：5分钟内有10次修改就生成RDB。save 60 10000：1分钟内有10000次修改就生成RDB。
写入非常频繁的场景可以只保留一条低频规则,避免BGSAVE频繁导致CPU和内存压力。
appendfsync参数
- always：每次写命令追加后立刻fsync到磁盘，数据最稳，但磁盘IO压力大,QPS可能明显下降。
- everysec：Redis后台线程每秒执行一次fsync,性能与安全平衡。
- no：不主动fsync，完全交给操作系统,断电或崩溃可能丢失最近几秒到几十秒数据。
生产环境里appendfsync everysec是绝大多数部署的默认选择,也是云厂商托管Redis常用的策略。
AOF重写其他参数
auto-aof-rewrite-min-size：AOF文件达到该值后才可能自动重写,默认64MB。auto-aof-rewrite-percentage：AOF文件相对上次重写后增长的百分比,达到就触发重写。
重写由Redis后台子进程完成，期间主进程继续处理读写请求,对性能影响可控。
生产环境redis持久化配置性能影响与磁盘规划
磁盘类型建议
AOF everysec会每秒写一次盘，RDB定期写快照，两者都需要稳定的本地磁盘，建议使用SSD或云盘，避免使用NFS、网络文件系统或性能差的机械盘，国内云厂商的本地SSD实例通常能轻松应对,但自建时要关注云盘IOPS上限。
内存与fork的关系
RDB的BGSAVE通过fork子进程生成快照，Linux使用写时复制，fork瞬间不会真的复制整块内存，但生产环境仍需预留约1.5倍内存余量，如果Redis实例使用了几十GB内存，fork过程可能停顿数百毫秒，需要关闭透明大页,减少fork延迟。
磁盘空间估算
AOF文件大小与写入命令数量相关，不做重写时会持续增长，开启auto-aof-rewrite后，重写过程需要额外空间,保守估计预留当前AOF文件两倍大小的可用磁盘。
性能影响评估
- RDB：BGSAVE期间，主进程通常不阻塞读写,但fork和写盘会消耗CPU和IO。
- AOF everysec：每秒一次fsync，对吞吐影响较小,延迟毛刺不明显。
- AOF always：每次写命令都fsync，高并发下可能成为瓶颈,需要实测。
redis持久化数据恢复操作
启动加载顺序
Redis启动时，如果appendonly yes，优先加载AOF文件；AOF关闭或文件不存在，才加载RDB，因此同时开启两者时，恢复以AOF为准,RDB作为兜底备份。
恢复步骤
- 停掉Redis服务。
- 备份当前dump.rdb和appendonly.aof到其他目录。
- 把需要恢复的AOF或RDB文件拷贝回dir目录。
- 确认文件属主为Redis运行用户,权限正确。
-
启动Redis,观察日志加载情况。
- 执行
INFO persistence查看aof_loading或rdb_loading状态。
文件损坏处理
AOF尾部损坏时,用：
redis-check-aof --fix appendonly.aof该命令会截断不完整命令，可能丢失最后几条写入,但能恢复大部分数据。
RDB文件损坏时,用：
redis-check-rdb dump.rdb检查文件完整性,必要时从更早的备份文件恢复。
生产环境redis持久化配置常见排查命令
CONFIG GET appendonly：查看AOF是否开启。CONFIG GET appendfsync：查看刷盘策略。CONFIG GET save：查看RDB触发规则。INFO persistence：查看持久化运行状态，重点看aof_enabled、rdb_last_bgsave_status、aof_last_bgrewrite_status。redis-cli BGSAVE：手动触发RDB快照。redis-cli BGREWRITEAOF：手动触发AOF重写。
云上Redis托管实例一般已经配置好持久化，但用户看不到底层文件，自行部署时，要把数据目录挂载到持久化磁盘,容器重启后数据才不会丢。
生产环境redis持久化配置没有统一模板，但核心框架很清晰：开启AOF everysec，保留RDB快照，启用混合持久化，根据业务写入量调整save和重写参数,就能在性能与数据安全之间找到稳定点。
Q&A
redis持久化配置怎么验证是否生效？
运行redis-cli CONFIG GET appendonly，返回yes表示AOF已开启，再执行INFO persistence，查看aof_enabled为1、rdb_last_bgsave_status为ok,即可确认RDB和AOF都正常工作。
redis持久化配置后加载顺序是RDB还是AOF？
当appendonly设置为yes时，Redis启动优先加载AOF文件，只有AOF文件不存在或损坏时，才会尝试加载RDB文件,并且启动日志会给出相应提示。
生产环境redis持久化配置数据丢失窗口怎么计算？
AOF everysec模式下，写命令最多在内存缓冲区停留约1秒，因此多数情况下最多丢失约1秒数据，RDB模式下丢失窗口等于最近一次成功BGSAVE之后到故障发生的时间差,具体取决于save触发规则和写入频率。