2024年Redis高频面试题拆解：从八股文到实战陷阱

1. Redis的五种基础数据结构？别被版本更新坑了！（最新变动必看）

传统答案会脱口而出String/Hash/List/Set/ZSet这五种，但Redis 5.0新增的Stream类型已经晋升为第六大类型（面试官可能自己都没反应过来！！！）。重点掌握Stream在消息队列场景的应用，特别是消费者组机制和ACK确认特性，这已经成了大厂高频考点。

2. 缓存雪崩VS缓存穿透，哪个破坏力更强？

雪崩像雪球越滚越大（大量key同时失效），穿透则是针尖刺破防护（查询不存在的数据）。但实际最恐怖的是缓存击穿——某个超级热点key突然失效，百万QPS直接怼到数据库（亲身经历：某电商大促时商品详情页缓存失效，MySQL连接池瞬间打满！）

解决方案对比表：

现象	防御手段	注意事项
雪崩	随机过期时间 + 永不过期策略	预热环节要加二级缓存
穿透	布隆过滤器 + 空值缓存	过滤器存在误判，需定期重建
击穿	互斥锁 + 热点数据永不过期	分布式锁要设置合理的超时时间

3. Redis事务能保证ACID吗？别想当然！

Redis事务更像是批量命令打包（multi-exec），没有传统数据库的原子性和隔离性。举个反例：在事务中watch某个key后，如果其他客户端修改了该key，整个事务会失败（但已执行的命令不会回滚！！！）。所以千万别用Redis事务处理金融交易！

4. 集群方案怎么选？坑比你想的多！

• 哨兵模式：适合读多写少，主从切换时有30秒不可用窗口（足够让老板杀你三次了！）
• Cluster模式：自动分片但跨slot操作受限，mget/mset命令会直接报错
• Codis方案：国内大厂偏爱，但运维复杂度高

血泪教训：某次流量突增导致Cluster集群自动迁移slot，期间出现大量MOVED重定向，客户端没有正确处理直接雪崩…

5. 持久化方案你站哪边？RDB还是AOF？

成年人才不做选择！Redis4.0推出的混合持久化（RDB+AOF）真香！重启时先加载RDB快照，再重放AOF增量日志。但要注意aof-use-rdb-preamble配置项需要开启，并且aof文件体积会暴涨（记得监控磁盘空间！）

6. 单线程为什么这么快？这个认知该更新了！

经典回答会说"单线程避免上下文切换"，但Redis6开始引入IO多线程（注意：执行命令还是单线程！）。网络IO处理使用多线程，真正提升性能的是以下三点：

1. 内存操作纳秒级响应
2. IO多路复用+事件驱动
3. 避免锁竞争带来的损耗

7. 先更新数据库还是先删缓存？这道送命题怎么答？

经典的缓存一致性难题，没有银弹！根据业务场景选择：

• 延迟双删：先删缓存->更新DB->休眠->再删缓存（休眠时间难把握）
• 监听binlog：通过canal中间件异步更新（保证最终一致）
• 设置短过期时间：适合容忍暂时不一致的场景

记住：强一致性请直接读数据库，别用缓存！

8. 内存淘汰策略怎么选？看业务场景下菜碟

• allkeys-lru：通用场景首选
• volatile-lfu：热点数据优先保留
• allkeys-random：适合冷数据均匀分布

特别注意：配置maxmemory后不设置淘汰策略，Redis会直接报错！（别问我怎么知道的…）

9. 分布式锁用SETNX已过时？RedLock也不靠谱？

虽然Redis官方推荐RedLock算法，但Martin大佬和Antirez的世纪论战说明：没有绝对安全的分布式锁！建议：

1. 加锁设置随机值（防止误删）
2. 使用PX参数设置过期时间
3. 删除锁时用Lua脚本保证原子性
4. 业务代码要处理锁失效的重试机制

10. 大厂高频新题：Redis Module用过哪些？

• RedisSearch：全文搜索功能（比ES更轻量）
• RedisJSON：直接操作JSON数据（别再傻傻用String存了！）
• RedisGraph：图数据库功能（社交关系场景）

---

面试加分技巧（别外传！）

1. 提到Redis7.0的新特性：Function特性替代Lua脚本、ACL权限细化
2. 讨论多级缓存架构：Redis+本地缓存+CDN的组合拳
3. 分析缓存污染问题：如何识别并清理无用的大Key
4. 准备一个真实的生产事故案例（比如缓存穿透导致DB挂掉）

最后提醒：别死记硬背！理解设计哲学（比如为什么选择单线程模型）比背诵命令更重要。建议动手搭建集群环境，用redis-benchmark压测，真实体验性能瓶颈。面试时遇到不会的问题，可以坦诚地说"这个知识点我需要确认下"，千万别不懂装懂！