Redis重启加载慢的根本原因是纯AOF需逐条重放命令、无法跳过中间状态；唯一有效优化是启用RDB+AOF混合持久化（aof-use-rdb-preamble yes），或从库彻底禁用本地持久化。
Redis重启后加载慢，核心不是IO带宽或CPU不够，而是纯AOF重放路径无法跳过中间状态——必须逐条执行命令。真正有效的优化只有两条路：切换到RDB+AOF混合持久化，或让从库彻底跳过加载。
为什么纯AOF模式重启必然慢
纯AOF（appendonly yes 且 aof-use-rdb-preamble no）启动时，Redis不是“读文件”，而是“重放日志”：每行*2\r\n$6\r\nSELECT\r\n都要走完整命令解析、键查找、过期判断、响应模拟流程。哪怕只是10万次SET，也得模拟真实写入路径，无法并行，也无法跳过重复key的中间状态。
常见现象包括：INFO persistence中loading:1卡住几十秒以上；redis-cli info | grep -i "aof_current_size"显示AOF文件达GB级但进度不动；日志停留在Starting Redis server后长时间无后续。
- 这不是磁盘慢，是设计使然：RDB是反序列化，AOF是重放，二者不可等价替换
-
bgrewriteaof只影响下次写入，对当前旧AOF文件无效 - 即使开了
io-threads，它只加速网络读写，不参与AOF重放过程
启用RDB+AOF混合持久化（Redis ≥ 4.0）
这是主库场景下最直接有效的方案：让AOF文件开头嵌入RDB快照，尾部只存增量命令。启动时先毫秒级加载RDB部分，再重放最后几百~几千条命令。
必须同时满足三个条件才能生效：
-
appendonly yes—— AOF必须开启 -
save ""或保留至少一条save规则（如save 900 1）—— RDB能力不能被禁用 -
aof-use-rdb-preamble yes—— 显式启用混合格式
改完配置后，必须手动触发一次重写：redis-cli bgrewriteaof，并确认INFO persistence中aof_rewrite_in_progress完成、新AOF文件生成。用head -c 100 /var/lib/redis/appendonly.aof | hexdump -C验证开头是否为REDIS0011魔数，而非纯文本*2\r\n。
注意：CONFIG REWRITE不会清理旧AOF文件，残留的纯AOF仍会被加载——务必手动rm appendonly.aof再重启。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
从库启动慢？直接禁用所有本地持久化
从库不需要RDB或AOF，加载它们纯属冗余。只要存在dump.rdb或appendonly.aof，启动就会阻塞主线程加载，哪怕配置里写了save ""。
正确关闭方式是三步清零：
-
save ""—— 清空自动RDB规则 -
appendonly no—— 关闭AOF功能本身（不是appendfsync no） -
auto-aof-rewrite-percentage 0—— 防止后台重写意外激活AOF
启动前必须手动清理：rm dump.rdb appendonly.aof temp-*.rdb。容器部署时尤其注意挂载配置是否覆盖了默认值。验证方法：config get save返回空字符串，config get appendonly返回no。
别碰多线程IO来加速启动
io-threads对启动加载完全无效。Redis 6.0+的多线程仅用于客户端连接的网络读写，而AOF重放、RDB加载、复制同步等关键路径仍是单线程主线程执行。试图调高io-threads只会增加上下文切换开销，毫无收益。
真正影响启动体验的，是fork()耗时（尤其大内存+THP开启时），以及AOF文件是否含RDB preamble。前者靠关THP和升级内核缓解，后者靠bgrewriteaof强制刷新文件格式。
最容易被忽略的是：混合模式下，RDB preamble不保存毫秒级过期精度（降级为PEXPIREAT），若业务强依赖精确TTL，需权衡是否启用。
