Redis如何开启AOF持久化记录写操作

Redis的AOF持久化虽能通过追加写命令实现数据恢复，但其安全性与性能高度依赖appendfsync配置（everysec为线上推荐折中方案，always牺牲性能，no则极不可靠），且易受重写资源消耗、文件完整性、路径挂载错误及系统时间异常等多重因素影响；开启前须显式配置appendonly yes、避免RDB全关，并在切换或重写时严格校验文件状态与环境一致性，否则不仅无法保障数据不丢，反而可能引发启动失败、数据缺失或磁盘空间暴增等问题。

Redis AOF 是什么，为什么不是所有场景都该开

AOF（Append Only File）本质是把每个写命令原样记进文件，重启时重放这些命令来恢复数据。它不等于“更安全”——如果 appendfsync 设成 no，可能丢一整秒操作；设成 always，吞吐直接掉 30% 以上，尤其小包高频写时磁盘 I/O 成瓶颈。

常见误判：以为开了 AOF 就不会丢数据。实际 Redis 进程崩溃但系统没崩，AOF 文件还在；可如果整个机器断电且 appendfsync 是 everysec，最后一秒的缓冲区就没了。

• appendonly yes 必须显式开启，配置默认是 no，改完要 redis-cli config rewrite 或重启才生效
• 不要和 RDB 同时关——否则实例重启即空库；建议至少保留 RDB 做冷备快照
• AOF 重写（bgrewriteaof）期间仍持续追加，重写完成前旧文件不删，磁盘空间可能翻倍

怎么配 appendfsync 才不拖慢服务又不太丢数据

这个参数决定命令写入磁盘的时机，只有三个合法值：always、everysec、no。线上几乎只用 everysec——它让主线程把命令写进内核缓冲区后立即返回，后台线程每秒刷一次盘。

• always：每次写都 fsync()，延迟高、磁盘寿命短，仅限金融级强一致场景（比如账务流水必须 100% 不丢）
• everysec：折中选择，实测单节点 QPS 5w+ 时延迟波动在 0.2–0.8ms，丢失窗口 ≤1 秒
• no：全靠系统调度刷盘，不可控，连 everysec 的兜底都没有，生产环境禁用

注意：everysec 模式下若 Redis 进程 crash，未刷盘的缓冲区命令会丢失；但如果是系统级 crash，只要内核缓冲区还没被覆盖，仍有概率 recover。

AOF 重写卡住或生成超大文件？检查这几个点

重写过程本身不阻塞读写，但若触发条件太松或 key 太多，会导致重写耗时长、临时文件爆炸。典型表现是 redis-cli info persistence 中 aof_rewrite_in_progress 长时间为 1，aof_current_size 突增数倍。

• 确认触发阈值是否合理：auto-aof-rewrite-percentage 100 表示当前 AOF 比上次重写后大一倍才触发，auto-aof-rewrite-min-size 64mb 是最小触发体积，小实例建议调低到 16mb
• 避免在流量高峰手动执行 bgrewriteaof，它会复制当前数据集状态，内存占用瞬时 +100%
• 如果 key 数量超千万且大量过期，AOF 重写会逐个序列化存活 key，比 RDB 更慢；此时应考虑分片或定期 redis-cli --bigkeys 清理冗余结构

从 RDB 切换到 AOF 后数据对不上？重点查这三处

切换不是改个配置就完事。Redis 启动时优先加载 AOF（如果存在且开启），否则才加载 RDB。但很多人忽略了 AOF 文件可能损坏、不完整，或重写中途失败残留了半截文件。

• 启动报错 Unexpected EOF reading the append only file：说明 AOF 文件末尾损坏，用 redis-check-aof --fix 修复，它会删掉最后不完整的命令
• 数据少了一部分：检查 appendfilename 是否指向正确路径，尤其 Docker 或 systemd 部署时容易挂载错目录，导致写进 /tmp 下的临时文件
• 时间回退：如果系统时间被手动改过，AOF 中的时间戳可能乱序，虽不影响命令执行，但排查问题时日志顺序失真

真正麻烦的是混合持久化开启后（aof-use-rdb-preamble yes），AOF 文件开头是 RDB 格式，后面才是命令流——这种格式没法用文本编辑器看，出问题只能靠 redis-check-aof 或重新 dump。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于数据库的相关知识，也可关注golang学习网公众号。