Redis是面试中绕不开的一道坎。不管是校招还是社招无论你简历上写的是Java、Go还是Python只要提到缓存、分布式、高并发Redis总会作为最常被追问的中间件出现。我自己面试别人和被别人面的次数都不少发现很多人把Redis命令背得滚瓜烂熟但一问到底层实现、持久化机制、分布式锁到底怎么设计就支支吾吾说不出所以然。这篇把Redis常考的知识点完整串一遍结合我实际踩过的坑以及面试官真正想听的点整理成一份可以反复翻的复习笔记。内容尽量按“原理-场景-坑”的方式来写方便你和实际项目对应起来。1. 为什么Redis常考先搞清楚它解决了什么问题1.1 Redis是什么从缓存到中间件的定位Redis全称Remote Dictionary Server典型定位是基于内存的键值存储系统。很多同学把它等同于“缓存”这没有错但如果你在面试里也只说“Redis就是缓存”那基本就给自己挖坑了。因为Redis真正厉害的地方在于它既能当缓存用也能当消息队列、分布式锁、排行榜、计数器、会话存储、分布式ID生成器来用。把这些场景列出来面试官才会觉得你是真的理解Redis。从数据模型上看Redis不像Memcached那样只能存字符串而是提供了String、Hash、List、Set、ZSet等丰富的数据结构。这些结构不是装饰品每一种都有专门的底层设计和典型场景。比如ZSet用跳表实现天然适合排行榜List底层有quicklist适合消息队列场景Bitmap可以用极小空间做用户签到HyperLogLog可以做UV统计。所以说Redis是一个“数据结构服务器”一点也不夸张这也是它和普通缓存最大的区别。再说说它基于内存这个特点。内存的访问速度是纳秒级别的比磁盘快几个数量级所以Redis单实例能扛住十万级QPS。但“快”不是没有代价的内存成本高、容量有限后续的持久化、淘汰策略、集群方案都是为了在内存的局限性和数据可靠性之间做权衡。面试官常问“Redis为什么快”其实就是在考察你对内存、IO模型、数据结构底层这三个层次的认知。1.2 单线程模型为什么快哪些场景会变慢Redis常被提到的另一个标签是“单线程”。在Redis 6.0之前网络IO和命令执行都是单线程的6.0引入了IO多线程但命令执行仍然是单线程。面试最容易问的一个问题是单线程为什么还能这么快答案要从几个层面看。第一基于内存存储。这是最直接的优势不需要磁盘寻址和旋转延迟数据读写都在内存里完成。第二使用了IO多路复用机制。Redis自己封装了一个事件处理器通过epoll等系统调用同时监听大量客户端连接把网络读写事件压入队列然后逐一处理。第三单线程避免了线程切换和锁竞争的开销。对于纯内存操作来说CPU不是瓶颈线程切换反而会更慢所以单线程模型在这种情况下反而更高效。但是单线程模型也意味着一条慢命令会阻塞后面所有命令。我见过不少线上事故都是因为执行了KEYS *、HGETALL一个超大Hash、SMEMBERS一个超大Set或者包含复杂计算的Lua脚本直接把Redis卡死。所以你在项目里要养成习惯生产环境禁用KEYS命令可以用SCAN分批扫描对大Key进行拆分或者压缩用info clients和slowlog去定位慢查询。面试时如果能在“为什么快”后面主动说出“所以要注意慢命令”会让面试官觉得你真的有实战经验而不只是背了八股。2. 核心数据结构面试第一关就是这五种2.1 五种基础类型的底层实现与适用场景String最基础但绝不是“存字符串”这么简单。它的底层是SDSSimple Dynamic String相比C语言原生字符串多了长度记录、空间预分配、惰性空间释放等能力所以获取长度是O(1)的而且可以安全地做append、截断等操作。String之所以常考是因为很多场景都基于它缓存对象、分布式锁、计数器、限流、分布式ID。比如INCR命令能保证原子自增这正是秒杀库存、点赞数、访问量最常用的方案。Hash可以理解成一个内存版的“小对象”。它的底层在数据量小的时候是压缩列表ziplist当字段太多或某个value过大时会转成hashtable。Hash适合缓存对象比如用户信息、商品详情这样你可以只修改某个字段而不需要把整个JSON字符串读出来再序列化回去。很多人纠结用String存JSON还是用Hash存对象我的建议是需要频繁修改部分字段时用Hash整体读写比较多时用String大对象还要考虑内存碎片和序列化成本。List底层是quicklist融合了双向链表和压缩列表的优点。它的典型场景是消息队列、时间线列表、最新事件。不过现在做消息队列更推荐Stream因为List的BRPOPLPUSH在消费确认、消息堆积、回溯上并不完善但简单的异步任务列表用List仍然很方便。ZSet是面试里的重头戏底层是跳表哈希表跳表负责按分数排序和范围查询哈希表负责按成员取分数。它的经典场景是排行榜、延时队列、带权重的任务调度。这里要记住ZSet的底层结构因为面试官非常喜欢问“为什么用跳表而不是红黑树”。2.2 高级结构Bitmap、HyperLogLog、GEO到底怎么用除了五种基础类型Redis还提供了几个高级数据结构因为日常开发中确实能用上也经常被当作加分项来问你。Bitmap不是独立类型底层是String的位图操作。一个字节有8位SETBIT/GETBIT命令可以在O(1)时间设置和读取某一位。典型场景是用户签到、在线状态、布隆过滤器的雏形。比如统计一个月内连续登录天数用Bitmap可以做到极低的内存占用10万用户每天占用的空间只有约12KB。面试题“一亿个用户统计今天活跃用户数”就可以用它回答。HyperLogLog用于基数统计也就是去重计数。它的神奇之处在于无论存多少元素标准误差只有0.81%左右且每个键最多占用约12KB内存。比如UV统计每天几千万的访问量如果精确用Set存储会非常耗内存用HyperLogLog几乎可以忽略内存成本。当然它不能精确统计也不能获取具体有哪些元素这个限制要心里有数。GEO是Redis 3.2引入的底层用ZSet实现支持经纬度存储、范围查询、距离计算。比如附近的人、外卖商家距离排序就会用到它。面试中提到GEO时要能说出它的实现方式是对经纬度做GeoHash编码然后作为ZSet的score来排序这样才显得不是只听过名词。Stream则是Redis 5.0引入的消息队列模型支持消费者组、ACK确认和消息回溯适合轻量级可靠性要求不太极端的生产消费场景。3. 持久化机制RDB和AOF怎么选3.1 RDB快照的原理与触发方式Redis作为缓存时很多人以为它不需要持久化但生产环境里如果进程宕机或者服务器重启缓存全丢紧接着就可能出现缓存雪崩数据库被打挂。所以Redis默认开启了RDB持久化它的原理是定期生成一个内存数据的全量快照文件dump.rdb。RDB的触发方式有几种手动执行SAVE或BGSAVE或者配置save规则自动触发。SAVE是同步阻塞的生产环境基本不用因为会阻塞所有客户端。BGSAVE会fork一个子进程去生成快照Redis主进程继续处理命令。这里有个常见考点fork出的子进程是怎么拿到内存快照的答案是用操作系统的写时复制Copy-On-Write机制。fork瞬间子进程共享父进程的物理内存当主进程要修改某个页时会先把该页复制一份再修改这样子进程看到的仍是fork时刻的内存状态。正因如此RDB生成过程中内存占用会短暂上升如果机器内存紧张可能触发系统OOM这是实操中要特别注意的。RDB的优点是文件紧凑、加载速度快适合做灾备和全量恢复。缺点是它只能保存到某个时间点的快照两次快照之间的数据可能丢失同时fork子进程在大数据量下会有额外的CPU和内存开销。所以生产上一般会用RDB做定时备份再用AOF保证秒级数据安全。3.2 AOF日志的重写与刷盘策略AOFAppend Only File记录的是每一条写命令的日志恢复时把日志里的命令重新执行一遍就能还原数据。它比RDB丢失数据更少但文件体积会持续增长所以必须有重写机制。AOF的刷盘策略由appendfsync配置控制可选值有always、everysec、no。always表示每条写命令都同步刷盘最安全但性能最差everysec是每秒刷一次最多丢一秒数据性能和数据安全比较均衡默认配置就是它no是把刷盘交给操作系统性能最好但丢失数据的时间不可控。实际业务中如果对数据敏感度不是极高选everysec就够了如果真到了银行转账这种级别建议直接考虑其他存储方案因为always的性能代价太大不一定扛得住。AOF重写不是对原文件做压缩而是Redis会fork一个子进程根据当前内存中的数据生成最少必要命令写到一个新的AOF文件里然后替换旧文件。比如同一个Key被set了一百次重写后只保留最后一次set。这里要说一个常见误区手动执行BGREWRITEAOF会消耗资源所以在写脚本自动重写时一定要避开业务高峰期。3.3 混合持久化与恢复流程Redis 4.0之后引入了混合持久化默认开启时AOF文件的前半部分是RDB格式的二进制快照后半部分是从快照时刻到最新状态的增量命令日志。这样重启时先把RDB快照直接加载到内存再重放增量命令比纯AOF重放要快得多。恢复的时候Redis启动会优先加载AOF文件因为AOF数据更完整如果AOF文件不存在再尝试加载RDB。这里有两个很实战的点一是AOF文件如果损坏Redis可能启动失败官方提供了redis-check-aof工具可以修复二是加载大RDB时Redis会短暂阻塞所以要监控启动日志和数据量避免在恢复期间造成服务长时间不可用。我自己的习惯是在云上部署Redis时RDB做整点备份到对象存储AOF通过everysec策略保证实时性重要数据做定期全量验证恢复不能只看到dump文件生成就觉得万事大吉。面试时如果能把RDB和AOF的优缺点、恢复优先级、fork和写时复制讲清楚基本就能拿满这个部分的分。4. 高可用与扩展主从、哨兵、集群4.1 主从复制的完整流程单机Redis存在可用性和容量瓶颈所以主从复制是绕不开的话题。主从复制的基本流程是从节点执行SLAVEOF命令新版本叫REPLICAOF发起同步请求主节点执行BGSAVE生成RDB把RDB传给从节点从节点加载RDB然后主节点把后面的写命令同步给从节点。这里面试官常问细节比如“全量复制和部分复制是怎么区分的”。在Redis 2.8之前断线重连只能做全量复制之后引入了部分复制依赖三个核心要素主节点的replid复制ID、复制偏移量offset、复制积压缓冲区backlog。从节点断线重连后带上自己当前的offset和replid主节点判断offset是否还在backlog里如果在就只把这段增量数据发给从节点如果断了太久backlog已经被覆盖就只能做全量同步。有几点实战启示第一backlog大小要合理设置默认是1MB在高写入场景很容易被覆盖导致从节点频繁全量同步建议估算一下网络中断时主节点一分钟的写入量把backlog调大。第二主节点在BGSAVE期间fork子进程会占用CPU和内存所以要避免在主节点压力很大时动态增加从节点。第三从节点可以做读写分离但要接受从节点的数据延迟。如果你在业务里对一致性要求极高就不能无脑把读请求都打到从节点上。4.2 哨兵的监控与故障转移有了主从复制后如果主节点挂了从节点无法自动接任需要人工切换这在生产环境是不可接受的。所以Redis提供了哨兵Sentinel机制它其实是一个独立运行的进程负责监控主从节点的健康状态并在主节点故障时自动执行故障转移。哨兵的工作原理可以拆成三步监控、选举、通知。多个哨兵节点互相通信通过PING确认主节点是否客观下线当超过一定数量的哨兵都认为主节点不可用时会开始故障转移流程先在内网中选举出一个哨兵作为leader由它从从节点里选一个提升为新的主节点同时把其他从节点重新指向新主节点。这里有一个很容易忽略的点哨兵至少部署3个实例否则可能因为脑裂产生误判。如果只部署一个哨兵它自己脑裂或者网络抖动可能就把正常的主节点判定为故障导致可用性问题。线上部署时哨兵建议和主节点分开部署避免同一台物理机挂掉连哨兵也一起挂掉。虽然现在云厂商的托管Redis已经屏蔽了哨兵细节但自己搭主从高可用时这些还是必须掌握的。4.3 Redis Cluster的槽位分配当数据量超过单机内存或者写入QPS超过单实例上限就需要Redis Cluster做水平扩展。Redis Cluster采用无中心化架构服务端每个节点都保存路由信息客户端可以访问任意节点来实现命令转发和重定向。Cluster把整个键空间划分成16384个槽位每个节点负责一部分槽位。对某个Key执行命令时先通过CRC16算法计算Key的哈希值再对16384取模得到它所属的槽位然后由节点负责路由。如果客户端连接的是错误节点会收到MOVED重定向错误客户端需要更新本地缓存的路由表。还有一种ASK重定向发生在槽位迁移过程中代表数据正在从旧节点搬到新节点需要客户端配合重试。面试问到Cluster时除了槽位分配还喜欢问“为什么是16384”。这个数字是设计权衡心跳包需要携带槽位位图16384个槽位对应2KB的空间如果改成65536个槽位位图大小变成8KB传输成本增加同时Redis节点数量一般很难超过1000个16384已经足够均匀分布。把这个原因说出来会显得你看过设计源码而不是死记硬背。5. 事务与Lua为什么说Redis事务不够“事务”5.1 MULTI/EXEC/DISCARD/WATCHRedis事务由MULTI命令开启之后输入的命令会排队EXEC时依次执行。这个过程中如果某条命令本身有语法错误整个事务所有命令都不会执行如果某条命令运行时错误比如对一个字符串执行LPUSH前面的命令已经执行成功后面的也不会回滚。也就是说Redis只保证原子性命令串行执行期间不会有其他客户端命令插入不保证传统的回滚能力。为什么会这样官方原话大意是Redis命令只有在语法错误或对错误类型使用命令时才会失败这属于编程错误理论上不应该在运行时经常发生为了支持回滚反而会让内部状态机更复杂。所以你在设计业务时不能把数据库事务的期望强加给Redis不能指望它自动回滚。WATCH命令提供了一种乐观锁机制。比如你要实现“先读一个值判断后写回”的场景可以在MULTI之前WATCH这个Key如果在事务执行期间有其他客户端修改了它EXEC会返回失败表示事务被放弃。经典应用是秒杀库存用WATCH监听库存Key事务里做减库存操作如果冲突就重试。不过实际项目里这种思路用得越来越少因为完全可以用Lua脚本或者更简单的原子命令替代。5.2 用Lua脚本保证原子性Redis支持在服务端执行Lua脚本通过EVAL命令提交脚本里的多条Redis命令会被原子执行执行期间不会插入其他命令。这就解决了“多条命令的复合操作需要原子性”的问题。比如扣减库存并记录订单可以用Lua把检查库存、扣减、记录三个操作写在一起避免并发下的超卖问题。Lua脚本还有个附加好处是减少网络开销客户端不用多次RTT往返。但要注意如果脚本有大量循环或复杂计算执行期间会阻塞整个Redis实例所以线上一定要控制脚本执行时间和循环次数。Redis 7.0之后引入了函数功能本质也是Lua脚本的扩展但这块面试问得不多。我在项目里比较常见的做法是把分布式限流、原子库存、防重复提交这类逻辑写成Lua脚本放在Redis里用EVALSHA调用。这样做一方面减少网络传输另一方面因为脚本是原子的就不需要额外加分布式锁。面试时如果你能现场写一个简单的Lua扣库存脚本并且讲清楚为什么比WATCHmulti更可靠会很加分。6. 分布式锁与缓存雪崩击穿穿透6.1 分布式锁的正确实现与常见坑分布式锁是Redis在分布式系统中的高频应用也是面试必考题。最基础的正确写法是使用SET命令的扩展参数SET lock_key unique_value NX PX 30000。NX表示只有Key不存在时才设置成功PX设置过期时间unique_value是客户端唯一标识。只有加锁和解锁都满足原子性才是安全的。这里最容易踩的坑有三个。第一个是忘了设置过期时间一旦持有锁的进程宕机锁永远不释放其他线程全部卡死。第二个是释放锁时不做身份校验直接DEL可能把别人持有的锁误删。场景是线程A执行时间超过过期时间锁自动过期线程B拿到锁A执行完执行DEL把B的锁删了。解决办法是释放前先比较unique_value再使用Lua脚本完成“检查-删除”的原子操作。第三个是续期问题如果业务执行时间不确定锁可能提前过期要用看门狗机制自动续期。Redisson的lock就实现了这个功能默认看门狗每10秒续期一次直到unlock。至于RedLock算法面试时如果提到不要光说“RedLock更安全”要能说出争议点它依赖多个独立的Redis节点加锁但无法完全避免时钟漂移问题和GC停顿造成的不一致。很多技术专家认为RedLock并不可靠建议在真正需要强一致性的场景优先考虑ZooKeeper或etcd。分布式锁不是银弹能不用就不用优先用幂等和事务解决业务问题。6.2 缓存三兄弟雪崩、击穿、穿透的应对这三个概念是缓存面试题的高频组合必须先分清定义。缓存雪崩是大量Key在同一时间集中过期导致请求全部落到数据库缓存击穿是一个热点Key过期大量请求同时访问这个Key并打穿到数据库缓存穿透是查询一个根本不存在的数据缓存和数据库都没有每次请求都直接打到数据库。应对缓存雪崩的常见手段包括设置过期时间时加一个随机值避免集中过期对热点数据提供永不过期方案用后台定时任务主动更新缓存如果数据库压力实在扛不住可以加服务降级和限流。比如双十一活动把整点过期的Key的TTL设置成基础值随机偏移能有效分散过期时间。缓存击穿的核心思路是只允许一个线程去重建缓存其他线程等待。可以加互斥锁比如用Redis分布式锁保证只有一个请求回源数据库其他请求短暂等待后读取缓存也可以对热点Key设置逻辑过期时间缓存里的value包含过期标记后台线程异步刷新真数据。缓存穿透则更适合用布隆过滤器把所有可能存在的Key先过滤一遍如果Key不存在直接返回空结果同时对空结果也做短暂缓存加上参数校验避免恶意请求绕过Redis打DB。我在实际开发中习惯把这三个问题的处理和监控报警放在一起缓存命中率突然下降就报警DB慢查询多了也要回溯是否Key设计不合理。面试时不要只背方案要能结合自己项目的业务场景说明为什么选这种方案而不选另一种。7. 内存淘汰策略与Key过期机制7.1 过期删除策略惰性删除与定期删除很多人分不清“Key过期”和“内存淘汰”是两个不同的机制。Key到了过期时间后Redis会怎么删除它答案不是单纯定时删除而是混合惰性删除和定期删除。惰性删除是指当客户端访问一个Key时Redis会检查它是否已过期如果过期就删除并返回空。这样做最省CPU但问题是一个过期Key可能长期得不到访问迟迟不删会一直占着内存。定期删除就是Redis每隔一段时间随机抽取一部分设置了过期时间的Key把其中已过期的删除掉。它避免集中扫描全库浪费CPU也缓解了惰性删除的滞后性。这个结合体也不是完美的仍然可能有大量过期Key在短时间内积压。所以内存淘汰策略就是兜底方案当内存使用达到maxmemory配置的上限后Redis会根据策略来回收内存。这里还有一个常见面试题如果Redis内存满了maxmemory-policy设置为noeviction新写入命令会报错但读和删除操作正常一旦遇到这种情况服务就基本不可写了。7.2 八种内存淘汰策略怎么选Redis提供的淘汰策略比较多主流的可以按是否有过期时间分成两类。allkeys-lru从所有Key中按LRU最近最少使用淘汰volatile-lru只从设置过过期时间的Key里淘汰allkeys-lfu和volatile-lfu对应的是LFU最不经常使用还有allkeys-random和volatile-random。需要提醒的是Redis实现的LRU是近似LRU不是精确的因为它默认采样一部分Key做淘汰最新版本还引入了LFU来应对“历史访问频率高但近期不用的冷数据被保留”的问题。选型没有绝对标准但有几个经验可以参考如果你的Redis只做纯缓存数据丢了可以从数据库重建用allkeys-lru最省心如果希望冷热数据区分更严格比如某些数据访问频率高但很久没被操作用allkeys-lfu可能更好如果有部分Key不想被淘汰比如分布式锁、限流计数那就不要用allkeys开头的策略改用volatile-ttl或者volatile-lru并为相关Key设置过期时间。生产环境一定要设置maxmemory否则内存被打爆后操作系统开始swapRedis性能会断崖式下降。我遇到过一次线上事故就是Redis实例maxmemory设置得太大直接打满了物理内存触发系统OOM整个服务跟着卡死。后来我把maxmemory设为物理内存的70%左右同时保留必要的内存余量给fork子进程使用才稳住。面试时提到这个例子比单纯背出八种策略要有说服力得多。8. 常见面试题速查与个人经验8.1 高频问答清单为了方便大家临考前快速过一遍我整理了一个高频二维表把问题和核心要点放在一起。这里不追求面面俱到但覆盖的是出现概率最高的知识点。面试题核心回答要点Redis为什么快内存存储、IO多路复用、单线程避免上下文切换、底层数据结构高效Redis单线程为什么还能高并发IO多路复用和内存操作不是CPU密集型五种数据类型分别适合什么场景String缓存计数Hash对象List消息队列Set去重ZSet排行榜RDB和AOF的区别文件内容、恢复速度、数据丢失粒度和资源消耗主从不一致怎么办接受延迟、读写分离场景区分、增加网络稳定性、监控延迟指标哨兵和Cluster的区别前者高可用后者高可用水平扩展分布式锁怎么实现SET NX EX Lua释放锁 续期机制缓存穿透、击穿、雪崩布隆过滤器、互斥锁、过期时间随机化、永不过期Key过期和内存淘汰的关系删除过期Key是主动手段内存淘汰是兜底手段Redis事务和数据库事务区别原子串行、不支持回滚、WATCH做乐观锁这里面每个问题都可以继续往下深挖比如“怎样保证缓存和数据库一致性”我的经验是优先用Cache Aside模式先更新数据库再删除缓存删除失败则用消息队列重试。如果你面对的场景是并发读写同一热点Key还可以考虑延迟双删但记住这个方案也有不确定性最终还是要在业务上做兜底校验。8.2 面试中容易被追问的细节很多同学能答出一级答案但被面试官追问细节就露馅。比如“ZSet底层为什么用跳表而不是红黑树”不能只说“跳表实现简单”要说明红黑树在范围查询上需要中序遍历而跳表可以方便地从头部顺序遍历跳表的插入删除只影响局部层数且调优参数量化清晰。另一个高频追问是“Redis怎么处理Big Key”如果发现Big Key不能简单丢弃可以考虑拆分、压缩或者用scan扫描并异步删除删除时用UNLINK而不是DEL因为DEL会阻塞主线程UNLINK是异步释放内存。还有一个坑是序列化。面试时对方可能问到“Redis的value用什么序列化方式”如果你直接用JDK序列化存进去的是一堆二进制头空间浪费很大。实际开发里更常用JSON、Protobuf、Kryo或者Redis自带的String直接用字节流。结合热搜里经常看到的“Redis序列化”关键词这确实是一个容易被忽略但实际很影响性能和可读性的点。关于Redis日志和监控我想多说一句不要只在出问题时才去看日志。日常观察内存使用、命中率、慢查询、连接数、复制延迟这些指标能帮你提前发现很多隐患。比如用INFO命令看used_memory和maxmemory的比值如果超过80%就要考虑扩容或者清理。另一个很多人容易忽略的是Redis的日志默认可能只输出到stdout在Docker环境部署时一定要配置logfile或者让容器采集日志否则服务异常时你连线索都找不到。最后分享一个我自己复习Redis的经验不要按八股文的顺序去背最好把知识串成一条故障链。比如先想“缓存穿透打挂数据库”自然会引到布隆过滤器再想到“热点Key过期”引到互斥锁和永不过期“主从延迟”引到读写分离和一致性取舍“Redis重启数据丢失”引到RDB和AOF。把每个知识点放在具体故障场景里面试时候讲出来才会自然也更容易让面试官相信你真的在项目里处理过问题。这套笔记是我整理给团队新人用的今天把它分享出来希望能帮你把Redis的常考知识点理清楚。