Redis AOF持久化原理是什么_详解Append模式下的日志写入流程

大家好，今天本人给大家带来文章《Redis AOF持久化原理是什么_详解Append模式下的日志写入流程》，文中内容主要涉及到，如果你对数据库方面的知识点感兴趣，那就请各位朋友继续看下去吧~希望能真正帮到你们，谢谢！

AOF本质是只追加不修改的文本日志，通过重放命令恢复数据；appendfsync决定落盘策略，everysec为生产默认；SELECT因影响命令作用域被记录；BGREWRITEAOF基于内存快照重生成最小日志；no-appendfsync-on-rewrite可缓解重写时I/O竞争。

AOF 的本质就是“只追加不修改”的文本日志，不是备份快照，而是重放操作——只要 Redis 还在执行写命令，AOF 就会把它们一条条记下来，重启时再按顺序跑一遍。

appendfsync 配置决定数据是否真落盘

AOF 文件里有命令不等于安全。真正决定“断电后能不能找回数据”的，是 appendfsync 的取值：

• always：每次写命令都调用 fsync()，数据最安全，但性能暴跌，基本不用
• everysec（默认）：命令先写进内核缓冲区，每秒刷一次盘；宕机最多丢 1 秒数据，是生产环境事实标准
• no：完全交由操作系统决定何时刷盘（Linux 默认约 30 秒），速度快但风险高，仅测试可用

注意：everysec 下的“1 秒丢失”是指 fsync 延迟，不是命令未写入 AOF 缓冲区——命令进缓冲区是立即完成的，只是没立刻落盘。

为什么 AOF 文件里能看到 SELECT 命令

AOF 记录的是客户端发来的原始协议流（RESP），不是语义过滤后的“有效写操作”。SELECT 虽然不改数据，但它切换了数据库上下文，影响后续所有命令的作用域，所以必须记录。

比如这段内容在 appendonly.aof 里很常见：

*2
$6
SELECT
$1
0
*3
$3
SET
$3
key
$5
value

如果你用 redis-cli --pipe 向 Redis 导入 AOF 文件，它会忠实执行每一行，包括 SELECT。跳过它，SET 可能写到错误的 db 中。

BGREWRITEAOF 不读旧 AOF 文件，而是看内存

AOF 重写不是“压缩日志”，而是“重生成最小等效日志”。子进程 fork 后，直接遍历当前内存中的 dict 和 expires 字典，为每个 key 生成一条最终状态命令。

• 反复 SET k v1 → SET k v2 → SET k v3，重写后只剩 SET k v3
• DEL k 之后的 key，在内存中已不存在，重写结果里彻底消失
• 带过期时间的 key，如果已过期，也不会出现在重写结果中

所以重写触发条件（auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size）只看文件体积，和内存状态无关；但重写结果只反映那一刻的内存快照。

no-appendfsync-on-rewrite 开关容易被忽略

当 BGREWRITEAOF 或 SAVE 执行时，主线程仍在接收新写请求。此时若继续按 everysec 执行 fsync，可能因磁盘 I/O 竞争导致延迟飙升。

no-appendfsync-on-rewrite yes 的作用是：重写期间暂停主线程的 fsync，新命令仍写入 AOF 缓冲区，等重写结束再统一刷盘。

这个配置默认是 no，但高并发写场景下建议设为 yes——否则你可能在重写时突然看到 P99 延迟翻倍，却找不到原因。

今天关于《Redis AOF持久化原理是什么_详解Append模式下的日志写入流程》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！