redis常见面试题

作为资深 Java 开发，面试 Redis 时，面试官通常会跳过简单的“数据类型”，直接切入高并发下的高可用、数据一致性以及底层存储逻辑。

以下是为你梳理的 Redis 夺命连环问：

1. 缓存三兄弟：穿透、击穿、雪崩

这是最经典的面试题，你需要给出架构级的解决方案。

• 缓存穿透（Key 不存在）：

  • 现象：查询一个既不在缓存也不在数据库的数据（如恶意攻击）。

  • 方案：布隆过滤器 (Bloom Filter)；或者把空结果也缓存起来，设置短过期时间。

• 缓存击穿（热点 Key 过期）：

  • 现象：一个“超级热点”Key 失效的瞬间，海量请求直冲数据库。

  • 方案：互斥锁 (Mutex Lock)，只允许一个线程去查库补缓存；或者设置热点数据永不过期，由后台线程异步更新。

• 缓存雪崩（批量过期）：

  • 现象：大量 Key 在同一时间过期，或者 Redis 挂了。

  • 方案：过期时间加随机扰动值（Jitter）；采用 Redis 高可用集群（Sentinel/Cluster）。

2. Redis 为什么这么快？

除了“内存操作”，你需要答出底层的 IO 模型：

1. 纯内存操作：避免了磁盘 IO 开销。

2. 高效的数据结构：如跳表（SkipList）、压缩列表（ZipList）。

3. IO 多路复用：利用 epoll 非阻塞 IO，单线程也能处理数万个连接。

4. 单线程执行命令：避免了多线程的上下文切换和锁竞争开销。

3. 数据持久化：RDB vs AOF

面试官会问你：如果服务器突然断电，怎么保证数据不丢？

• RDB (Redis Database)：

  • 原理：定时对全量数据做快照。

  • 优点：恢复速度快，文件小。

  • 缺点：丢失风险大（两次快照间的数据会丢）。

• AOF (Append Only File)：

  • 原理：记录每一条写命令。

  • 优点：数据最完整（fsync 策略）。

  • 缺点：文件大，恢复慢。

• 混合持久化（Redis 4.0+）：RDB 做全量 + AOF 做增量，目前主流配置。

4. 数据库与缓存的一致性（重点）

先删缓存还是先更新数据库？

• 痛点：只要是分布式系统，就没法保证绝对的原子操作。

• 主流方案：Cache Aside Pattern。

  1. 先更新数据库。

  2. 再删除缓存。

• 进阶保障：为了防止第二步删除失败，可以引入 延迟双删 策略，或者订阅数据库的 Binlog (使用 Canal) 异步删除缓存。

5. Redis 分布式锁的坑

如果你用 setnx 实现锁，面试官会问：如果业务没执行完，锁过期了怎么办？

• 标准回答：不能只靠 setnx。

• Redisson 方案：使用 Redisson 客户端，它带有一个 “看门狗” (Watch Dog) 机制，会自动给快要过期的锁“续期”。

• Redlock 算法：如果是集群环境，需要半数以上节点加锁成功才算成功。

6. 集群模式：Sentinel vs Cluster

• Sentinel (哨兵)：主要解决 高可用。监控主从状态，主挂了自动选举新主，但不支持横向扩容。

• Cluster (集群)：主要解决 横向扩容。数据通过 哈希槽 (Hash Slot) 分散在不同节点上。

🛠 资深开发的加分点：大 Key 和 热 Key 探测

• 大 Key (BigKey)：比如一个 List 存了百万数据。

  • 危害：阻塞主线程，导致集群脑裂。

  • 解决：使用 SCAN 命令分批处理，或者开启 lazyfree-lazy-eviction 异步删除。

• 热 Key (HotKey)：

  • 发现：监控 Redis 客户端或使用 redis-cli --hotkeys。

  • 解决：利用本地缓存（如 Caffeine）挡一层；或者给热 Key 增加随机后缀，分散到多个 Slot。

📉 状态同步

• 2026-03-30：已整理 Redis 核心面试题，涵盖缓存策略、持久化、一致性及分布式锁。

这些知识点不仅是面试的“八股文”，更是你处理如 pancakebot.vip 这种实际项目时，保障系统不宕机的底气。

既然聊到了 Redis 性能，你想看看如何通过 Redis 的“慢查询日志”去抓取那些拖慢你 Java 应用的“真凶”吗？