1. Redis 面试到底在考什么“Redis 面试题”这四个字在技术面试里的出场率快赶上 Java 基础了。我这些年面过不少候选人也帮朋友做过模拟面试发现一个规律大家对 Redis 的基本概念背得滚瓜烂熟什么“高性能键值存储”“内存数据库”“支持五种数据类型”张口就来但一旦我问到“为什么快”“内存满了怎么办”“缓存和数据库一致性怎么搞”就明显露怯了。所以这篇不是把常考知识点简单列一遍而是把这些点背后的原理、取舍、真实项目里踩过的坑用做业务时实际会遇到的方式重新捋一遍。不管你是准备面试还是刚把 Redis 部署进测试环境都能从里面找到点能用得上的东西。面试官喜欢考 Redis本质上是因为它足够“小”但又有足够多的“纵深”。从一条命令到分布式锁从单线程模型到集群扩容任何一层都能挖出大量值得聊的东西。换句话说Redis 是少数几个能把“会背八股”和“真懂原理”明显区分开的技术。理解这一点你就能明白为什么面试官总在这里没完没了地追问。2. 数据类型与底层结构高频考点的重灾区2.1 String、Hash、List、Set、ZSet 的核心考题标准的 Redis 面试题上来一定是问你有哪些数据类型。这里大多数人能答出五种String、Hash、List、Set、ZSet。但面试官真正的意图往往在后面你凭什么选它它的应用场景是什么底层是怎么存的我通常建议候选人从“使用场景反推类型”来回答这样显得更像做过项目String最基础的类型适合缓存一个值、计数器、分布式 ID、Session 等。底层可以是 int、raw、embstr 三种编码注意整数的自增自减是原子的可以用来做秒杀库存、点赞数。Hash适合存对象比如用户信息、商品详情。相比 String 存 JSONHash 可以单独更新某个字段省流量也更符合 Redis 的“原子操作某个属性”的使用方式。List底层是双向链表适合做消息队列、时间轴、关注列表等。可以用 LPUSH BRPOP 实现简单的可靠消息队列。Set无序、去重适合做标签、好友关系、抽奖、共同关注。SINTER、SUNION 这些集合运算在社交场景非常实用。ZSet有序集合每个元素带一个 score适合排行榜、延迟队列、限流窗口。这个类型在面试中出现频率极高因为它的底层跳表skip list经常被拿来追问。2.2 底层编码与数据结构切换这是很能区分“背过”和“理解”的考点。Redis 对每个 value 并不是固定用一种数据结构存储而是根据元素数量和元素大小做“编码优化”。比如 Hash 如果元素较少且值较小底层用 ziplist紧凑列表当超过阈值后转换为 hashtable。ZSet 在数据量小时也是 ziplist超过zset-max-ziplist-entries后转为 skiplist dict 的组合。能讲清楚这件事的候选人至少说明他真看过object encoding的输出而不只是背教材。实际使用中如果你批量写入大量小字段的 Hash压缩编码可以显著减少内存开销。这也是为什么 Redis 官方一直强调“小 Hash 比大 JSON 字符串更省内存”的原因。面试时如果能顺势提一嘴redis-cli --bigkeys或者DEBUG OBJECT查看编码转换会是个不错的加分项。3. 持久化RDB 和 AOF 的取舍是第一道深水区3.1 RDB 快照的触发与原理面试官问你持久化不是真想知道你会不会配save 900 1而是想知道你如果负责一个 Redis 实例你选择哪种持久化方案、为什么、挂了你怎么办。RDB 是内存数据的全量快照默认生成 dump.rdb。它的优点非常明显文件紧凑恢复速度快适合做备份和灾难恢复。缺点同样致命最后一次快照之后的数据可能丢失。RDB 的触发方式有手动 BGSAVE、自动 save 配置、主从同步时从节点加载、以及 SHUTDOWN 时触发等。生产环境里RDB 做主从全量同步的载体非常方便。但如果你对数据丢失容忍度很低就不能只靠 RDB。面试时说到 RDB建议主动提一下fork()和 Copy-On-Write因为 Redis 的 RDB 生成依赖操作系统的 forkfork 期间如果父进程内存被大量修改会复制页表产生额外内存开销。这是一个经典的追问点而且很多人在实际部署时才意识到“为什么 Redis 内存占用 6G突然 RSS 到了 9G”。3.2 AOF 重写与 fsync 策略AOF 则是追加写命令日志恢复时逐条执行命令。它比 RDB 更可靠但文件会越来越大所以有 AOF rewrite 机制。AOF 的appendfsync有三种策略always、everysec、no。我一般推荐生产环境用everysec性能和数据安全的平衡最好——最多丢一秒的数据而不会像 always 那样每条写都 fsync导致吞吐下降明显。关于 AOF 重写有几个细节值得记住重写不是基于现有 AOF 文件做压缩而是基于当前内存中的数据生成最小写命令集然后后台子进程执行完成后替换旧文件。重写期间新来的写命令会同时写入 AOF 缓冲区不会被丢掉。如果面试官追问“AOF 文件损坏了怎么办”答案是 Redis 提供了redis-check-aof工具修复模糊了就不好答了。3.3 混合持久化4.0 之后的默认选项Redis 4.0 引入混合持久化AOF 重写时直接把 RDB 二进制格式作为文件头后面再接增量命令日志。这样兼顾了 RDB 的快速加载和 AOF 的低丢失率。我用过的很多生产实例都开了aof-use-rdb-preamble yes重启加载速度肉眼可见地快。这里有个面试常见问法“RDB 和 AOF 能同时开吗”当然可以而且 Redis 启动后加载优先顺序是 AOF 优先。因为 AOF 文件的数据完整性更高。知道了这些你就能在面试时把持久化讲成一个完整的决策模型而不是两条干巴巴的特性列表。4. 过期策略与内存淘汰面试必考的“内存治理”4.1 惰性删除与定期删除Redis 的 key 过期不是一到时间就立刻被物理删除而是依靠两种机制配合惰性删除当客户端访问一个 key 时Redis 会检查它是否过期如果过期就删除并返回空。定期删除Redis 每隔一段时间默认 100ms随机抽一批设置了过期时间的 key检查是否过期如果过期就删除。为什么不定时全量扫描因为 keys 可能非常多全量扫描会阻塞主线程影响性能。所以采用了“随机抽样 循环检查”的妥协策略。这带来的问题就是过期的 key 如果没有被访问也没有被定期扫描选中就会一直残留在内存里。长时间下去内存占用会虚高这也是生产环境内存监控要关注expired_keys指标的原因。4.2 八种内存淘汰策略怎么选Redis 默认内存上限是 0表示不限制实际上受物理内存限制。当maxmemory配置后内存满了就需要淘汰。常见的策略可以分为几类策略含义noeviction内存满了直接报错不淘汰任何 keyallkeys-lru从所有 key 中按 LRU 近似算法淘汰volatile-lru从设置过过期时间的 key 中按 LRU 淘汰allkeys-lfu从所有 key 中按访问频率淘汰Redis 4.0volatile-lfu从设置过过期时间的 key 中按频率淘汰volatile-random从设置过过期时间的 key 中随机淘汰allkeys-random从所有 key 中随机淘汰volatile-ttl从设置过过期时间的 key 中淘汰剩余 TTL 最短的我个人的经验是如果是纯缓存场景用allkeys-lru就够了因为你不希望 Redis 因为某些“从不设置过期时间”的永久 key 把内存撑爆后直接拒绝写入。如果是有真实数据落地的场景需要谨慎别依赖淘汰机制来清理数据。4.3 近似 LRU 和真正的 LRURedis 的 LRU 并不是严格 LRU而是“采样 LRU”。它会对随机抽取的 N 个 key 比较空闲时间淘汰最久未被访问的。默认采样数是 5配置项是maxmemory-samples。采样数越大结果越接近标准 LRU但 CPU 消耗也越高。面试官如果问“Redis 的 LRU 和传统 LRU 有什么区别”你只要点出“抽样 近似”关键词再提一句 Redis 4.0 之后还支持 LFU按访问频率淘汰就能证明你对这块有实际研究过。5. 缓存三大坑穿透、击穿、雪崩5.1 缓存穿透与布隆过滤器缓存穿透是指查询一个“数据库和缓存里都不存在的数据”。由于缓存没有该 key请求直接打到数据库如果量很大数据库会被压垮。常见的方案有三种缓存空值把查询结果为 null 也缓存一份设置较短的过期时间比如 60 秒避免每次穿过。布隆过滤器在缓存前加一道过滤网如果 key 一定不存在就直接返回不再访问缓存和数据库。参数校验对非法参数直接拦截比如id 0直接返回错误。布隆过滤器是高频考点。它的核心思想是使用多个哈希函数将一个 key 映射成多个位数组下标并把这些位设置为 1。查询时如果任何一个对应位是 0则 key 必定不存在如果都是 1则可能存在误判。用数学话讲就是“宁可错杀三千不可放走一个”——有一定的误判率但不会漏报。真实项目中可以用 Guava 的 BloomFilter也可以直接用 Redis 的 BF 模块RedisBloom。5.2 缓存击穿与互斥锁缓存击穿是指某个热点 key 在过期的一瞬间大量并发请求同时发现缓存中没有数据于是全部打到数据库上。注意它和穿透的区别穿透是“没有这个数据”击穿是“有这个数据但刚好过期”。解决击穿最经典的方法是互斥锁Mutex当缓存没有数据时不是所有线程都去查数据库而是先尝试获取分布式锁只有拿到锁的线程才去查数据库并回填缓存其他线程等待一段时间后重试从缓存读取。为了避免拿到锁的线程在写入缓存前挂掉还要给锁设置合理的过期时间。另一种方案是逻辑过期缓存中不设置 TTL而是在 value 中保存一个逻辑过期时间字段。每次读取时检查逻辑时间是否过期如果过期则尝试获取锁去重建缓存但读请求依然能拿到旧数据返回。很多高性能场景用这个方案因为它不会短时间阻塞请求但也带来了数据短暂不一致的风险。5.3 缓存雪崩与集群、降级雪崩是“大量 key 同时过期”或者“Redis 服务整个宕机”导致所有请求都涌入数据库。针对大量 key 同时过期的情况解决方案比较简单给过期时间加一个随机值比如基础过期时间上增加 1-5 分钟的随机偏移避免同一时刻集体失效。针对 Redis 宕机的情况就需要高可用方案了主从 哨兵、Cluster 集群、多级缓存、本地缓存兜底以及接口层的熔断降级。面试时能说出“根据业务场景缓存层不可用时可以采用多级缓存兜底最坏情况通过降级开关返回默认值而不是让用户看到 500”就比单纯背“集群”高一个档次。6. 事务与分布式锁从一道命令到分布式系统的门槛6.1 事务与 Lua 脚本原子性到底是什么意思Redis 的事务用 MULTI、EXEC、DISCARD、WATCH 来实现。它和执行关系型数据库事务完全不同它不保证回滚只是把命令按顺序打包执行。如果事务块中的某一条命令语法错误整个事务会被拒绝但如果运行时报错比如 incr 一个字符串值前面的命令已经执行也不会回滚。很多人会把这个弄混。而真正的“原子性操作”我用得最多的是Lua 脚本。因为 Redis 服务器是单线程模型一个 Lua 脚本在 Redis 里执行时不会插入其他命令所以天然是原子的。Redis 官方也推荐用 Lua 来组合多个命令完成复杂操作。比如库存扣减/恢复、限流、延迟队列等都很适合用 Lua。面试时如果候选项能主动说出“MULTI 的原子性只是隔离不是故障回滚要保证多命令原子执行用 Lua”我基本会认为他真在项目里写过。6.2 分布式锁从 SETNX 到 RedLock分布式锁是 Redis 面试的另一个高频点。考察的核心从“怎么实现一个锁”延伸为“怎么保证锁的可靠性”。最简单的方式是 SETNX 过期时间命令是SET key value NX EX 10。其中 NX 表示只有当 key 不存在时才设置成功EX 设置过期时间。这里有个经典的坑很多人用两条命令SETNX再单独EXPIRE如果程序在两条命令之间崩溃锁就没有过期时间导致死锁。正确写法是上面这条原子命令。再升级一点锁的 value 必须是唯一标识比如 UUID释放锁时需要先判断 value 是不是自己的再删除。为什么因为如果锁过期了别的线程重新获取了锁你如果直接 DEL就会把别人持有的锁释放掉。所以释放锁要借助 Lua 脚本保证“GET 判断”和“DEL 删除”的原子性。再往深一层单机 Redis 锁存在主从切换时丢失锁的风险。Redis 之父 Antirez 提出了 RedLock 算法要求向多个独立的 Redis 节点依次申请锁超过半数成功才算获取锁。RedLock 在业界一直有争议很多专家说它并不是百分之百安全但这是一个很好的谈资。面试时能讲出“RedLock 的基本思想 争议点”绝对能加印象分。7. 高可用架构主从、哨兵、Cluster7.1 主从复制的原理与断点续传面试提到主从肯定会问复制原理。基本的流程是从节点发送 PSYNC 命令给主节点。主节点执行 BGSAVE 生成 RDB 快照同时把新写命令缓存到复制缓冲区。主节点将 RDB 文件发送给从节点从节点加载后再接收缓冲区的增量命令。Redis 2.8 开始支持部分重同步Partial Resynchronization也就是断点续传。主从之间复制时会维护一个 replication ID 和 offset如果网络抖动从节点重连后可以尝试用PSYNC replid offset继续从断点开始同步而不是重新全量复制。这个设计在日常运维里非常有用否则每次网络闪断都要全量同步主节点压力巨大。还有一个考点是主从复制是异步的这意味着如果你在主节点写入了数据从节点还没复制完这个时候如果主节点宕机哨兵提升一个从节点为主节点那部分最新数据可能会丢失。这也是 Redis 高可用下的一致性与可用性权衡。7.2 哨兵机制自动故障转移怎么工作Redis Sentinel 是 Redis 高可用的核心组件。它负责监控主从节点的状态当主节点挂了之后自动选择一个从节点升级为主节点并把其余从节点重新指向新主节点同时通知客户端新主节点地址。哨兵本身是一个集群一般至少部署 3 个节点用 Raft 风格协议协调“主观下线”和“客观下线”。当某个哨兵发现主节点不可达时标记为主观下线当多个哨兵超过 quorum 配置都认为主节点不可达时才认为客观下线然后开始选举 leader由 leader 执行故障转移。一个常考的问题从节点选举的依据是什么主要看优先级slave-priority、数据偏移量replica offset越大越优先、运行 ID 越小越优先。这个顺序需要记住能体现你对运维细节的理解。7.3 Cluster 集群的槽位分布Redis Cluster 是官方提供的分布式解决方案。数据自动分片到 16384 个 slot 上每个节点负责一部分 slot。key 通过 CRC16 算法计算出 slot然后根据 slot 定位到对应节点。Cluster 里有个坑如果使用mset或mget这类多 key 命令要求这些 key 都属于同一个 hash slot否则会报 CROSSSLOT 错误。解决方法是使用哈希标签hash tag比如{user:100}.name和{user:100}.age只要花括号中的内容一致这些 key 就会被分配到同一个 slot。面试常见追问还包括Cluster 节点间怎么通信Gossip 协议Cluster 是否完整支持事务和 Lua 脚本要保证涉及的 key 在同一个节点上集群扩容/缩容时数据迁移使用 MIGRATE 命令Cluster 模式下的客户端路由smart client等。8. 序列化与编码从存到取的隐蔽问题8.1 为什么 Redis 需要序列化点击热搜词里的“redis序列化”说明这个点很多人搜过确实是实战里躲不开的问题。Redis 本身只支持字符串但业务上我们往往要存对象、列表、Map。所以需要在写入之前把对象变成字节数组或字符串读取后再反序列化成对象。常见的序列化方案有JDK 原生序列化直接实现 Serializable简单但序列化后的体积大可读性差而且 Java 特有的类型会污染 Redis 里的可视化面板。JSON 序列化如 Fastjson、Jackson、Gson。可读性好但需要存储类型信息否则反序列化时泛型可能丢失。某些 JSON 库在序列化 LocalDateTime 等类时还要写自定义处理器。Protobuf / Kryo / Hessian性能好体积小但调试不直观需要额外维护 schema 或注册类。我自己的经验是如果项目里用 Spring Data Redis默认的 JdkSerializationRedisSerializer 在管理端看起来全是\xAC\xED\x00\x05t...排查问题非常痛苦。一般都会改成 GenericJackson2JsonRedisSerializer或者结合自定义 ObjectMapper。面试时能聊到这里说明你是真碰过生产问题。8.2 可视化工具与连接工具的选择很多同学问“redis desktop manager 下载”“another redis desktop manager”这类问题说明在实际开发中可视化工具变成了刚需。Redis Desktop Manager 是早期用得最多的 GUI后来又出现了 Another Redis Desktop Manager开源免费且跨平台支持更好。如果你在 Windows 上开发也可以用它连接远程 Redis查看 key、执行命令、订阅频道比 redis-cli 直观得多。连接 Redis 时要注意生产环境一定不要暴露 Redis 到公网不要用默认端口不设密码就跑。可视化工具推荐配置 SSH 隧道或者通过跳板机访问而不是直接开 6379 端口公网监听。这是个不太像“面试题”但却是面试官心里很想确认的工程素养。9. 面试高频追问内存模型、阻塞排查与性能优化9.1 为什么 Redis 单线程还这么快几乎所有 Redis 面试都会聊“单线程为什么快”。答案的核心并不是“单线程所以快”而是Redis 基于内存数据访问没有磁盘 IO 延迟采用 IO 多路复用epoll单线程可以处理大量连接避免多线程上下文切换和锁竞争数据结构本身是经过高度优化的。但 Redis 6.0 后开始支持多线程 IO 来处理网络读写因为网络 read/write 已经成为单线程模型的瓶颈。注意多线程只用于 IO 读写命令执行还是单线程的。所以如果有人问“Redis 7.0 是不是多线程了”你可以分两层回答IO 线程可配置核心的命令执行依然是主线程串行。9.2 线上 Redis 变慢了怎么排查面试里常把你丢到一个场景“线上 Redis 突然出现很多慢查询你怎么排查。”这个问题的正确姿势是从“Redis 是单线程执行命令”这个前提去推导先用SLOWLOG GET查看慢日志定位具体是什么命令慢。看看是不是 keys 全量扫描或运算复杂度太高的命令比如 KEYS、HGETALL、ZRANGE 大范围查询。检查 big key 是否过多因为大 key 的删除、序列化、网络传输都会阻塞主线程。通常用--bigkeys扫描。大 key 删除要用UNLINK而不是DEL避免阻塞。检查是否存在集中过期INFO memory里的expired_keys上涨是否异常。检查是否开启了 AOF 且 fsync 策略为 always或者 AOF 重写期间父进程内存压力增大。检查系统内存是否触发 swap如果 Redis 使用的内存被换到磁盘性能会急剧下降。还有一类阻塞问题是 fork 阻塞RDB 生成时如果内存过大fork 过程会影响主进程。通常建议控制单个 Redis 实例内存不超过 8-10G同时用云主机的物理内存不要用 swap。9.3 缓存与数据库一致性怎么回答这个几乎必考。比较稳妥的回答框架是读操作先读缓存读不到读数据库再回写缓存。写操作先更新数据库再删除缓存Cache Aside Pattern。而不是先删缓存再更新库因为两个操作之间有并发窗口容易导致缓存里是旧数据。为什么是“删除缓存”而不是“更新缓存”因为更新缓存成本高且容易因为并发导致后写覆盖先写删除缓存后下一次读的时候再回填更安全。如果严格要求强一致则需要引入消息队列或订阅 binlog如 Canal通过异步方式更新/删除缓存但绝大多数业务不需要强一致只需要最终一致。能把这个逻辑讲清楚并承认“没有绝对一致只有最终一致”面试官通常都会点头。10. 部署安装中的知识串讲现在很多应届生在学校里用的是 Windows 版 Redis工作后用 Docker 部署面试官也会问一些部署相关的问题。热搜词里“redis安装”“docker 安装 redis 主从”“windows 版本 redis 下载”出现频率很高说明大家确实经常在这上面踩坑。Windows 上的 Redis 通常是微软移植版版本会滞后于 Linux 官方版。如果你只是想本地学习直接去官方 GitHub releases 里下 zip 包解压用。但生产环境一定要用 Linux或者用 Docker 跑官方镜像redis:7.0、redis:6.2。注意官方镜像默认没有配置文件推荐挂载自定义 redis.conf并开启appendonly yes。启动容器时至少要考虑三点数据卷挂载防止容器重建后数据丢失端口映射最好只绑定内网 IP比如-p 127.0.0.1:6379:6379设置密码用requirepass配置或者用命令行的--requirepass。主从部署时用 Docker Compose 同时编排主节点和从节点非常方便从节点通过replicaof 主节点容器名 6379建立复制关系。注意主从节点在同一个 Docker 网络内可以直接用服务名解析跨宿主机部署时则要填真实 IP。这些知识点听起来和“常考知识点”关联不强但实际面试中你有无部署经验几句话就能听出来。所以我建议把这部分和前面的理论串起来能配置主从你才算真的会“高可用”。11. 面试实战中的答题技巧最后聊一点面试答题的技巧吧这部分不是 Redis 知识点本身但对面试结果影响很大。第一回答要“有结构”。不要说一堆零散的词试试“观点 原理 场景 坑”的结构。比如谈到持久化你可以说“我会看业务对数据丢失的容忍度如果允许丢分钟级数据用 RDB 做定时备份如果最多丢一秒数据就开 AOF everysec还可以混合持久化兼顾加载速度和安全性。我们生产就遇到过 BGSAVE 时内存毛刺变高后来把单实例内存控制在 6G 内才缓解。”这段话比背十句教材都有说服力。第二学会反问边界。面试官问“Redis 最多支持多少 key”不要盲猜数字可以先反问“您是指单实例还是集群key 大小有没有限制”来体现思维缜密。实际答案不是数量而是受内存限制一个 key 的 value 最大是 512MB。第三不要装懂。面试官问到 RedLock、Gossip、ziplist 细节等如果只是听说过名称就坦诚说“我了解它大概的原理但没有在生产中实践过”比强行编造好得多。工程岗面试更看重“知道边界在哪里”而不是无所不知。我自己筛候选人时最后常常问一句“如果让你自己搭一套 Redis 缓存方案你会怎么设计”能把“选型→部署→监控→备份→故障恢复→压测”说出一套完整链路的人基本都会被录用。这也是我整理这份知识点解析的底层逻辑知识点是用来解决问题的不是用来背诵的。希望这份解析能帮你把零散的知识点重新串成体系下一次不管是面试官提问还是线上 Redis 报警你都能更自信地应对。