redis宕机主因是持久化执行失败：rdb fork失败（如vm.overcommit_memory=0致内存预估不足）或aof写入阻塞（如磁盘满、i/o延迟高、文件损坏），而非配置语法错误；需检查系统资源、磁盘状态及内核参数。
Redis 因持久化失败而宕机，核心原因通常是 RDB fork 失败或 AOF 写入阻塞，不是配置写错了，而是系统资源或磁盘状态不满足持久化执行条件。
redis-server 启动失败并报 FATAL CONFIG FILE ERROR 或直接退出
这不是配置语法错误，而是 Redis 在尝试加载 RDB/AOF 文件时校验失败或读取异常。常见于：
- 手动替换
dump.rdb或appendonly.aof后权限不对（如属主不是 redis 用户） - AOF 文件末尾损坏（比如断电导致 write 未 flush 完毕）
- RDB 文件被截断（
cp过程中被中断，或磁盘满后写入失败）
验证方式：redis-check-rdb dump.rdb 或 redis-check-aof --fix appendonly.aof。若校验失败，且无备份，只能清空数据目录重启（丢失最后一次持久化之后的数据）。
日志里反复出现 Can't save in background: fork: Cannot allocate memory
这是最典型的“假内存够、真 fork 不了”问题。Linux 的 vm.overcommit_memory 默认为 0，内核在 fork 前会预估子进程所需虚拟内存（≈ 当前 Redis 内存占用），若物理内存 + swap 不足该估算值，fork 就失败 —— 即使 free -m 显示还有 2GB 空闲。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 查当前值：
cat /proc/sys/vm/overcommit_memory - 临时修复：
echo 1 | sudo tee /proc/sys/vm/overcommit_memory（允许 overcommit） - 永久生效：在
/etc/sysctl.conf加vm.overcommit_memory = 1，再sysctl -p - 注意：设为 1 后需确保
maxmemory已严格配置，否则 OOM killer 可能干掉 redis 进程
启用 AOF 后 Redis 启动卡住、CPU 100%、日志无输出
这通常发生在 AOF 文件极大（几 GB）、且启用了 aof-rewrite-incremental-fsync yes 但磁盘 I/O 极差的场景。Redis 在加载 AOF 时是单线程顺序重放命令，遇到超大文件 + 慢盘，可能卡住数分钟甚至触发 systemd 超时 kill。
- 先用
strace -p $(pgrep redis-server)看是否卡在read()系统调用 - 紧急恢复：停服务 → 备份原 AOF → 用
redis-check-aof --fix截断损坏部分 → 若仍过大，考虑关闭 AOF，仅靠 RDB 恢复（需确认 RDB 时间点可接受） - 长期规避：控制 AOF 重写频率（
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size），并确保dir所在磁盘不与数据库共用、无 RAID5 延迟
INFO persistence 显示 rdb_bgsave_in_progress:1 却长时间不结束
说明 bgsave 卡在 fork 后的写盘阶段，常见于：
- 磁盘满（
df -h看dir所在分区） - 磁盘 I/O 队列堆积（
iostat -x 1看%util是否持续 100%，await是否 >100ms） - 使用了机械盘且启用了
save配置项（如save 60 10000），每次 save 都会阻塞主线程
此时 Redis 仍可响应请求，但延迟飙升；若连续多次 bgsave 失败，Redis 可能拒绝写入（取决于 stop-writes-on-bgsave-error yes）。优先清理磁盘空间，再检查 I/O 路径瓶颈 —— 容器环境尤其注意 overlay2 存储驱动在高 write 场景下的性能衰减。
持久化异常的根因往往不在 Redis 配置本身，而在它运行的 Linux 环境细节：内存 overcommit 策略、磁盘健康度、I/O 调度器、容器存储驱动。排查时别只盯着 redis.conf，/proc/sys/vm/ 和 iostat 的输出更关键。
