redis aof 是将写命令追加到文件以实现持久化，但并非所有场景都适用：appendfsync 配置影响安全性与性能，everysec 是线上折中选择，always 性能差，no 不可靠；aof 重写可能耗资源，切换时需检查文件完整性、路径及时间戳。
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 <filename></filename>修复，它会删掉最后不完整的命令 - 数据少了一部分：检查
appendfilename是否指向正确路径，尤其 Docker 或 systemd 部署时容易挂载错目录，导致写进 /tmp 下的临时文件 - 时间回退：如果系统时间被手动改过，AOF 中的时间戳可能乱序，虽不影响命令执行，但排查问题时日志顺序失真
真正麻烦的是混合持久化开启后（aof-use-rdb-preamble yes），AOF 文件开头是 RDB 格式，后面才是命令流——这种格式没法用文本编辑器看，出问题只能靠 redis-check-aof 或重新 dump。
