Redis 面试串讲：从应用场景到高可用的一条回答线

Redis 的题目很容易背散。今天背五种数据类型，明天背 AOF 和 RDB，后天背分布式锁、缓存击穿、哨兵、集群。每个点都能说两句，但一旦面试官换个问法，比如“你们为什么用 Redis”“Redis 出问题怎么保证业务可用”“缓存和数据库怎么保持一致”，回答就容易乱。

相关基础内容 的 Redis 部分其实有一条很清楚的线：先讲 Redis 在应用中的用法，比如缓存层、消息队列、会话和计数器；再讲什么数据值得缓存，也就是热点数据和冷数据；继续往下是数据结构、持久化、事务、分布式锁；最后进入缓存一致性、雪崩击穿穿透、主从复制、哨兵和切片集群。

这篇不再拆一个新概念，而是把这些内容串起来。你可以把它当成专题收束篇：回答 Redis 问题时，先讲场景，再讲机制，再讲边界，最后讲取舍。这样比把知识点一股脑倒出来更像真实工程思路。

一个好的 Redis 回答，不应该从命令开始。先讲场景。文中说 Redis 可以用作缓存层，存储频繁访问的数据，提高访问速度；也可以通过发布订阅模式传递消息；还可以存储会话数据、计数器等。

这几个场景都指向同一个特点：Redis 适合高频、短路径、内存友好的数据访问。缓存层用来减少数据库压力；会话存储用来快速校验登录态；计数器用原子递增承接高频统计；发布订阅适合做轻量通知。

回答时可以先把 Redis 定位说清楚：它不是替代 MySQL 的万能存储，而是加速访问、承接热点、保存轻量状态的内存系统。这个定位一旦说准，后面讲数据结构和高可用才有落点。

资料 对热点数据和冷数据的定义很简单：热数据是访问次数较多的数据，冷数据是访问很少或者从不访问的数据，只有热数据缓存才有价值。这个点可以自然接在应用场景后面。

为什么不是所有数据都缓存？因为 Redis 内存有限。高频访问的数据放进缓存，能提高命中率，减少数据库回源；低频冷数据长期占用缓存，只会浪费内存，还可能挤掉真正有价值的热点数据。

面试里如果被问缓存设计，可以把判断标准说出来：看访问频次、命中率、回源成本、更新频率和数据是否可重建。高频、集中、可重建的数据适合缓存；强一致业务事实仍然要以 MySQL 为准。

Redis 不是只有普通 key-value。资料 前面列了 String、List、Hash、Set、Zset 以及底层结构，比如 SDS、哈希表、整数集合、quicklist、listpack、跳表。数据结构是 Redis 能做很多业务动作的原因。

缓存字符串可以用 String，用户对象字段可以用 Hash，消息列表可以用 List，去重和集合判断可以用 Set，排行榜和按分数范围读取可以用 Zset。讲到 Zset 时，还可以带出为什么 Redis 使用跳表：实现简单，容易理解和调试，范围查询友好，插入删除表现好。

这一步回答的重点不是背名字，而是把结构和场景对应起来。Redis 好用，是因为它给了带语义的数据结构，让很多高频操作不必每次都回数据库，也不必在应用层手写一堆并发控制逻辑。

资料 对持久化讲了三类：AOF 日志、RDB 快照、混合持久化。AOF 是每执行一条写操作命令，就把命令追加到文件；RDB 是把某一时刻内存数据以二进制方式写入磁盘；混合持久化结合了两者优点。

进一步讲 AOF，还要说 Always、Everysec、No 三种写回策略。可靠性从高到低，性能从低到高。Always 每次写命令后同步写回硬盘；Everysec 每秒写回一次；No 由操作系统决定写回时机。

这里要讲边界：Redis 支持持久化，不代表它就等于 MySQL。缓存数据可以丢了重建，业务事实不能随便丢。持久化提高恢复能力，但对关键业务，还要结合主从、备份、消息日志、数据库落库和业务补偿。

文中 Redis 分布式锁的核心是 SETNX，或者更完整的 SET lock_key unique_value NX PX 10000。NX 保证 key 不存在才写入，PX 设置过期时间，unique_value 标识加锁客户端。释放时要先判断 unique_value 是否属于当前客户端，是才删除 lock_key。

这段可以回答“Redis 怎么做分布式锁”。重点说三个坑：不能没有过期时间，否则客户端异常会造成死锁；不能直接 DEL，否则可能误删别人的锁；比较 value 和删除 key 最好用 Lua 脚本放在一起执行。

Redis 事务则用 MULTI 和 EXEC。MULTI 开启事务，命令先入队，EXEC 后按顺序执行。WATCH 可以监视 key，如果提交前 key 被其他客户端修改，事务会取消。它适合 Redis 内部命令队列和乐观监视，不等同于 MySQL 的复杂事务。

Redis 和 MySQL 一起用，面试绕不开一致性。文中讲了 Cache Aside、Read/Write Through、Write Behind。Cache Aside 是读时先查缓存，未命中查数据库并回填；写时先更新数据库，再让缓存失效。

Read/Write Through 是让缓存代理后端存储，应用把后端看成单一存储。Read Through 由缓存服务自己加载数据；Write Through 由缓存层同步更新缓存和数据库。Write Behind 则是先更新缓存，再异步批量写数据库，写入快，但不是强一致，可能丢数据。

回答时要回到原则：MySQL 保存最终业务事实，Redis 负责加速和轻量状态。常规业务优先 Cache Aside；希望缓存层透明代理时再考虑 Through；追求写入速度且能接受最终一致和丢失风险，才考虑 Write Behind。

资料 也讲了缓存雪崩、击穿、穿透。雪崩是大量缓存同时失效，请求直接打到数据库；击穿是某个热点 key 失效后，大量并发请求同时回源；穿透是请求缓存和数据库都不存在的数据，每次都打到数据库。

这三个问题可以放在一致性之后讲，因为它们都是缓存层失效或没有命中的后果。雪崩可以通过分散过期时间、永不过期加后台刷新来缓解；击穿可以用互斥锁或热点预热；穿透可以用参数校验、空值缓存或布隆过滤器。

这里不要只背定义。最好说出业务场景：活动页配置同时过期容易雪崩，爆款商品 key 过期容易击穿，恶意构造不存在 id 容易穿透。能把场景讲出来，说明你理解缓存为什么会伤到数据库。

最后再讲 Redis 集群。资料 对三种模式的概括是：主从复制把一个 Redis 实例的数据复制到其他实例，主节点把写操作传播到从节点；哨兵监控 Redis 实例状态，发现主节点故障并自动故障转移；切片集群把数据分布在不同服务器上，降低系统对单主节点的依赖。

主从复制解决副本和读扩展，但主节点故障还要切换；哨兵在主从基础上解决自动故障转移；切片集群解决单主容量和写压力瓶颈，通过分片实现横向扩展。

选型时按问题来：只需要副本和读扩展，先上主从；需要自动故障转移，加哨兵；数据量或写压力超过单主能力，再考虑切片集群。这样回答比直接说“Redis Cluster 高可用”更准确。

第一句讲场景：我们用 Redis 主要做缓存、会话、计数和轻量消息通知，核心价值是把高频访问放到内存里，减少数据库压力。

第二句讲机制：Redis 通过丰富数据结构支撑不同业务动作，通过 RDB、AOF、混合持久化提升恢复能力，通过分布式锁和事务处理一部分并发控制问题。

第三句讲边界：Redis 不替代 MySQL，缓存一致性常用 Cache Aside，关键事实仍以数据库为准；Pub/Sub 不是可靠消息队列，Write Behind 不是强一致方案。第四句讲取舍：规模上来后，用主从、哨兵、切片集群分别解决副本、故障转移和横向扩展问题。

如果面试官让你整体讲 Redis，可以先从应用场景讲起：Redis 常用于缓存层、会话、计数器和发布订阅，适合高频访问、短路径、可重建或轻量状态数据。不是所有数据都值得缓存，热点数据才有价值，冷数据长期占用 Redis 会浪费内存。

再讲核心机制：Redis 有 String、Hash、List、Set、Zset 等结构，Zset 底层用跳表适合范围查询；持久化有 RDB、AOF、混合持久化，AOF 写回策略 Always、Everysec、No 在可靠性和性能之间取舍；分布式锁用 SET NX PX 加 unique_value，释放时要校验再删除；事务用 MULTI、EXEC、WATCH。

最后讲系统设计：缓存和数据库一致性常用 Cache Aside，读缓存未命中回源，写时先更新数据库再让缓存失效；雪崩、击穿、穿透要分别治理；高可用从主从复制、哨兵到切片集群逐步演进。收尾强调 MySQL 保存最终业务事实，Redis 负责加速访问和轻量状态。