当前位置：首页 > 问答 > 正文

阿里面试里关于Redis那些绕不开的问题和考察点，聊聊面试官到底想问啥

太叔访天
问答
2026-01-16 07:13:07
2

说到阿里面试里的Redis，你会发现面试官很少会问你“Redis的五种数据类型是啥”这种死记硬背的问题，他们默认你已经掌握了基础，他们真正想考察的，是你怎么把这些知识用起来，解决实际生产中那些“恶心”的问题，他们的问题背后，往往藏着一个潜台词：“我们系统量很大，你这么用Redis，能扛得住吗？会不会出事儿？”

第一类绕不开的问题：缓存相关，这绝对是重灾区。

问题示例： “项目里你们是怎么用缓存的？如果缓存里的数据和数据库里的数据不一致了，怎么办？”
考察点与面试官心思：
- 他首先想听你的实战经验，你不是背理论，而是真的在项目里用过，你会提到为什么选择缓存某些数据（比如用户信息、商品详情），缓存键（Key）是怎么设计的（是不是有统一的命名空间，比如service:id:），过期时间怎么设置的（是固定时间还是随机值防止缓存雪崩）。
- “缓存不一致”是核心考点，他不想只听你背“先更新数据库，再删除缓存”或者用 Canal 监听 binlog 这类方案，他想知道你理解每种方案的权衡，你提到“先更数据库再删缓存”主流方案，他可能会追问：“在删除缓存这个动作失败的情况下，会有什么后果？你有什么兜底策略？” 这时候你如果能提到设置缓存过期时间作为最终保障，或者引入重试机制、消息队列来确保删除成功，面试官就会觉得你思考得很周全，他想看到你的风险意识。
问题示例： “缓存穿透、雪崩、击穿，说说你的理解以及在实际项目中是怎么预防的？”
考察点与面试官心思：
- 这老三样几乎是必考题，但高分回答和普通回答差别巨大，面试官讨厌听到千篇一律的“用布隆过滤器解决穿透、用随机过期时间解决雪崩、用互斥锁解决击穿”。
- 他想听细节和更深度的思考。
  - 穿透： 你用了布隆过滤器，那布隆过滤器本身的数据怎么和数据库保持同步？它的误判率你们业务能接受吗？有没有更简单的方案，比如对于肯定不存在的 key,也缓存一个空值并设置一个短的过期时间？
  - 击穿： 你用互斥锁（Redis 的 setnx），那这个锁的粒度是多少？会不会导致大量线程阻塞？有没有考虑过用“逻辑过期”的方案（即缓存值不过期，但里面存一个逻辑过期时间，另一个线程异步去更新）来避免锁竞争？这能体现你对高并发场景下性能瓶颈的洞察。
  - 雪崩： 你提到随机过期时间，那这个随机范围是怎么定的？为什么是 1-5 分钟，而不是 1-10 分钟？这背后有没有对业务流量和数据库承载能力的评估？这能看出你做事是否严谨、有数据驱动思维。

第二类绕不开的问题：Redis 的持久化和高可用。

问题示例： “RDB 和 AOF 的区别？你们生产环境用的哪种？为什么？”
考察点与面试官心思：
- 这问题看似基础，但陷阱很深，如果你只说“RDB 是快照，AOF 是日志，我们用了 AOF 因为数据更安全”,那就太浅了。
- 面试官想听到的是权衡（Trade-off），你需要说明白：RDB 恢复快，但可能丢数据，适合做冷备和容忍分钟级数据丢失的场景；AOF 数据安全，但文件大、恢复慢，然后引出“通常我们生产环境会同时开启，用 AOF 保证数据不丢，用 RDB 做某个时间点的快速备份”。
- 他还会关心操作细节：BGSAVE 子进程 fork 时，如果数据量太大，会导致主线程阻塞，你们是怎么监控和应对的？AOF 重写过程中会不会影响服务？这考察了你对 Redis 内部机制的理解和运维经验。
问题示例： “Redis 集群模式了解吗？主从、哨兵、Cluster 模式各自解决什么问题？”
考察点与面试官心思：
- 阿里体量的公司，单机 Redis 根本不够看，所以集群是必问的，面试官想通过这个问题判断你是否具备分布式系统的思维。
- 他希望你清晰地说出：主从复制是做数据冗余和读写分离；哨兵（Sentinel）是在主从基础上实现了高可用（HA），能自动故障转移；Cluster 模式则是为了海量数据的分片存储和横向扩展。
- 更深入的问题会接着来：“数据是怎么分片的？（CRC16取模）”“扩容缩容时，数据迁移是怎么做的？会阻塞服务吗？（回答出重哈希和异步迁移）”“客户端是怎么知道要去哪个节点读写数据的？（提到重定向机制 MOVED/ASK）” 这些问题都是在考察你对分布式系统数据分布、一致性、可用性这些核心概念的理解。

第三类绕不开的问题：实战场景设计。

问题示例： “用 Redis 实现一个分布式锁。”
考察点与面试官心思：
- 这可能是最经典的场景题了，面试官期待你写出的不是一个简单的 setnx 命令，而是一个工业级可用的锁。
- 你的回答需要覆盖：原子性获取（set nx px 一条命令完成），设置唯一值（UUID）用于防止误删其他客户端的锁，释放锁时检查是否为自己持有（Lua 脚本保证原子性），他可能会故意追问：“如果业务执行时间超过了锁的超时时间怎么办？” 这会引出了解红锁（RedLock） 的讨论，或者更务实的方案（比如守护线程续期），这里考察的是你对分布式锁本质（在不可靠环境下实现互斥）的深刻理解和对边界情况的处理能力。
问题示例： “设计一个微博/微信的点赞功能，要求防重复点赞、能显示点赞列表。”
考察点与面试官心思：
- 这类业务场景题，面试官想看你的数据模型设计能力，你会选择哪种数据结构？（比如用 Set 来存一个帖子的所有点赞用户 ID，键为 like:post:123），为什么用 Set？（因为天然去重，判断是否存在、获取总数都很高效）。
- 他还会关心扩展性：如果是个超级热帖，点赞数上百万，用 SMEMBERS 取全量列表会不会有问题？这时候你能否想到用 SSCAN 命令分批迭代？这体现了你对大数据量下的 Redis 操作技巧的掌握。