Redis重启后雪崩的根本原因不是未开启持久化，而是加载RDB/AOF后key虽存在但TTL已过期，首次访问仍穿透数据库；即使混合持久化启用，AOF重放慢、冷启动无预热，仍会导致雪崩。
为什么Redis重启后会雪崩，不是因为没持久化
Redis重启后雪崩，根本原因不是RDB或AOF没开，而是加载完持久化文件后，所有key的TTL已过期——这些key在内存里“存在”，但状态是expired，首次访问仍会穿透到数据库。即使你用redis-cli config get aof-use-rdb-preamble确认混合持久化开着、appendonly.aof也校验通过，只要没做缓存预热，流量一来照样打穿后端。
同时开RDB和AOF时，Redis根本不会“选”，它只认AOF文件
只要appendonly.aof文件存在且未被截断（或配置了aof-load-truncated yes），Redis启动时会直接忽略dump.rdb，全程只用AOF恢复。这不是可调选项，是硬编码逻辑。
- 好处：AOF数据更全，比RDB快照少丢几秒写入
- 风险：几十GB的AOF文件校验+重放可能卡住启动数分钟；而RDB加载通常秒级
- 应急手段：雪崩刚发生时，临时
mv appendonly.aof appendonly.aof.bak，让Redis退回到RDB模式快速拉起服务
auto-aof-rewrite-percentage和save规则冲突，会触发双重fork
这两个配置都依赖info persistence里的指标，但彼此无感知：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
save 60 10000满足后立即触发BGSAVE -
auto-aof-rewrite-percentage 100表示AOF体积翻倍就触发bgrewriteaof - 如果业务写入突增，60秒内既满足RDB条件又触发AOF重写，两个子进程并发
fork，内存页复制压力翻倍，主线程卡顿 - 验证是否踩坑：
redis-cli info stats | grep aof_delayed_fsync非零值说明fsync已延迟，AOF缓冲区堆积，主线程正在紧急同步
appendfsync everysec不是“每秒落盘”，它只是每秒调一次fsync()
appendfsync everysec把命令先写进内核page cache，再由主线程每秒调一次fsync()刷盘。实际耗时取决于磁盘响应——SSD通常20ms，但若连续几秒fsync()慢，AOF缓冲区（aof_buf）就会堆积，触发阻塞式同步，主线程停摆。
- 别盲目切
always：QPS直接腰斩，对高吞吐场景不可行 - 也别用
no：等于放弃数据安全底线，宕机大概率丢失最后几秒甚至几分钟数据 - 真正有效的缓解：给AOF文件单独挂SSD分区，并确保
vm.swappiness=1，避免page cache被swap挤出
最常被忽略的一点：持久化参数调得再细，只要没配合缓存预热或降级策略，重启后的“冷启动”阶段依然会雪崩。RDB/AOF解决的是“数据能不能回来”，而不是“回来的数据能不能立刻扛住流量”。
