Redis高频面试题深度解析，从单线程模型到集群槽机制的实战要点

在后端开发与系统架构岗位的面试中，Redis 几乎是必考项。其简洁协议、高性能内存操作与丰富的数据结构使其成为缓存与中间件层的基石，但这也导致面试官倾向于深挖底层机制与边界场景。近期技术社区对 Redis 高频题目的讨论集中于六个维度：执行模型演进、过期键清理逻辑、持久化策略权衡、分布式锁安全实现、Cluster 分片槽机制，以及事务与原子性边界。这些题目不仅考察知识广度，更检验候选人是否具备生产环境中的故障预判与调优意识。

首先，关于“Redis 为什么快”这一经典问题，标准答案常被简化为“单线程无锁”，但这已不准确。自 Redis 6.0 起，网络 I/O 层引入了多线程模型——主线程仍负责命令执行（保持原子性），而多个 I/O 线程并行处理 socket 读写。这意味着：命令处理仍是单线程，避免了并发修改共享数据的锁竞争；但连接建立、协议解析与响应发送可并行化，显著提升高并发下的吞吐能力。值得注意的是，瓶颈通常不在 CPU 计算本身（内存操作多为微秒级），而在于慢查询（如 KEYS *、超大 HGETALL）、大 Key 阻塞或 Lua 脚本死循环。面试中若能补充 I/O 线程演进细节，往往能体现对版本迭代的真实理解。

第二类高频问题是过期键的删除时机。Redis 采用惰性删除与定期删除双机制协同工作：当客户端访问某 Key 时，若发现 TTL 已过期，则立即删除并返回空值（惰性）；同时后台周期性随机抽样检查带过期时间的 Key，到期即删（定期）。这种设计平衡了实时性与性能开销，但也导致 INFO memory 中内存占用不会随 TTL 到期即时下降——这是正常现象，非内存泄漏。需特别注意区分“过期删除”与“内存淘汰”：后者由 maxmemory-policy 触发，当内存达上限时按策略驱逐 Key，与 TTL 无必然关联。常见策略中，volatile-lru 仅淘汰设过期时间的 Key，allkeys-lru 则无差别淘汰，而 noeviction 在写满时直接报错，适用于将 Redis 当数据库使用的场景。

第三，RDB 与 AOF 的选型争议长期存在。RDB 是某一时刻的内存快照，文件小、恢复快，但两次快照间的数据在崩溃时会丢失；AOF 则以追加日志方式记录写命令，通过 appendfsync everysec 可控制最多丢一秒数据，但文件更大、重放耗时更长。实际生产中，混合持久化（AOF 前半段为 RDB 格式底稿，后半段为增量命令）已成为主流方案，兼顾恢复速度与数据安全性。关键提醒：SAVE 命令会阻塞主线程，线上必须使用 BGSAVE；而 fork 子进程时，若内存过大可能引发短暂抖动，这也是运维监控的重点指标。

进一步延伸，Redlock 算法虽被提出用于多节点容错，但因时钟漂移与网络分区问题存在争议，多数场景下单实例 + 身份校验 + 合理超时已足够支撑缓存互斥与下单防重。更深层建议：对于扣库存等 check-then-act 场景，优先用 Lua 将读写合并为原子操作，比依赖外部锁更可靠。

第五，Cluster 的 16384 个槽是分片核心。整个 keyspace 被划分为 16384 个哈希槽，每个主节点负责一段连续槽位。Key 映射规则为 CRC16(key) mod 16384，客户端计算槽位后直连对应节点。扩容时迁移的是槽而非具体 Key，保证平滑伸缩。多 Key 命令（如 MGET、SUNION）要求所有 Key 落在同一槽，否则报错。解决方案是使用哈希标签：将 order:{1001}:pay 与 order:{1001}:items 中的 {1001} 作为标签，使 CRC16 计算仅基于 1001，从而确保同槽。需明确区分 Cluster、Sentinel 与主从复制三者定位：Cluster 自带分片与故障转移；Sentinel 专注主从高可用；主从复制解决读扩展与备份，三者功能互补但不可混用。

最后，事务机制常被误解为“强一致性保障”。Redis 的 MULTI/EXEC 仅提供命令排队与原子执行（无回滚），不支持隔离级别与 ACID 中的“一致性”语义。其本质是“一次性发送多个命令”，若中间某命令语法错误，后续命令仍会执行；若运行时出错（如对 String 执行 HGET），仅该命令失败，其余继续。真正需要强一致性的场景（如资金转账），应结合 Lua 脚本或外部数据库事务实现。

除上述六点外，穿透、击穿、大 Key 等问题也高频出现。缓存穿透指查不存在的 Key 导致大量请求打到 DB，可用布隆过滤器或空值缓存防御；缓存击穿是热点 Key 过期瞬间并发请求压垮 DB，可通过互斥锁或永不过期+异步更新缓解；大 Key 则易引发阻塞与网络传输延迟，需定期扫描并拆分。这些并非孤立知识点，而是构成 Redis 在高并发系统中稳定运行的完整防护链。

值得指出的是，当前面试趋势正从“背八股”转向“讲链路”：考官更关注候选人能否将 Redis 放入真实业务上下文——例如在微服务熔断中如何用 Redis 状态监控预防雪崩，或在 Serverless 架构下利用其低延迟特性抵御冷启动击穿。这要求开发者不仅懂命令，更要理解其在系统级协作中的角色。

综上，Redis 面试题的本质是考察对“简单设计背后复杂权衡”的认知深度。从单线程到 I/O 多线程，从惰性删除到槽位迁移，每一处优化都源于对性能、一致性与可用性三角的反复取舍。掌握这些逻辑链条，远比记忆标准答案更具长期价值。