在Redis中，有两种方法可以实现数据的持久化存储：AOF（只追加文件）和RDB（Redis数据库快照）。在生产环境中，通常会同时设置这两种选项，但许多开发者可能会提出以下疑问。
"AOF实时记录数据，RDB设置还有意义吗？" "反正AOF具有更高的恢复优先级，RDB不就没必要了吗？"
然而，在实际的生产环境中，RDB是绝对必要的。让我们看看其原因。
1. AOF文件可能会损坏
AOF记录所有更改，但存在文件损坏的风险。由于磁盘故障、运行时错误、文件错误移动等原因，AOF文件损坏后，可能会很难恢复。
redis-server --appendonly yes
当Redis重启时，如果AOF文件损坏，则可能无法恢复数据。在这种情况下，有RDB备份至少可以恢复部分数据。
✅ 如果只使用AOF而文件损坏了怎么办？ 数据丢失风险增加
✅ 如果有RDB呢？ 至少可以恢复部分数据
2. AOF恢复速度慢
AOF必须逐一重新执行所有更改进行恢复。数据越多，Redis重启时的恢复时间可能越长。
例如，如果AOF文件为2GB，Redis将执行数百万条SET命令。而RDB则只需加载转储文件，因此恢复速度要快得多。
✅ 如果只使用AOF呢？ 恢复时间可能会变长
✅ 如果同时使用RDB呢？ 可以更快恢复
3. RDB更适合备份和服务器迁移
在生产环境中备份数据时，AOF文件大且日志格式不易利用。而RDB则文件小且可以完整保留特定时点的数据，备份更为简便。
✔ RDB用于备份的例子：
cp /var/lib/redis/dump.rdb /backup/dump-2025-02-17.rdb
✔ 数据迁移到另一服务器的例子：
scp /var/lib/redis/dump.rdb new-server:/var/lib/redis/
✅ AOF数据越多，备份越困难
✅ RDB适合快速备份和恢复特定时点数据
4. 可以减轻磁盘I/O负担
AOF需要将所有更改记录到磁盘，因此磁盘I/O负担很大。而RDB则每固定周期仅保存一次，对磁盘的负载较小。
✅ 如果只使用AOF呢？ 磁盘负载可能增加
✅ 如果与RDB一起使用呢？ 可以优化性能
5. 在生产环境推荐的RDB + AOF设置
在生产环境中，建议以下设置。
# RDB快照设置 （在满足条件时将数据保存到磁盘）
# save <seconds> <changes> [<seconds> <changes> ...]
save 900 1 300 10 60 10000
# 如果在900秒（15分钟）内有超过1个键发生变化，或在300秒（5分钟）内有超过10个键变化，或在60秒（1分钟）内有超过10,000个键变化，则保存
# 启用AOF
appendonly yes
appendfsync everysec # 每秒记录到磁盘，实现性能与稳定性的平衡
# AOF文件大小自动优化（重写）
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
🔍 多个save条件将如何评估？
在Redis中，所有save条件以OR条件形式工作。也就是说，只要满足其中一个条件，快照就会被保存。
✔ 示例1：如果设置了save 900 1和save 60 10000 - 如果在900秒内发生超过1个键的更改，或在60秒内发生超过10,000个键的更改 - RDB快照将被保存。
✔ 示例2：如果添加了save 300 10条件 - 如果在300秒内发生超过10个键的更改，或在900秒内发生超过1个更改，或在60秒内发生超过10,000个更改 - RDB快照将被保存。
✅ 所有save选项均以OR条件评估
✅ 只要满足一个条件，RDB立即保存
结论：即使有AOF，RDB也是必需的
✅ 仅使用AOF无法完全保护数据
✅ 在AOF损坏的情况下，RDB承担最后的备份角色
✅ AOF恢复速度可能较慢，因此利用RDB可以快速恢复
✅ RDB有利于备份与服务器迁移
✅ 可以减轻磁盘I/O负担并优化性能
✅ save设置以OR条件工作，只要满足一个条件就会保存RDB
因此，在生产环境中，将RDB + AOF共同设置是最安全和最佳的方法。
通过右侧的搜索框搜索`Redis`！准备了与Redis相关的其他文章。
还可以查看包含AOF重写功能分析内容的上一篇文章。
댓글이 없습니다.