Redis实例重启后加载AOF慢，因纯AOF需顺序重放所有命令；启用RDB+AOF混合持久化（aof-use-rdb-preamble yes）可先快速加载RDB快照再重放少量增量命令，显著提速恢复。
Redis实例重启后加载AOF文件特别慢，是因为纯AOF模式在重放时必须顺序执行每条命令
纯AOF（appendonly yes 且 aof-use-rdb-preamble no）下，Redis启动时需逐行读取AOF文件、解析并执行所有写命令。哪怕只有10万条SET，也要模拟真实写入路径——走命令分发、键空间查找、过期判断、网络响应模拟（即使没客户端），这比直接加载二进制RDB快不了多少，反而更慢。
常见现象：Starting Redis server... 日志后卡住几十秒甚至数分钟，INFO persistence 中 loading:1 长时间不变成0，redis-cli info | grep -i "aof_current_size\|loading" 显示AOF体积大但进度不动。
- 典型诱因：高QPS业务用
appendfsync everysec生成的AOF文件碎片多、重复key多（如频繁更新同一key）、未定期重写（auto-aof-rewrite-percentage设置过大或被禁用） - 关键区别：RDB是内存快照，加载即反序列化；AOF是操作日志，加载=重放，不可跳过中间状态
- 注意：
bgrewriteaof本身不解决启动慢——它只影响下次AOF写入，旧AOF仍要全量重放
启用RDB+AOF混合持久化（aof-use-rdb-preamble yes）能大幅缩短恢复时间
开启后，BGREWRITEAOF生成的新AOF文件头部是紧凑RDB格式，后面才是增量AOF命令。Redis启动时先用RDB方式快速加载头部快照（毫秒级），再重放尾部少量增量命令（通常几百~几千条），整体耗时从分钟级降到秒级。
实操要点：
- 必须同时开启RDB和AOF：
save ""可禁用定时RDB，但不能关掉RDB能力（即不能删掉dbfilename和dir配置） - 确认AOF重写已实际触发：改完配置后手动执行
redis-cli bgrewriteaof，观察INFO persistence中aof_rewrite_in_progress:0变为1再回0，且新AOF文件大小明显小于旧文件 - 检查生成的AOF文件是否含RDB preamble：用
head -c 100 /var/lib/redis/appendonly.aof | hexdump -C，开头应出现REDIS0011（RDB魔数），而非纯文本*2\r\n$6\r\nSELECT\r\n - 兼容性注意：该特性要求Redis ≥ 4.0，低于此版本无法识别混合格式，启动会报错
Wrong signature trying to load DB from file
禁用纯AOF模式前，务必清理残留旧AOF并验证配置生效
仅修改aof-use-rdb-preamble yes 不够——Redis仍会继续追加到现有纯AOF文件，下次重启还是得全量重放。必须让系统切换到新格式的AOF文件。
- 安全做法：停机窗口内，先
redis-cli shutdown save触发一次RDB落盘，再删掉旧appendonly.aof，最后用redis-server /etc/redis.conf启动，它会自动创建带preamble的新AOF - 在线做法（不推荐用于核心集群）：确保
auto-aof-rewrite-percentage足够低（如100），等BGREWRITEAOF自动生成新文件后，用redis-cli config set appendfilename "appendonly.aof.new"切换文件名，再config rewrite持久化，最后人工替换+重启 - 验证陷阱：
CONFIG GET aof-use-rdb-preamble返回yes≠ 生效，必须确认INFO中aof_enabled:1且aof_rewrite_in_progress:0时，新AOF文件已生成且含RDB头
混合持久化不是银弹：小key高频更新场景下RDB部分仍可能膨胀
RDB preamble本质是最后一次AOF重写时刻的全量快照。如果业务存在大量短生命周期key（如session、临时token），而AOF重写间隔长（auto-aof-rewrite-min-size 设得太大），RDB部分就会包含大量已过期或已被删除的key，导致快照体积虚高，加载变慢。
此时需权衡：
- 调低
auto-aof-rewrite-min-size（如从64mb改为16mb），增加重写频率，让RDB更“新鲜” - 避免在AOF重写期间做大批量DEL（会把已删key又写进RDB），可改用
SCAN + UNLINK异步清理 - 监控指标重点看
aof_base_size（RDB部分大小）和aof_pending_bio_fsync（写盘延迟），而非只盯总AOF体积
真正卡住恢复速度的，往往不是AOF本身，而是你以为切了混合模式就万事大吉，却忘了旧文件还在被追加、新文件没真正接管、或者RDB快照里塞了一堆早该消失的幽灵key。
