Redis AOF持久化配置

1. 核心含义与作用

appendonly yes 用于开启 Redis 的 AOF（Append Only File）持久化模式：

• 默认值：appendonly no（关闭 AOF，默认仅开启 RDB）
• 核心逻辑：开启后，Redis 会将每一条写命令（如 set、hset、incr 等）以文本协议的形式追加到 AOF 文件中，而非仅依赖 RDB 的快照方式。
• 核心价值：相比 RDB 快照（可能丢失最后一次快照后的所有数据），AOF 能最大程度减少数据丢失（可通过 appendfsync 配置控制丢失数据的量级）。

2. 关键配套配置（完整示例）

仅开启 appendonly yes 还不够，通常需要搭配以下配置才能达到最优效果，这里给出生产环境常用的完整配置示例：

# 开启AOF持久化
appendonly yes

# AOF文件名称（默认：appendonly.aof）
appendfilename "appendonly.aof"

# 同步策略（核心，决定数据安全性与性能的平衡）
# 可选值：
# - always：每写一条命令就同步到磁盘，数据最安全，但性能损耗最大
# - everysec：每秒同步一次（推荐），最多丢失1秒数据，性能与安全兼顾
# - no：由操作系统决定同步时机，性能最好，但数据丢失风险最高
appendfsync everysec

# 开启AOF重写时是否临时关闭同步（避免重写期间性能下降）
no-appendfsync-on-rewrite yes

# AOF重写触发条件（避免文件过大）
# 当前AOF文件大小超过上一次重写后大小的100%，且文件大小至少64MB时触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# AOF文件损坏时的处理策略（yes：忽略错误继续启动，no：启动失败）
aof-load-truncated yes

3. 核心配置解释

• appendfsync everysec：生产环境最推荐的配置，既保证了性能，又将数据丢失控制在 1 秒内；
• AOF 重写：AOF 文件会随写命令不断增大，重写会将冗余命令合并（比如多次 incr 合并为 set），减小文件体积，且重写过程是异步的，不阻塞主进程；
• aof-load-truncated yes：如果 AOF 文件末尾因异常损坏，Redis 会忽略损坏部分并正常启动，避免因小部分损坏导致整个服务无法启动。

4. 使用场景与注意事项

适用场景

• 对数据丢失敏感的业务（如支付、交易、核心缓存）；
• 要求 “尽可能少丢数据”，而非仅接受快照级别的持久化。

注意事项

• 性能影响：AOF 会比纯 RDB 多一些磁盘 IO 开销，但 everysec 模式下影响极小，可忽略；
• 文件大小：开启重写配置后，无需担心 AOF 文件过大，Redis 会自动优化；
• 兼容 RDB：AOF 和 RDB 可同时开启，Redis 重启时会优先加载 AOF 文件（数据更完整）。

总结

1. appendonly yes 核心作用是开启 AOF 持久化，大幅提升数据可靠性，减少丢失风险；
2. 生产环境建议搭配 appendfsync everysec 使用，平衡性能与数据安全；
3. 务必开启 AOF 重写配置，避免文件体积无限增大。