一文搞懂Redis面试错误解决，面试和工作都用得到

一文搞懂 Redis 面试错误解决，面试和工作都用得到

核心思路：Redis 报错不要死记报错码，分 客户端异常、连接异常、内存异常、持久化异常、集群异常、命令与使用规范 六大类，同时区分【面试标准答案】和【线上真实排查步骤】，面试直接说思路，工作直接照着排错。

一、连接类报错(最高频)

1. Could not connect to Redis at xxx:6379: Connection refused

原因

Redis 服务没启动

绑定了 bind 127.0.0.1，外部机器无法访问

防火墙 / 安全组拦截 6379 端口

端口被别的程序占用

✅ 排查(工作)

systemctl status redis 看服务状态

检查 redis.conf bind、protected-mode

防火墙放行：firewalld /ufw/ 云服务器安全组 ✅ 面试回答：先确认进程是否启动，再检查绑定地址、保护模式、防火墙、端口占用。

2. DENIED Redis is running in protected mode

原因：保护模式开启，没有设置密码、没有指定 bind，拒绝外部访问 ✅ 方案(生产不建议直接关闭保护模式)

设置密码 requirepass

配置 bind 指定可信 IP

面试加分：线上禁止直接 protected-mode no，优先密码 + 白名单，而不是关闭保护模式。

3. IOError: Connection reset by peer / Read timeout

原因

网络抖动、中间代理断开连接

Redis 服务端 timeout 配置，空闲连接被服务端踢掉

客户端连接池配置不合理，拿了闲置很久的旧连接 ✅ 解决：

客户端连接池配置：空闲连接检测、心跳检测

不要用长连接硬扛，合理设置连接超时

哨兵 / 集群场景下，主从切换也会触发连接重置

4. NOAUTH Authentication required

原因：Redis 设置密码，客户端没传密码 ✅ 解决：连接时 auth 密码 或者客户端配置 password 参数

面试坑：很多人只说加密码，忘记区分：redis6 + 支持 ACL，不止 requirepass。

二、内存相关报错(面试必考，OOM、淘汰策略)

1. OOM command not allowed when used memory > 'maxmemory'

原因：内存打满，并且 maxmemory-policy noeviction(不淘汰，直接拒绝写入) ✅ 排查步骤

info memory 看内存占用

查看 maxmemory、maxmemory-policy ✅ 面试必背 6 种淘汰策略：

noeviction：不淘汰，写报错(默认旧版本)

allkeys-lru：所有 key LRU 淘汰

volatile-lru：带过期 key LRU

allkeys-lfu：所有 key LFU

volatile-lfu：带过期 key LFU

volatile-ttl：优先淘汰快要过期的 key

面试加分：业务热点缓存优先 allkeys-lfu;有过期时间的临时缓存用 volatile-lru;不允许丢数据的业务不能依赖淘汰，要控制写入量。

2. Memory is not enough to allocate

原因：系统可用内存不足，Redis 申请内存失败 ⚠️ 重点：Linux 下 overcommit_memory 配置!

overcommit_memory=0：严格校验，容易分配失败

overcommit_memory=1：允许超分配(Redis 推荐) ✅ 面试高频考点：Redis 持久化 RDB/AOF fork 子进程，需要双倍内存预留，内存快满时 fork 失败。

三、持久化报错(RDB、AOF，面试重灾区)

1. Can't save in background: fork: Cannot allocate memory

原因：执行 bgsave，fork 子进程失败，系统内存不足 ✅ 方案：

调大系统内存，或者降低 Redis 内存占用

调整 overcommit_memory = 1

错开业务高峰执行 bgsave

面试一句话：fork 会拷贝页表，需要预留内存，不是 Redis 本身占用，是操作系统内存分配机制。

2. AOF check error / Bad file format

原因：AOF 文件损坏(断电、磁盘异常、写入中断) ✅ 修复流程：

redis-check-aof --fix appendonly.aof 修复

优先备份原文件再修复

修复后重启 Redis

面试区分：RDB 损坏用 redis-check-rdb;AOF 修复会丢弃损坏之后的数据。

3. AOF fsync is taking too long (disk is busy)

原因：磁盘 IO 打满，AOF 刷盘阻塞主线程 appendfsync 三个配置：always /everysec/no

always：每条刷盘，最安全，性能差

everysec：每秒刷(默认，折中)

no：交给操作系统刷，性能高，丢数据风险大 ✅ 面试考点：everysec 最多丢 1 秒数据;磁盘慢的时候，everysec 依然会阻塞。

四、集群 / 哨兵报错(Redis Cluster + Sentinel)

1. MOVED xxx xxx:6379

原因：Cluster 集群，key 不在当前槽位，重定向 ✅ 处理：客户端必须支持集群模式，自动重定向，不要单机方式访问集群节点

面试坑：很多新手用普通 Jedis 直连集群节点，就会疯狂报 MOVED。

2. ASK xxx xxx:6379

原因：集群正在做槽迁移(migrate)，临时重定向，和 MOVED 不一样

MOVED：槽永久归属别的节点

ASK：迁移中，临时去目标节点查询，查询完不缓存槽信息

3. CLUSTERDOWN The cluster is down

原因：集群槽不全，至少 16384 个槽没有全部分配正常，整个集群不可写入 ✅ 排查：cluster info、cluster slots，看哪些槽未分配、节点失联常见诱因：节点半数宕机、槽迁移中断、节点网络分区

4. Sentinel 无法自动故障转移

原因清单(面试常问)

客观下线条件没满足(quorum 票数不够)

主从之间网络不通

从机配置 slaveof 错误、replica-priority 0 不参与选主

哨兵时间不同步、防火墙阻断哨兵通信端口

加分：quorum 是判定客观下线;实际选举新主需要过半哨兵同意。

五、命令、数据类型、并发相关报错

1. WRONGTYPE Operation against a key holding the wrong kind of value

原因：key 存在，但数据类型和你执行的命令不匹配例：key 是 string，你执行 hget(哈希命令) ✅ 排查：type key 查看类型

工作中常见：代码复用 key、脏数据残留、测试环境没清理数据。

2. BUSYKEY Target key name already exists

原因：redis5+ stream、或者 rename、migrate 的时候目标 key 已存在

3. 并发超卖、缓存击穿 / 雪崩 / 穿透(不算报错，但面试必问 “异常现象”)

缓存穿透：查不存在 key，大量请求打 DB → 布隆过滤器、空值缓存

缓存击穿：热点 key 过期，大量请求打 DB → 互斥锁、永不过期、逻辑过期

缓存雪崩：大量 key 同时过期 → 过期时间加随机偏移、集群拆分、限流降级

4. Lua 脚本报错：Script is busy

原因：Lua 脚本执行超时，Redis 默认不允许打断，会拒绝新脚本 ✅ 面试：script kill 杀掉脚本(只读脚本);如果脚本已经写数据，script kill 无效，只能 shutdown。

重点：Lua 脚本是原子执行，超时后会阻塞，线上 Lua 尽量简短，避免慢查询。

六、慢查询、阻塞类问题(现象：Redis 卡顿，无明确报错)

慢查询不是报错，但是面试高频： slowlog get 查看慢查询阻塞来源：

大 key：del 一个超大 hash/list，主线程阻塞

大量 keys *、flushall、flushdb(禁止在线上业务调用)

持久化 fork、AOF 刷盘、大集群槽迁移 ✅ 面试回答：禁止线上 keys;大 key 用 unlink(异步删除);拆分大 key。

七、面试通用答题模板(直接背)

面试官问：Redis 报 XX 错误，你怎么排查?

先看报错信息，区分【连接 / 内存 / 持久化 / 集群 / 命令类型】

先用 info、cluster info、slowlog、redis-cli 基础命令定位

检查配置文件(maxmemory、appendfsync、bind、保护模式)

检查外部环境：网络、防火墙、磁盘 IO、系统内存、overcommit_memory

给出修复方案，同时说风险(比如 AOF 修复会丢数据、关闭保护模式不安全)

最后补充：如何提前预防(监控、告警、规范)

八、高频避坑总结(面试容易答错)

❌ 报错 fork 失败，直接加内存就完事 → ✅ 要提 overcommit_memory 和 fork 机制

❌ ASK 和 MOVED 当成同一个重定向 → ✅ 一个是迁移临时，一个是永久槽归属

❌ 保护模式直接关闭解决 → ✅ 生产推荐密码 + IP 白名单

❌ Lua 脚本超时直接 kill 一定成功 → ✅ 有写入的脚本不能 kill

❌ 淘汰策略能保证数据不丢 → ✅ 淘汰是删除 key，重要业务不能依赖淘汰