Redis启动不加载RDB的首要原因是AOF优先级高于RDB：只要appendonly yes且AOF文件存在，即使RDB完好也会被跳过；其次可能因stop-writes-on-bgsave-error残留错误状态、RDB版本不兼容、maxmemory过小或vm.overcommit_memory=2导致加载失败。
Redis启动不加载RDB：先看AOF是否抢了优先权
Redis默认「有AOF就不用RDB」——哪怕RDB文件完好，只要appendonly yes且AOF文件存在（哪怕为空），它就会跳过RDB加载。这不是bug，是设计逻辑：AOF记录更细、恢复更全。
实操建议：
- 用
grep appendonly /etc/redis/redis.conf确认是否启用AOF；若值为yes，再查ls -l /var/lib/redis/appendonly.aof是否存在 - 若你明确想用RDB（比如刚从备份恢复完dump.rdb），临时关闭AOF：
redis-cli config set appendonly no，然后重启服务 - 注意：AOF文件损坏时Redis可能静默忽略，但RDB校验失败会直接报错退出——别误以为“没报错=加载成功”
RDB加载失败但无报错？检查stop-writes-on-bgsave-error是否间接阻断
这个配置项本意是“快照失败就禁止写入”，但它也会影响启动时的RDB加载行为：如果上次BGSAVE失败后残留了错误状态（如磁盘满、权限异常），Redis可能拒绝加载旧RDB并静默以空库启动。
实操建议：
- 查当前状态：
redis-cli config get stop-writes-on-bgsave-error，若返回yes，再看日志里是否有Can't save in background: fork: Cannot allocate memory这类线索 - 验证磁盘与内存：
df -h看dir路径所在分区，free -h看可用内存；fork失败在低内存VPS上极常见 - 临时绕过（仅调试）：
redis-cli config set stop-writes-on-bgsave-error no，再手动触发save，观察是否能生成新dump.rdb
版本不兼容：高版本生成的RDB，低版本Redis直接拒载
Redis 7.0+生成的RDB文件含新编码格式，6.x或更早版本解析时会卡在头部校验，现象是启动日志只显示Reading RDB file...后停住，无ERROR，但redis-cli dbsize返回0。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操建议：
- 两端比版本：
redis-server --version（服务端）和redis-cli INFO server | grep redis_version（客户端连上去查） - 不要靠“名字猜版本”：比如Debian源装的
redis-server可能是6.0，而手动编译的可能是7.2——必须实查 - 降级方案不是改配置，而是用同版本Redis导出数据：
redis-cli --rdb dump.rdb --pipe | redis-cli -h newhost -p 6379 --raw（需目标实例支持）
内存限制maxmemory设太小，导致RDB加载中途被OOM killer干掉
很多人只关注Redis运行时内存，却忘了RDB加载是“先解压再建结构”的过程，峰值内存可达RDB文件大小的2–3倍。若maxmemory设得接近物理内存，加载瞬间就触发OOM。
实操建议：
- 估算RDB大小：
ls -lh /var/lib/redis/dump.rdb，假设是500MB，则预留至少1.5GB空闲内存 - 临时放宽限制：
redis-cli config set maxmemory 0（禁用限制），再重启；生产环境应结合maxmemory-policy设为noeviction防误删 - 关键点：Linux的
/proc/sys/vm/overcommit_memory若为2（严格模式），即使maxmemory 0也可能因系统级overcommit拒绝fork——此时需调成1
真正难排查的，往往是多个条件叠加：比如AOF开启 + RDB版本高 + maxmemory卡死 + overcommit_memory=2。单独看每个配置都“合理”，合起来就启动失败。动手前，先用redis-server /etc/redis/redis.conf --test-memory跑个基础校验，比盲试快得多。
