8.3.2 AOF日志机制与重写策略

AOF（Append Only File）通过记录写命令实现持久化，具备可读可审计、恢复粒度细的特点。开启后写入的命令会追加到日志文件 appendonly.aof，重启时按序重放。

原理草图（AOF写入与重写流程）

1. 开启与配置示例（含参数解释）#

编辑配置文件并重启服务：

# /etc/redis/redis.conf
appendonly yes                    # 开启AOF持久化
appendfilename "appendonly.aof"   # AOF文件名
appendfsync everysec              # 每秒fsync一次（默认推荐）
no-appendfsync-on-rewrite yes     # 重写时减少fsync，降低抖动

auto-aof-rewrite-percentage 100   # AOF大小相对上次重写增长100%触发
auto-aof-rewrite-min-size 64mb    # AOF最小达到64MB才允许触发重写

# 重启Redis（以systemd为例）
systemctl restart redis
systemctl status redis --no-pager

参数解释
- appendfsync always：每次写入都同步，最安全但性能最低
- appendfsync everysec：每秒同步一次，性能与安全均衡
- appendfsync no：由OS决定同步时机，性能高但风险大
- no-appendfsync-on-rewrite yes：重写期间避免双重fsync引起抖动

2. 手工触发AOF重写与验证#

# 触发重写
redis-cli bgrewriteaof

# 查看重写状态与AOF大小
redis-cli info persistence | egrep 'aof_rewrite_in_progress|aof_current_size|aof_base_size|aof_last_rewrite_time_sec'

预期效果
- aof_rewrite_in_progress:1 表示重写进行中
- 重写完成后 aof_current_size 明显小于重写前

3. AOF文件结构与恢复演示#

# 查看AOF日志内容（可读命令）
head -n 10 /var/lib/redis/appendonly.aof

# 停止服务后模拟损坏（仅演示）
systemctl stop redis
echo "BAD" >> /var/lib/redis/appendonly.aof

修复命令

# 修复损坏的AOF
redis-check-aof --fix /var/lib/redis/appendonly.aof

预期效果
- 修复工具输出“OK/Fixed”并截断损坏部分
- 重新启动后数据尽可能恢复

4. 性能影响与优化建议（含命令验证）#

# 观察磁盘与写入压力
iostat -x 1 5

# 观察AOF写入/重写状态
redis-cli info persistence

优化建议：
- 高写入场景优先 appendfsync everysec
- 磁盘I/O紧张时调高 auto-aof-rewrite-min-size，避免频繁重写
- 使用SSD或更快磁盘，降低重写期间延迟

5. 常见故障排查#

1）AOF重写失败
- 现象：aof_last_bgrewrite_status:err
- 排查命令：

df -h
ls -l /var/lib/redis/
tail -n 50 /var/log/redis/redis-server.log

处理：检查磁盘空间、权限、文件系统只读等问题

2）重写期间延迟升高
- 现象：客户端响应变慢
- 处理：调高重写阈值或开启 no-appendfsync-on-rewrite yes

6. 练习（可操作）#

开启AOF并设置 appendfsync everysec，观察 info persistence 输出变化。
手工触发 bgrewriteaof，记录重写前后 aof_current_size。
人工破坏AOF并使用 redis-check-aof --fix 修复，验证数据恢复情况。

7. AOF与RDB对比要点（简表）#

AOF：恢复更完整，但加载慢、文件大
RDB：加载快，但可能丢失最近数据
生产建议：配合混合持久化（见后续小节）兼顾速度与安全