Redis AOF重写机制通过语义压缩保留每个键最新命令、剔除冗余操作，由子进程后台生成新文件并原子替换，支持混合持久化进一步减小体积，配合自动阈值策略控制触发时机。
Redis AOF 重写机制通过“用最终状态替代过程记录”的方式压缩日志体积，不是简单删减，而是重建——只保留每个键当前有效的最新命令，剔除中间冗余操作。
用最终值覆盖多次变更
AOF 原始日志忠实记录所有写操作，比如连续执行：
- SET user:name "Alice"
- SET user:name "Bob"
- SET user:name "Charlie"
重写后只生成一条：SET user:name "Charlie"。同理，INCR counter 执行 100 次，重写后等价于 SET counter 100。这种基于内存快照的“语义压缩”，让文件体积趋近于当前数据集的实际大小，而非操作历史总和。
后台非阻塞生成新文件
重写由子进程（bgrewriteaof）在后台完成，主进程持续服务：
- 子进程读取当前数据库全部键值，按统一格式（如 RESP）生成最小命令集写入临时 AOF 文件
- 主进程将重写期间的新写入命令缓存在
aof_rewrite_buffer中 - 重写完成后，Redis 原子替换旧 AOF 文件，并把缓冲区命令追加到新文件末尾
这种方式确保不丢数据、不阻塞请求，也避免了直接编辑原文件可能引发的损坏风险。
配合混合持久化进一步瘦身
启用 aof-use-rdb-preamble yes 后，重写不再纯文本输出，而是：
- 先写入一个紧凑的 RDB 格式二进制快照（含所有键值及过期时间）
- 再追加重写期间产生的增量 AOF 命令
RDB 部分比等效文本命令小得多，尤其对字符串、哈希等结构效果显著。实测大实例下，AOF 文件体积可减少 40%–70%，恢复速度也明显提升。
靠自动策略持续控量
仅靠手动触发不够，需配置自动重写阈值：
-
auto-aof-rewrite-percentage 100：当前 AOF 大小比上一次重写后增长 100% 时触发 -
auto-aof-rewrite-min-size 64mb：防止小文件频繁重写，设最低触发门槛
建议根据业务写入节奏调整，例如高写入场景可设为 50 和 128mb，兼顾及时性与资源开销。
