Redis 作为内存数据库，在高并发场景下常因持久化、集群通信和客户端连接等问题触发报错。本文按故障类型梳理常见报错现象、排查思路与处理方案，供运维人员参考。文中涉及的命令均为 Redis 自带工具，具体参数请结合自身版本确认。

一、持久化相关报错

1. RDB 持久化失败

典型日志：“Background saving error”、“Can't save in background: fork: Cannot allocate memory”。

• 内存不足导致 fork 失败：检查系统可用内存与 vm.overcommit_memory 设置。若内存余量不足以完成写时复制，fork 会直接失败。可通过降低实例内存占用或将 vm.overcommit_memory 设为 1 缓解。
• 磁盘空间或权限问题：确认 dir 目录剩余空间、目录属主，以及 dbfilename 是否可写。日志中若出现 “Permission denied” 或 “No space left on device” 应优先处理。
• SAVE 阻塞风险：避免在生产环境手动执行 SAVE，它会阻塞主线程；使用 BGSAVE 或依赖自动触发。

2. AOF 相关报错

典型日志：“Bad file format reading the append only file”、“Unexpected end of file reading the append only file”、“Can't open the append-only file”。

1. 进程异常退出或磁盘写满可能导致 AOF 文件尾部截断。可用 redis-check-aof --fix 修复，修复前务必备份原文件。
2. 确认 appendonly、appendfilename、appenddirname（视版本而定）配置与磁盘路径一致。
3. AOF 重写期间若出现 aof_rewrite_in_progress 长期为 1，检查子进程是否被系统 OOM Killer 终止。
4. 混合持久化下，注意 RDB 与 AOF 文件同时损坏时的恢复顺序，优先使用完整度更高的备份。

二、集群相关报错

1. 集群状态异常

典型报错：“CLUSTERDOWN The cluster is down”、“Cluster state changed”。

• 使用 redis-cli --cluster check 查看槽位覆盖、节点握手与副本关系。
• 确认 cluster-node-timeout 与网络抖动情况。超时过小会导致频繁误判主节点下线，过大则故障切换迟缓。
• 若部分槽位无人负责，可执行 redis-cli --cluster fix 重新分配，但需评估数据迁移影响。

2. 主从切换与副本报错

典型日志：“MASTER <-> REPLICA link status changed”、“Failover auth denied”。

1. 检查 cluster-require-full-coverage 设置。设为 yes 时，任一槽位不可用即整体拒绝服务；业务对可用性敏感时可评估调整为 no。
2. 副本长期同步失败，多与网络、repl-backlog-size 不足或主节点写入压力过大有关。
3. 出现脑裂风险时，结合 min-replicas-to-write 与 min-replicas-max-lag 限制主节点写入条件。

3. 槽位迁移报错

“ERR Target instance replied with error: MOVED” 通常在迁移过程中出现，属于正常重定向。若持续报错，检查迁移脚本是否中断、cluster-config-file 是否残留旧节点信息。

三、连接与崩溃类报错

1. 客户端连接被拒

典型报错：“ERR max number of clients reached”、“Connection reset by peer”。

• 核对 maxclients、系统 ulimit -n 与 net.core.somaxconn。三者中任一过小都会限制连接数。
• 排查是否存在连接泄漏：应用未正确归还连接池、未设置空闲回收，都会导致句柄持续增长。
• 开启 timeout 与 TCP keepalive，清理僵死连接。

2. 内存与淘汰引发的报错

典型报错：“OOM command not allowed when used memory > 'maxmemory'”、“MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist to disk”。

1. 前者的直接原因是内存达到上限且策略不允许写入，需检查 maxmemory-policy 与数据增长趋势。
2. 后者表示持久化失败后 Redis 停止接受写命令，需先修复磁盘或权限问题，再确认 stop-writes-on-bgsave-error 是否放开。
3. 不建议长期用 CONFIG SET 临时关闭写保护，应定位根因。

3. 进程崩溃与重启

• 查看系统日志中是否出现 OOM Killer 记录，确认 Redis 是否被内核终止。
• 检查 redis-server 核心转储与慢查询日志，定位是否存在超大 key 或阻塞命令。
• 避免使用 KEYS、FLUSHALL 等高风险命令，改用 SCAN 渐进遍历。

四、通用排查顺序

1. 先看 Redis 日志与系统日志，确认时间点与错误关键字。
2. 再查资源水位：内存、磁盘、文件句柄、网络带宽。
3. 然后用 INFO、SLOWLOG、CLIENT LIST 判断是配置问题还是业务压测所致。
4. 最后才考虑调整参数或重启，变更前保留可回滚的备份与配置快照。

以上方案覆盖了持久化、集群与连接崩溃三大类常见报错。实际处置中，建议先通过监控确认故障范围，再按影响面从大到小逐项排除，避免在高负载时段进行大规模配置变更。