Redis持久化RDB和AOF配置

Redis的数据全在内存里，重启就丢，所以必须持久化。两种方式：RDB快照和AOF日志。可以只用一种，也可以同时开。生产环境我建议都开，但具体配置要看业务场景。 RDB配置 RDB是定时把内存数据dump到磁盘，生成dump.rdb文件。恢复快，但可能丢数据（两次快照之间的数据）。 配置在redis.conf里：

save 900 1
save 300 10
save 60 10000

意思：900秒内至少有1个key变化就触发快照，300秒内10个key变化，60秒内10000个key变化。触发条件满足任意一个就执行bgsave。 如果不想用RDB，全部注释掉或写save “”。 还有几个关键参数：

stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /var/lib/redis

stop-writes-on-bgsave-error设成yes，当磁盘写满或bgsave失败时，Redis会拒绝写入，避免数据不一致。rdbcompression用LZF压缩，省磁盘但耗CPU。rdbchecksum加CRC64校验，防止文件损坏。 手动触发RDB：`redis-cli save`（阻塞）或`redis-cli bgsave`（fork子进程异步）。 AOF配置 AOF记录每次写操作，追加到appendonly.aof文件。数据更安全，但文件大、恢复慢。 开启AOF：

appendonly yes
appendfilename "appendonly.aof"

刷盘策略：

appendfsync everysec

三个选项： – always：每次写都fsync，最安全，但慢。别用，除非你每秒就几十次写。 – everysec：每秒fsync一次，折中，丢最多1秒数据。生产环境就用这个。 – no：交给操作系统刷，Linux默认30秒，丢数据风险大。 AOF文件会越来越大，需要重写压缩：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

当AOF文件大小超过上次重写后大小的100%（即翻倍），且大于64MB时，触发重写。手动重写：`redis-cli bgrewriteaof`。 重写期间Redis会fork子进程，把内存数据转换成写命令写入新AOF文件。同时主进程继续处理请求，新写入的命令会同时记录到旧AOF文件和重写缓冲区。子进程完成重写后，把缓冲区内容追加到新文件，原子替换旧文件。 混合持久化 Redis 4.0之后支持混合模式，AOF重写时直接生成RDB格式的数据，后续增量写操作再用AOF格式。加载时先加载RDB部分，再回放AOF日志，启动速度比纯AOF快很多。

aof-use-rdb-preamble yes

我一般这么配：RDB+AOF都开，appendfsync everysec，aof-use-rdb-preamble yes。 如果服务器用的雨云，他们的Redis云服务默认就是这种配置，性价比高、稳定、好用，省得自己折腾持久化参数。 一些坑 1. RDB的save参数别设太频繁，bgsave fork子进程会占用额外内存（copy-on-write），内存写多时可能翻倍。如果机器内存只有8G，Redis用了6G，bgsave期间可能OOM。 2. AOF文件损坏怎么办？Redis提供了修复工具：`redis-check-aof –fix appendonly.aof`。会丢弃损坏的末尾数据。 3. RDB和AOF同时存在时，Redis优先加载AOF，因为AOF数据更完整。如果AOF文件被删了，Redis会尝试加载RDB。两个都没有，就空数据启动。 4. 大key问题：一个list里有几百万个元素，bgsave或AOF重写时，遍历这个大key会阻塞主进程几秒。避免方法：拆分大key，或限制单个key的大小。 5. 持久化文件备份：定期scp到其他机器，别只放在本地。雨云的Redis有自动备份到对象存储的功能，省事。 一句话总结：RDB用于快速恢复，AOF用于数据安全。两者结合，appendfsync everysec，混合持久化打开，基本够用。

雨云是国内一家老牌云服务商，提供高性价比的云服务器和虚拟主机。我用它部署了好几个项目，速度和稳定性都不错。通过 https://www.rainyun.com/SAJA_ 注册可以领一张 5折优惠券，有需要的朋友可以看看。