Redis高频面试题解析干货，结合核心原理、高频考点和回答技巧

一、Redis核心数据结构与实战场景

高频问题：Redis有哪些数据结构？分别适合什么场景？
回答模板：

1. 基础结构（必答）：

   • String（缓存、计数器）、Hash（对象存储）、List（队列、栈）、Set（标签、去重）、ZSet（排行榜）
   • 扩展加分：Bitmaps（日活统计）、HyperLogLog（UV去重）、GEO（地理位置）

2. 场景举例（体现实战能力）：

   • 例1：用ZSet实现电商销量排行榜，ZINCRBY更新分数，ZREVRANGE获取Top10；
   • 例2：用Hash存储用户会话信息（如HSET user:1001 name "Alice"），减少Key数量。

3. 底层优化（展示深度）：

   • 小数据用ziplist（Hash/List/ZSet的紧凑编码），大数据转skiplist或dict。
   • 踩坑案例：大Value（如10MB的String）导致网络阻塞，需拆分或压缩。

---

二、持久化机制：RDB vs AOF

高频问题：RDB和AOF的区别？如何选择？
回答策略：

1. 核心区别：

   • RDB：全量快照，恢复快但可能丢数据；
   • AOF：增量日志，数据安全但文件大；
   • 混合持久化（4.0+） ：AOF文件 = RDB头 + 增量日志（兼顾速度与安全）。

2. 选型建议（体现决策能力）：

   • 主从架构：主节点开AOF（appendfsync everysec），从节点开RDB；
   • 容灾要求高：混合持久化 + 定期备份RDB到云存储。

3. 实战坑点：

   • AOF重写期间内存暴涨 → 监控aof_rewrite_in_progress，限制重写频率。

---

三、高可用方案：主从、哨兵、集群对比

高频问题：如何保证Redis高可用？
回答框架：

1. 方案对比（清晰分层）：

   • 主从复制：手动切换，适合测试环境；
   • 哨兵：自动故障转移，中小规模生产；
   • Cluster：分片存储，大规模数据（如10TB+）。

2. 集群原理（展示技术深度）：

   • 数据分片：16384个槽，CRC16(key) % 16384计算槽位；
   • Gossip协议：节点间通信，Redis 7.0优化了故障检测速度。

3. 实战经验（加分项）：

   • 案例：某业务从哨兵迁移到Cluster，通过redis-cli --cluster reshard平滑扩容，解决数据倾斜问题。

---

四、缓存异常问题：穿透、击穿、雪崩

高频问题：如何解决缓存穿透？
回答技巧：

1. 穿透 vs 击穿 vs 雪崩（先澄清概念）：

   • 穿透：查不存在的数据（恶意攻击）；
   • 击穿：单个热点Key过期；
   • 雪崩：大量Key同时过期。

2. 解决方案（分层递进）：

   • 穿透：布隆过滤器（误判率可控） + 缓存空值（SET null 5s）；
   • 击穿：互斥锁（Redisson的tryLock） + 逻辑过期时间；
   • 雪崩：随机过期时间（基础版） + 二级缓存（本地缓存+Redis）。

3. 扩展思考（体现架构能力）：

   • 布隆过滤器内存占用计算：n=元素数量, p=误判率 → m=-n*lnp/(ln2)^2。

---

五、分布式锁实现与Redisson

高频问题：如何用Redis实现分布式锁？
回答模板：

1. 基础方案（必答）：

   • SET lock_key uuid NX EX 30（原子性加锁+过期时间）；
   • 对比Lua脚本解锁（if redis.call("get",KEYS[1])==ARGV[1] then return redis.call("del",KEYS[1])）。

2. 进阶方案（展示知识面）：

   • RedLock算法（半数以上节点加锁成功）；
   • Redisson看门狗机制（自动续期，避免业务未完成锁过期）。

3. 陷阱规避（体现严谨性）：

   • 避免锁过期后误删其他请求的锁（UUID验证）；
   • 时钟漂移问题：NTP同步 + RedLock依赖多数节点时钟一致。

---

六、Redis为什么快？单线程模型优劣

高频问题：Redis单线程为什么性能高？
回答策略：

1. 核心原因（分层回答）：

   • 内存操作 + 单线程无锁竞争 + I/O多路复用（epoll）；
   • 高效数据结构（如跳表、ziplist）。

2. 瓶颈分析（展示辩证思维）：

   • 单线程模型：适合高吞吐但CPU不密集场景，需避免慢查询（如KEYS *）；
   • Redis 6.0多线程：仅网络I/O多线程（io-threads 4），命令执行仍单线程。

3. 优化案例：

   • 某高并发场景通过Pipeline批量写入，提升吞吐量300%。

---

七、性能调优与监控

高频问题：如何定位Redis性能问题？
回答框架：

1. 工具链（体现专业性）：

   • slowlog get：分析慢查询（阈值slowlog-log-slower-than）；
   • redis-cli --bigkeys：找出大Key；
   • INFO memory：监控内存碎片率（mem_fragmentation_ratio > 1.5需重启）。

2. 优化手段：

   • 连接池配置（避免频繁创建连接）；
   • 内存淘汰策略选择（allkeys-lfu适合高频访问场景）。

3. 实战案例：

   • 某业务因Hash字段过多导致ziplist转dict，内存上涨30%，通过拆分Key优化。

---

本文由 https://www.dblens.com 知识分享， dblens for MySQL - 免费的MySQL管理工具。