Redis的AOF持久化会把每一条写命令追加到文件末尾，重启时通过重放命令来恢复数据。文件一旦损坏，轻则丢失最后几条写操作，重则整个实例无法启动。遇到AOF损坏时不必急于清空数据文件，大多数情况下可以通过工具或手动方式修复，只损失文件尾部不完整的部分。

AOF文件的写入机制与损坏原因

AOF文件使用Redis自定义的RESP协议来序列化命令。每一条命令都以星号开头，接着是参数个数，然后每个参数用美元符号加长度前缀表示。比如执行一条SET foo bar命令，写入AOF的内容会是：

*3
$3
SET
$3
foo
$3
bar

由于AOF采用追加写方式，正常情况下文件末尾一定是完整的命令边界。但如果Redis在写入过程中遇到断电、磁盘空间不足、内核缓冲区异常、硬件故障或者人为编辑文件，就可能出现半条命令残留在文件末尾，或者命令中间被截断。rewrite过程中如果发生异常，也可能生成不完整的临时文件。另外，某些文件系统在崩溃后可能丢失最后一部分写操作，虽然Redis设置了aof-load-truncated参数来容忍尾部截断，但一旦截断位置不在命令边界上，Redis就无法解析后续内容。

理解这个机制很重要，因为修复的本质就是找到最后一个完整的、符合RESP协议的命令结束位置，然后把文件从这个位置截断，丢弃后面的非法内容。

使用redis-check-aof工具修复

Redis官方随安装包提供了redis-check-aof工具，它可以快速检查AOF文件的合法性，并且支持自动修复。检测文件是否损坏可以执行：

redis-check-aof appendonly.aof

如果文件正常，工具会输出AOF is valid。如果发现损坏，会提示在某个偏移量之后无法解析。此时可以使用fix选项进行修复：

redis-check-aof --fix appendonly.aof

工具会扫描整个文件，定位到最后一个完整的AOF命令边界，然后把后面的内容全部截断。这个过程对原始数据是只读的，不会破坏前面完整的命令。执行修复前仍然建议先备份原始文件，因为如果工具判断错误或者你希望对文件进行更精细的处理，备份是恢复的底线。修复完成后重新启动Redis，观察启动日志中是否出现AOF加载错误，同时检查数据量是否与预期一致。

需要注意，redis-check-aof工具在Redis 6及以上版本中默认与redis-server放在同一目录，早期版本可能需要单独安装redis-tools包。如果工具报告文件损坏但无法定位到偏移量，或者修复后数据丢失过多，就要考虑手动方式处理。

手动定位并裁剪损坏的AOF文件

当redis-check-aof无法满足需求时，可以手动解析AOF文件来找到最后一个完整命令的位置。原理是逐条读取RESP命令：读取第一个星号，获取参数个数，然后依次读取每个参数的长度并跳过相应字节。如果任何一个步骤无法完整获取，说明当前位置之后属于损坏部分，文件的合法内容到此为止。

下面是一个Python脚本示例，它会扫描AOF文件并输出最后一个合法偏移量，然后将文件截断到该位置。该脚本以二进制方式读取文件，避免编码问题。

import sys
def find_last_valid_offset(data):
    pos = 0
    last_valid = 0
    while pos < len(data):
        if data[pos:pos+1] != b'*':
            break
        line_end = data.find(b'\r\n', pos)
        if line_end == -1:
            break
        try:
            argc = int(data[pos+1:line_end])
        except ValueError:
            break
        pos = line_end + 2
        ok = True
        for _ in range(argc):
            if pos >= len(data) or data[pos:pos+1] != b'$':
                ok = False
                break
            line_end = data.find(b'\r\n', pos)
            if line_end == -1:
                ok = False
                break
            try:
                length = int(data[pos+1:line_end])
            except ValueError:
                ok = False
                break
            pos = line_end + 2
            if pos + length + 2 > len(data):
                ok = False
                break
            if data[pos+length:pos+length+2] != b'\r\n':
                ok = False
                break
            pos += length + 2
        if not ok:
            break
        last_valid = pos
    return last_valid
if __name__ == '__main__':
    if len(sys.argv) != 2:
        print('Usage: python fix_aof.py appendonly.aof')
        sys.exit(1)
    path = sys.argv[1]
    with open(path, 'rb') as f:
        data = f.read()
    offset = find_last_valid_offset(data)
    print('Last valid offset: %d, total size: %d' % (offset, len(data)))
    with open(path, 'wb') as f:
        f.write(data[:offset])
    print('Truncated file.')

使用该脚本前需要停止Redis写入并将AOF文件复制到独立目录。运行脚本后，再次用redis-check-aof验证文件是否合法。如果脚本输出的合法偏移量远远小于文件总大小，说明损坏部分较大，可能存在更深层次的问题，比如文件中部某个命令长度字段被篡改。此时不要盲目截断，最好结合Redis日志和操作记录判断数据丢失范围。

防止AOF损坏的配置与运维建议

修复只是事后手段，减少损坏概率需要从配置和运维两方面入手。Redis提供了appendfsync参数控制刷盘频率，设置为everysec可以在性能和数据安全之间取得平衡，避免每次写入都触发fsync带来的压力。同时开启no-appendfsync-on-rewrite yes可以在rewrite期间避免主进程同时执行fsync，降低磁盘I/O争用导致的写入失败概率。

对于尾部截断场景，可以启用aof-load-truncated yes，这样Redis在加载AOF时如果发现文件末尾不完整，会忽略并继续启动，只丢弃尾部无法解析的部分。但该配置对中部损坏无效，因此还需要配合磁盘空间监控、UPS不间断电源、使用可靠的文件系统等措施。定期做RDB快照并开启混合持久化也能在AOF严重损坏时提供恢复来源，毕竟混合持久化会把RDB数据嵌入到AOF文件开头，降低重放负担和损坏风险。

日常运维中建议把AOF文件纳入备份计划，同时避免在Redis运行期间直接编辑AOF文件。如果必须手动修改，应当先关闭Redis或切换到只读模式，修改后使用redis-check-aof验证合法性再启动实例。数据文件损坏并不可怕，可怕的是没有备份和没有验证流程，把恢复动作和预防机制结合起来，才能让Redis的数据持久化更可靠。