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 延迟翻倍，却找不到原因。
