Redis RDB 与 AOF 怎么取舍：线上重启时的数据恢复路径和风险

线上 Redis 重启后，数据能恢复到什么时间点，取决于实例最后完成的 RDB 快照、AOF 写入策略，以及启动时实际选择的持久化文件。RDB 更像某个时刻的快照，AOF 则记录写命令；因此选择时先看能接受多少数据回退，再看磁盘、恢复时长和运维复杂度。

需要较快恢复、能接受最近一次快照后的少量回退时，RDB 更直接；不能接受较大的写入丢失窗口时，应优先评估 AOF，并通过恢复演练验证结果，而不是只看配置文件。

一次线上重启，Redis 到底从哪里读回数据

排查重启恢复问题时，最容易误判的是把“配置里写过某个参数”和“当前实例实际使用哪种文件”当成一回事。可以先把恢复路径拆成三个节点：Redis 启动读取持久化文件，文件重建内存数据，应用再通过命令验证关键键。

下面这段 Go 代码只做检查，不修改 Redis。它把 INFO persistence 返回的文本按行解析为字段，重点查看 loading、rdb_last_save_time 和 aof_enabled。这些字段必须和观察到的实例状态一起解释，不能单独当成数据完整性证明。

package main

import (
    "context"
    "fmt"
    "strings"

    "github.com/redis/go-redis/v9"
)

func main() {
    ctx := context.Background()
    client := redis.NewClient(&redis.Options{Addr: "127.0.0.1:6379"})
    defer client.Close()

    info, err := client.Info(ctx, "persistence").Result()
    if err != nil {
        panic(err)
    }
    for _, line := range strings.Split(info, "\n") {
        if strings.HasPrefix(line, "loading:") ||
            strings.HasPrefix(line, "rdb_last_save_time:") ||
            strings.HasPrefix(line, "aof_enabled:") {
            fmt.Println(line)
        }
    }
}

这段程序的调用链是 main → client.Info → Redis 的 persistence 区域；返回文本再经过 strings.Split 和前缀判断，最后输出恢复判断所需的三个字段。若 loading:1，先等待加载完成再核对业务键；不要在加载期间把空结果当成数据丢失。

RDB 和 AOF 的恢复边界差在哪里

RDB 将内存数据写成快照，适合备份和快速装载。快照完成后到下一次快照前发生的写入，不会出现在这个快照里。AOF 则按策略把写命令追加到日志，重启时重放日志；appendfsync everysec 通常把刷盘节奏控制在秒级，但仍要把操作系统、磁盘和故障场景纳入演练。

选择不能只看“哪个更安全”。RDB 文件便于复制和归档，但恢复点由快照频率决定；AOF 的恢复点更细，却需要关注 AOF 重写、磁盘空间和重放时间。对缓存型业务，少量回退可能可接受；对订单、库存或任务状态，应该先定义不可接受的丢失窗口，再决定是否组合使用。

用一次隔离演练确认配置，而不是凭感觉切换

先在与生产版本一致的隔离实例执行 INFO persistence，记录 loading 变回 0 的时刻，再读取一组预先写入的关键键。RDB 场景要确认这些键是否存在于最近快照；AOF 场景还要确认追加写入在重启后是否被重放。演练时保留启动日志和持久化文件大小，便于解释差异。

如果使用 AOF，重点检查 appendonly yes、appendfsync everysec 与磁盘空间；如果使用 RDB，重点检查 save 规则、最近一次保存时间和快照文件是否来自预期实例。不要直接删除线上持久化文件来“验证”，这会把实验变成不可逆的故障。

常见问题：误区与回滚边界

只打开 AOF 就等于零丢失吗

不是。AOF 仍受刷盘策略、磁盘故障和重启时重放状态影响。应把“允许丢失的时间窗口”写进演练记录，并用关键键和业务计数做恢复前后对比。

RDB 文件越新，恢复就一定越快吗

不一定。快照新鲜度和文件大小、磁盘读速、实例内存压力都有关。正确做法是记录一次真实恢复耗时，不用未经测量的数字替代结果。

切换前要保留什么

保留配置快照、RDB/AOF 文件清单、启动日志和验证键列表；切换失败时先恢复原配置并使用原持久化文件启动隔离实例，再决定是否回到线上。

把选择落成一张恢复检查清单

先写清业务能接受的数据回退窗口，再确认当前持久化配置和文件，最后做一次隔离重启。RDB 适合快照、备份与相对简单的恢复路径；AOF 适合更细的写入记录，但必须配合磁盘、重写和重放验证。无论选择哪一种，真正可依赖的不是配置文本，而是最近一次成功的恢复演练。