启动时的加载顺序
实例启动后按固定优先级挑选恢复来源：appendonly 为 yes 且 AOF 文件存在时加载 AOF，因为它的数据更接近最新；否则加载 dir/dbfilename 指向的 RDB 快照；两份都不存在则以空库启动。要注意「文件在不在」和「实际加载了哪一份」是两件事：开启 AOF 之后 RDB 仍然会继续生成，但启动时并不会被优先读取。判断当前数据来自哪里，最直接的办法是看启动日志那一行。
基本信息
| 优先级一 | appendonly yes 且 AOF 文件可用时加载 AOF |
|---|---|
| 优先级二 | AOF 不可用时加载 dir 目录下的 RDB 快照 |
| 都不存在 | 以空库启动，DBSIZE 为 0，只记录日志不报错 |
| 日志判据 | DB loaded from append only file / DB loaded from disk |
| 加载过程 | 由主线程完成，期间不能处理任何命令 |
| 耗时因素 | 键数量、单值体积、maxmemory 与磁盘速度共同决定启动时长 |
典型使用场景
- 数据迁移与克隆：把快照文件放到目标实例的 dir 下启动，快速得到一份数据副本
- 恢复演练：在隔离环境用备份文件启动，验证备份可用并量化加载耗时
- 排查数据变少：先确认加载来源与加载结果，再怀疑业务写入逻辑
- 版本升级预演：用同一份数据在新版本上加载，提前暴露格式兼容问题
- 评估停机窗口：按实测加载时间安排维护窗口与健康检查宽限期
确认加载来源与结果
确认加载来源与结果
redis-cli CONFIG GET appendonly # 先确认 AOF 是否开启
redis-cli CONFIG GET dir # 数据目录，快照与 AOF 都在这里找
redis-cli INFO persistence | grep -E '^loading|aof_enabled|aof_last_bgrewrite_status'
redis-cli DBSIZE # 加载后的键数量
redis-cli INFO keyspace # 分库键数量与过期情况
sudo tail -n 100 /var/log/redis/redis-server.log | grep -iE 'DB loaded|loading|Wrong signature|Bad file format'加载来源判定
| 启动条件 | 加载来源 | 说明 |
|---|---|---|
| appendonly yes 且 AOF 可用 | AOF | 数据最接近最新，重写前文件体积可能明显大于 RDB |
| appendonly no 且 RDB 存在 | RDB | 快照时刻的全量数据，之后的写入已丢失 |
| 两者都不存在 | 空库 | 首次启动的正常表现，需确认不是目录或权限写错 |
| 文件损坏 | 启动失败 | 进程直接退出并打印格式错误，需先修复文件再看日志 |
| AOF 开启但文件缺失 | 按版本而异 | 不同大版本处理方式不同，必须以该版本的启动日志为准 |
加载是单线程同步完成的，大实例可能持续几十秒到几分钟。这段时间里端口已经监听，客户端能连上但命令会一直等待，健康检查若只判断端口连通就会误判为「已就绪」。滚动重启时要么调长探针的超时与失败阈值，要么在应用侧等 INFO 里的 loading 变为 0。
在 appendonly yes 的实例上把旧的 dump.rdb 覆盖进 dir 目录，并不会改变启动后看到的数据库：AOF 优先级更高，数据依旧来自 AOF。迁移数据前先确认 appendonly 状态、aof 文件实际位置，否则很容易得出「文件换了数据没变」的结论。