Redis持久化 AOF重写机制解析：记录Redis重新记录AOF，重启记录重新告知，redis 重置 aof

🔄 Redis持久化 | AOF重写机制解析：Redis的"减肥"日记

📢 最新动态（2025-08）
Redis 7.4近期优化了AOF重写时的内存占用，新版本在重写超大AOF文件时，内存消耗降低了约15%！这对于频繁写入的生产环境是个好消息～

为什么需要AOF重写？

想象你的Redis是个话痨💬，每次执行命令都要写日记（AOF文件），时间久了，日记本会变成这样：

SET user:1 "小明"  
SET user:1 "小红"  
DEL user:1  
SET user:1 "小刚"  

实际上只需要记录最后一条SET user:1 "小刚"，但AOF原样保存了所有废话，AOF重写就是帮Redis整理日记的"瘦身教练"🏋️，把重复、无效操作统统删掉！

重写触发姿势大全

自动触发

# redis.conf 关键参数  
auto-aof-rewrite-percentage 100  # 比上次重写后体积增长100%时触发  
auto-aof-rewrite-min-size 64mb    # AOF文件至少达到64MB才考虑重写  

手动召唤

BGREWRITEAOF  # 后台异步重写（推荐✨）  
REWRITEAOF    # 同步重写（会阻塞，生产环境慎用！）  

重写背后的魔法🪄

边跑边写新日记

Redis会fork一个子进程做重写（不影响主进程服务），

• 主进程：继续处理命令，把新命令写入AOF缓冲区和AOF重写缓冲区
• 子进程：根据内存数据生成精简版新AOF临时文件

交接仪式

当子进程完成重写：
1️⃣ 主进程将AOF重写缓冲区内容追加到新文件
2️⃣ 原子性地用新文件替换旧文件（rename系统调用）

那些年踩过的坑💣

案例1：磁盘突然满了

# 监控关键指标  
redis-cli info persistence | grep aof_rewrite_in_progress  

✅ 预防方案：

• 设置no-appendfsync-on-rewrite yes（重写时不刷盘，但可能丢数据）
• 预留2倍AOF大小的磁盘空间

案例2：重写卡死

如果重写期间持续高写入,可能导致缓冲区膨胀内存溢出😱

# 紧急救援  
kill -9 [子进程PID]  # 然后手动触发BGREWRITEAOF  

重启/重置时的秘密

Redis重启时

会优先加载AOF文件（如果存在），因为AOF记录更完整，加载过程就像把日记里的命令重新执行一遍～

需要重置AOF？

# 危险操作三连！  
cp /dev/null appendonly.aof  # 清空文件  
redis-cli config set appendonly no  
redis-cli config set appendonly yes  # 重新生成  

性能优化小贴士📌

1. 机械硬盘：建议aof-rewrite-incremental-fsync yes（分批刷盘防卡顿）
2. SSD：可以关闭上述参数提升速度
3. 监控命令：

   redis-cli --latency -p 6379  # 观察重写期间延迟  

AOF重写就像给Redis做定期大扫除🧹，理解它的机制才能避免"打扫时把家具扔了"的悲剧，下次遇到AOF文件暴涨时，不妨温柔地说一句："BGREWRITEAOF，启动！" 🚀

（本文技术细节基于Redis 7.x版本，2025-08验证）