第94篇：Redis面试高频题（2026版）—— 深度解析 + 生产实战

📌 系列导航：《Java 100 天进阶之路》完整目录 |
⬅️ 上一篇：第93篇：Redis实战应用：缓存策略与分布式锁 |
➡️ 下一篇：第95篇：消息队列基础（RocketMQ/Kafka）（待发布）

---

🚀 一、核心考点全景图

本文精选 30+ 道 Redis 大厂高频面试题，覆盖以下 6 大模块，其中 Lua/事务 和 AI 新场景 是 2026 年的关键加分项。

考点模块	核心关键词	面试考察目标
数据结构	SDS, ListPack, QuickList, SkipList	考察对底层存储原理的理解，避免“只会用”
持久化	RDB, AOF, 混合持久化, COW	考察数据安全与性能的平衡能力
高可用	Cluster (16384槽), Sentinel, 哨兵选举	考察分布式系统架构设计能力
缓存策略	穿透/击穿/雪崩, 布隆过滤器, 多级缓存	考察解决高并发业务场景的实战经验
高级特性	Lua 脚本, Redisson, 事务 vs Lua	考察对原子性、分布式锁的深度把控
AI 新场景	Embedding 缓存, RAG, 推理延迟优化	2026年特有加分项，考察技术前瞻性

---

二、数据结构与底层实现（5题）

Q1：Redis 支持哪些数据结构？底层实现分别是什么？

String（SDS）、Hash（ListPack+HashTable）、List（QuickList）、Set（IntSet+HashTable）、ZSet（ListPack+SkipList+HashTable），以及 HyperLogLog、Bitmap、Geo、Stream。
💡 加分：Redis 7.0 用 ListPack 替代 ZipList 解决了连锁更新性能问题。ZipList 在修改时可能触发 O(N²) 的连锁更新，ListPack 采用反向存储长度，修改不影响其他元素，性能更稳定。

Q2：Redis 的 String 底层为什么不用 C 语言字符串？

SDS 支持 O(1) 获取长度，二进制安全，预分配内存减少扩容开销。

Q3：ZSet 底层跳表 vs 红黑树，为什么选跳表？

跳表实现简单，支持范围查询（ZRANGE）效率高（O(logN + M)），且内存占用与红黑树相近。业务中排行榜分页非常频繁，跳表优势明显。

Q4：Redis 的 List 作为消息队列有什么缺点？

不支持多消费者、消息确认，消费者宕机会丢消息。专业场景用 Redis Stream 或 RocketMQ。

Q5：Bitmap 和 HyperLogLog 适用场景？

Bitmap：签到、布隆过滤器底层；HyperLogLog：UV 统计（误差 0.81%，内存固定 12KB）。

---

三、持久化（3题）

Q6：RDB 和 AOF 的区别？如何选型？

RDB 定期快照，恢复快但可能丢数据；AOF 记录命令，最多丢1秒。生产推荐混合持久化（Redis 4.0+）。

Q7：AOF 重写原理？

fork 子进程，读取内存数据生成最小命令集写入新 AOF，完成后替换旧文件。避免文件无限膨胀。

Q8：大内存 Redis 做 BGSAVE 时导致 OOM 怎么办？

调整 overcommit_memory = 1；使用无盘复制（repl-diskless-sync）；低峰期执行；升级到 Redis 7.x。

---

四、高可用与集群（6题）

Q9：主从复制的全量与增量同步过程？

全量：RDB + 复制缓冲区；增量：PSYNC2，根据 runid 和 offset 判断是否可增量。

Q10：哨兵选举新主的流程？

主观下线 → 客观下线（quorum 票）→ 领导者哨兵 failover → 选 slave 优先级高、偏移量大、runid 小的。

Q11：Redis Cluster 如何分片？

16384 个哈希槽，每个 key 根据 CRC16(key) % 16384 映射到槽，节点负责一部分槽。客户端任意连接，MOVED/ASK 重定向。

Q12：Cluster 执行多 key 操作限制？

不同槽的 key 不能放入一个事务或批量操作。可用 {hashtag} 强制同槽。

Q13：使用 Redis Cluster 时还需要 Sentinel 吗？

不需要。Cluster 自带主从选举（Raft），Sentinel 仅用于非分片的主从架构。

Q14：如何平滑扩容 Cluster？

redis-cli --cluster add-node 添加新节点，再使用 --cluster reshard 迁移槽位，业务无感知。

---

五、缓存三大杀手（4题）

Q15：缓存穿透、击穿、雪崩区别与解决方案？

术语	原因	解决方案
穿透	查询不存在数据	布隆过滤器 + 缓存空对象
击穿	热点 key 过期	互斥锁（Redisson）或逻辑过期
雪崩	大量 key 同时过期	随机 TTL + Redis 集群

Q16：布隆过滤器为什么存在误判？

哈希碰撞。可通过增加位数组长度和哈希函数个数降低误判率。生产推荐 Redisson 的 RBloomFilter（持久化、分布式），避免 Guava 内存版重启丢失。

Q17：逻辑过期解决击穿的原理？

缓存中存 value + expireTime，查询时若逻辑过期，异步去 DB 更新并返回旧值，无阻塞。适合容忍短暂不一致的场景（如商品详情）。

Q18：热点 Key 如何治理？

本地缓存（Caffeine）+ Redis 多级缓存；读写分离；使用 HLL 或客户端计数识别热点。

---

六、分布式锁与 Lua 脚本（5题）

Q19：Redis 分布式锁的缺陷？

死锁（未设过期时间）、锁误删（未校验持有者）、锁过期业务未完成。生产用 Redisson，其看门狗自动续期。

Q20：Redisson 看门狗原理？

锁默认 30 秒，每 10 秒检查任务是否完成，若未完成则续期，完成后主动释放。

Q21：Redisson 对 Lua 脚本的封装有哪些优雅之处？

• 极简 API：RScript 对象，明确区分模式、返回值类型、KEYS/ARGV。
• 脚本缓存：首次加载生成 SHA1 摘要，后续 evalSha 减少网络传输。
• 执行模式：READ_ONLY 可路由到从节点，分担主节点压力。
• 序列化解决：配置 JsonJacksonCodec 避免 tonumber 返回 nil。

Q22：如何防止 Lua 脚本阻塞 Redis？

• 控制时长：单个脚本执行 < 1ms，设置 lua-time-limit（如 500ms）。
• 拆分复杂操作：拆分为多个小脚本或异步消息队列。
• 禁用全量扫描：严禁 KEYS *、HGETALL，改用 SCAN。
• 限制调用次数：每个脚本 redis.call ≤ 3 次。
• 使用 EVALSHA：避免重复传输脚本内容。
• 控制批量 Key 数量：单次处理 100~1000 条。
  💡 加分（Redis 7.0+ 新特性）：Redis 7.0 引入 Redis Functions，脚本持久化、集群同步、权限管理更强；Sharded Pub/Sub 解决集群模式下的广播性能问题。

Q23：Redis 分布式锁与 Zookeeper 锁对比？

Redis 性能高，适合高并发；Zookeeper 强一致，适合金融等极高可靠性场景。

---

七、Redis 事务深度解析（对比 Lua 脚本）

7.1 事务 vs Lua 脚本核心对比

特性	Redis 事务 (MULTI/EXEC)	Lua 脚本
原子性	⚠️ 隔离性，运行时错误不回滚	✅ 强原子性，脚本整体执行
网络开销	❌ 多次往返	✅ 一次性发送，RTT 少
逻辑能力	❌ 仅顺序执行，无分支循环	✅ 支持复杂逻辑（if-else、循环）
阻塞风险	🟢 低	🔴 高，需严格控制执行时间
适用场景	简单批量命令、乐观锁（WATCH）	强原子性复杂逻辑（秒杀、扣库存）

深度解析：两者都不支持传统回滚。事务中某命令失败，已执行命令不回滚；Lua 脚本中 redis.call 出错会终止脚本，但已执行的写操作也会保留（除非用 pcall 捕获并手动补偿）。

7.2 生产环境选型建议

• 选择事务：仅需保证一组简单命令顺序执行，不依赖中间结果；或配合 WATCH 实现乐观锁（如计数器、积分更新）。
• 选择 Lua 脚本：需要强原子性（如秒杀扣库存）、依赖读取-判断-写入的复杂逻辑、希望减少网络 RTT。

7.3 Redis 事务实际应用场景（面试话术）

“实际业务中，我们通常把 Redis 事务看作轻量级命令批处理机制。例如计数器原子更新（WATCH + INCR）、账户转账（DECR + INCR）、批量初始化等。但需注意：事务不支持回滚，高并发冲突下性能差。秒杀等场景我们改用 Lua 脚本 或 Redisson 分布式锁。”

---

八、性能优化与常见问题（5题）

Q24：KEYS * 为什么禁用？

阻塞 Redis 单线程，生产用 SCAN 渐进式遍历。

Q25：Big Key 危害与治理？

危害：慢查询、阻塞、网络拥塞。量化：String >10KB，集合 >1000 元素。治理：拆分、UNLINK 删除、MEMORY USAGE 监控。

Q26：Redis 内存淘汰策略有哪些？

volatile-lru、allkeys-lru、volatile-ttl、allkeys-random、noeviction（默认）。
⚠️ 生产严禁 noeviction，会导致 OOM。
通用缓存选 allkeys-lru，有冷热分片选 allkeys-lfu。

Q27：Pipeline 与事务（MULTI）区别？

Pipeline 打包命令减少 RTT，不保证原子性；事务原子执行，但不支持回滚。
Pipeline 要分批次提交（每批 ≤ 1000），防内存暴涨。

Q28：Redis 单线程为什么快？

纯内存、非阻塞 I/O（IO多路复用，基于 epoll）、数据结构高效、单线程避免上下文切换。
💡 加分：Redis 6.0+ 引入多线程 I/O，仅用于网络收发和协议解析，核心命令执行依然单线程，兼顾高并发与原子性。

---

九、场景设计题（3题）

Q29：设计秒杀系统 Redis 部分？

库存预热到 Redis，使用 Redisson 分布式锁扣减，异步消息队列持久化订单。缓存商品详情使用逻辑过期。

Q30：排行榜实时更新（千万用户）？

用 ZSet，score 为分数，ZINCRBY 原子增，ZREVRANGE 取 Top N。分页用 ZREVRANGE 加 limit。

Q31：UV 统计（日活）？

HyperLogLog，PFADD + PFCOUNT，误差 0.81%，12KB 固定内存，可合并多天 PFMERGE。

---

十、跨界思考：AI 时代的缓存优化（2026 加分项）

Q32：如何用 Redis 优化 LLM 大模型的推理延迟？

在 RAG（检索增强生成）架构中，Embedding 向量和 Prompt 结果是典型“重计算、可缓存”资源。

1. Embedding 缓存：将用户问题计算出的 Embedding 向量存入 Redis，利用 RediSearch 模块的 HNSW 索引实现近似最近邻搜索，缓存命中时直接复用，减少对 Embedding 模型的重复调用。
2. 推理结果缓存：对于相同或相似的问题（通过语义相似度去重），直接返回缓存的 LLM 生成结果，显著降低成本与延迟（尤其适合高频 FAQ）。
3. 流式限流：使用 Redis 的 INCR + 过期时间实现令牌桶或滑动窗口限流，保护 LLM 后端不被突发流量冲垮。
   💡 实践：某智能客服系统通过 Redis 缓存 Embedding，将平均响应延迟从 2.5s 降至 0.4s，每月节省约 40% API 调用费用。

---

十一、生产级实战深度解析（加分专题）

11.1 缓存击穿真实事故排查

案例：某电商促销时，爆款商品缓存失效，10万+ 并发直击 DB，连接池瞬间耗尽。
紧急止血：手动查库写入 Redis，临时开启互斥锁。
长期优化：热点 Key 设置为“逻辑永不过期”，定时任务异步刷新；所有热点商品设置随机偏移量（基础 TTL + 0~5 分钟）。

11.2 分布式锁防死锁与防误删

• 原子加锁：必须使用 SET key value NX PX milliseconds，避免 SETNX + EXPIRE 非原子导致死锁。
• 防误删：释放锁时用 Lua 脚本校验唯一标识（UUID），防止锁过期后误删其他线程的锁。

11.3 Big Key 与热 Key 治理

• 绝对禁止：KEYS *、HGETALL 大集合。用 SCAN / HSCAN 分批。
• 检测命令：redis-cli --bigkeys、MEMORY USAGE key。
• 热 Key 处理：多级缓存（Caffeine + Redis），或代理层（如 Codis）自动识别分发。

11.4 双写一致性保障策略

推荐 “先更新 DB，再删除缓存”。为防止极短窗口期脏读，可升级为 “延时双删”：
更新 DB → 删除缓存 → 休眠几百 ms → 再次删除缓存。
更优雅方案：通过 Canal 监听 MySQL binlog，异步更新 Redis，彻底解耦。

---

📊 你的学习进度

• 当前：第94篇 / 共108篇 · 进阶篇：缓存与消息队列（第91~96篇）
• ✅ 已完成：基础篇44篇 + 第91~94篇
• 📖 正在学：第94篇
• ⏳ 待学习：第95~108篇

👉 📚 完整目录 & 学习指南 | 🔥 订阅本专栏，不错过每一篇

💡 本专栏每篇都包含：避坑表 + 面试高频考点 + 练习题。每天30分钟，100天拿offer！

---

👉 下一篇文章预告

《第95篇：消息队列基础（RocketMQ/Kafka）（2026版）》

内容简介：消息队列核心模型（点对点/发布订阅）、RocketMQ 与 Kafka 对比、消息丢失/重复消费/顺序消息解决方案、死信队列实战。

💡 学完这篇，你将掌握消息中间件选型与生产级使用规范。

🎁 福利提醒：评论区留言“Redis面试”可领取《Redis 面试高频题 PDF》完整版（含本文所有扩展内容）。

📌 《Java 100 天进阶之路 | 从入门到上岗就业》 每天一篇，建议收藏 + 关注，一起100天拿offer！
👉 点击关注我，更新后第一时间收到推送！