Redis高频面试题及详细实战答案

Redis高频面试题及详细实战答案一、Redis基础核心面试题1、为什么Redis性能这么高？这是面试高频基础题，核心原因结合底层设计和运行机制，主要有5点：1）纯内存操作：Redis所有数据都存储在内存中，内存读写速度远超磁盘，避免了磁盘IO的耗时瓶颈，这是性能高的核心原因。2）单线程模型：核心命令处理全程单线程，避免了多线程的线程切换、锁竞争、死锁等开销，同时保证了命令执行的原子性，无需额外加锁。注意：Redis并非完全单线程，持久化、集群同步等后台操作是独立子线程执行。3）IO多路复用：采用epoll（Linux）、kqueue（Mac）多路复用技术，单个线程可以监听大量客户端连接，不用为每个连接创建线程，极大提升并发处理能力，支持上万并发连接。4）高效数据结构：底层封装了压缩列表、跳跃表、哈希表等优化后的数据结构，时间复杂度极低，大部分增删改查操作都是O(1)复杂度。5）极简的协议设计：采用RESP简单文本协议，解析速度快、开销小，没有复杂的报文解析逻辑，减少CPU消耗。2、Redis单线程为什么不会瓶颈？能不能处理高并发？很多人误区认为单线程性能差，实际Redis单线程完全可以支撑十万级QPS，核心逻辑：1）Redis的瓶颈不在CPU，而在内存和网络IO。内存读写速度极快，单线程完全可以跑满网络带宽，不会出现CPU算力不足的问题。2）单线程规避了多线程的并发开销，整体执行效率更高。3）针对多核CPU，Redis支持多实例部署，通过开启多个Redis进程，充分利用多核资源，解决单线程无法利用多核的问题。总结：单线程适合Redis的业务场景，不仅不是短板，反而是高性能、高稳定的优势。3、Redis支持的数据类型有哪些？日常分别用在什么场景？Redis常用5大基础类型+5大特殊类型，都是面试和工作高频使用：基础类型1）String字符串：最常用，支持key-value、数字、字符串。场景：缓存用户信息、配置信息、计数器、限流、分布式锁。2）Hash哈希：适合存储结构化数据。场景：缓存用户详情、商品信息、订单数据，相比String序列化存储更节省内存、支持单独修改字段。3）List列表：有序可重复，双向链表。场景：消息队列、任务队列、时间线、排行榜列表。4）Set集合：无序不可重复。场景：去重、好友共同关注、抽奖、权限集合判断。5）ZSet有序集合：有序不可重复，带score分值排序。场景：各类排行榜、延时队列、权重排序场景。特殊类型1）Bitmap位图：位运算，超省内存。场景：签到统计、状态标记、活跃用户统计。2）HyperLogLog：基数统计，误差极小。场景：统计页面UV、独立访客数。3）Geo地理位置：存储经纬度。场景：附近的人、附近门店、地理位置测距。4）Stream：消息队列。场景：可靠消息队列、消息消费、日志收集。5）Bitfield：位域操作，精细化位运算。场景：海量状态存储、高性能标记统计。4、Redis的过期删除策略是什么？Redis采用惰性删除+定期删除结合的策略，没有采用实时删除（开销太大）：1）惰性删除（核心）：key过期后不会立刻删除，等到下次访问该key时，检查是否过期，过期则直接删除并返回空。优点：极致节省CPU资源；缺点：过期key长期不访问会一直占用内存，造成内存泄漏。2）定期删除（兜底）：Redis每隔一段时间（默认100ms），随机抽取部分过期key检查并删除。优点：解决惰性删除的内存泄漏问题；缺点：是随机抽样，无法清理所有过期key。两者配合：既保证CPU不会被过期删除操作占用，又能最大限度清理过期数据，控制内存占用。5、Redis内存淘汰策略有哪些？当内存达到maxmemory上限时，触发内存淘汰，Redis共有8种淘汰策略，面试重点记常用6种：1）noeviction（默认）：不淘汰任何数据，内存满后写入报错，只允许读操作，线上不推荐。2）allkeys-lru：从所有key中，淘汰最近最少使用的key，通用场景，线上最常用。3）volatile-lru：只从设置了过期时间的key中，淘汰最近最少使用的key。4）allkeys-lfu：从所有key中，淘汰使用频率最低的key（Redis4.0+新增）。5）volatile-lfu：从过期key中，淘汰使用频率最低的key。6）allkeys-random/volatile-random：随机淘汰key，业务基本不用。线上最优实践：普通缓存业务用allkeys-lru，有永久key、只希望淘汰过期数据用volatile-lru。二、缓存三大问题（击穿、穿透、雪崩）面试题1、什么是缓存穿透？怎么解决？定义：查询数据库和缓存都不存在的数据，比如恶意请求大量不存在的用户ID、商品ID，请求直接穿透到数据库，压垮数据库。解决方案（优先级从高到低）：1）缓存空值/默认值：查询数据库为空时，在缓存中存入空值，设置短过期时间，避免同一请求反复打数据库。2）布隆过滤器：将所有有效key预存到布隆过滤器，请求进来先校验，不存在直接拦截，不访问缓存和数据库，适合海量数据场景。3）接口层校验：参数合法性校验、限流、黑名单拦截，杜绝恶意非法请求。2、什么是缓存击穿？怎么解决？定义：热点Key在过期瞬间，大量并发请求同时打向数据库，瞬间压垮数据库。区别于穿透：数据是存在的，只是key过期了。解决方案：1）互斥锁（分布式锁）：key过期后，只放行一个请求查询数据库、更新缓存，其他请求阻塞等待，避免并发打库。缺点：少量阻塞，牺牲一点吞吐量。2）热点Key永不过期：手动取消热点数据的过期时间，后台异步定时更新缓存，从根源杜绝击穿。线上最优方案，无性能损耗。3）过期时间随机偏移：避免大量key同时过期，分散过期压力。3、什么是缓存雪崩？怎么解决？定义：大量缓存key同一时间过期，或者Redis服务宕机，导致所有请求直接访问数据库，数据库瞬间压力过载崩溃。解决方案：1）过期时间加随机值：给所有key的过期时间增加1-5分钟随机偏移，避免批量key同时过期，预防小规模雪崩。2）Redis高可用部署：主从+哨兵/集群部署，避免单节点宕机导致整体缓存失效，解决Redis宕机引发的雪崩。3）服务层限流、降级、熔断：缓存失效后，限制数据库QPS，超出阈值直接降级返回默认数据，保护数据库。4）多级缓存：本地缓存（Caffeine）+Redis分布式缓存，Redis失效后，本地缓存兜底，避免全线崩溃。三、Redis持久化面试题1、Redis持久化有几种方式？区别是什么？Redis有两种持久化机制：RDB快照、AOF日志，线上一般开启两者混合持久化。RDB（快照持久化）原理：定期将内存中全量数据生成二进制快照文件，保存到磁盘。支持手动save（阻塞）、bgsave（后台子线程执行，不阻塞主线程）。优点：文件体积小、恢复速度快、占用CPU低，适合做冷备份。缺点：有数据丢失风险，两次快照之间的数据无法保存；无法实现秒级持久化。AOF（日志持久化）原理：记录每一条写命令到日志文件，重启时重放日志恢复数据，默认每秒写入一次。三种刷盘策略：1）always：每次写操作都刷盘，数据零丢失，性能极差，基本不用。2）everysec：每秒刷盘一次，最多丢失1秒数据，性能均衡，线上默认。3）no：交给系统自动刷盘，不可控，不推荐。优点：数据安全性高，丢失数据极少；支持实时持久化。缺点：日志文件体积大，恢复速度慢，长期运行文件会膨胀，需要定期AOF重写。2、线上为什么要开启RDB+AOF混合持久化？1）单独用RDB：数据丢失风险大，无法保证数据可靠性。2）单独用AOF：文件大、恢复慢，故障重启耗时久。3）混合持久化：Redis4.0+支持，AOF重写时会加载RDB全量数据，再追加增量AOF日志。既拥有RDB恢复快的优势，又有AOF数据安全的优势，兼顾性能和数据可靠性，是线上标准配置。3、AOF重写机制是什么？为什么需要重写？AOF会记录所有写命令，长期运行会产生大量冗余命令（比如多次修改同一个key，只保留最后一次即可），导致文件越来越大。AOF重写就是Redis后台子进程，根据当前内存数据，生成最简指令日志，替换旧的冗余AOF文件，大幅缩小文件体积，不影响主线程正常读写。四、Redis高可用与集群面试题1、Redis主从复制原理？主从复制是高可用的基础，一主多从，主节点负责读写，从节点同步主节点数据，只提供读服务，分担读压力。复制分为三个阶段：1）握手阶段：从节点启动后，向主节点发送同步请求，主从建立连接。2）全量复制：主节点执行bgsave生成RDB文件，发送给从节点，从节点加载RDB完成全量数据同步。期间主节点新的写命令会缓存，同步完成后发送给从节点。3）增量复制：全量同步完成后，主节点持续将新的写命令实时同步给从节点，保持数据一致。2、Redis哨兵机制的作用？哨兵（Sentinel）是基于主从复制的高可用方案，解决主节点宕机无法自动切换的问题，核心三大作用：1）监控：实时监控主节点、从节点的运行状态。2）故障转移：主节点宕机后，哨兵集群投票，自动选举最优从节点升级为主节点，修改其他从节点的主节点指向。3）消息通知：将故障转移结果、节点状态变更通知给客户端。线上部署：至少3个哨兵节点，保证集群容错性。3、Redis集群（Cluster）原理？哈希槽是什么？RedisCluster是分布式集群方案，解决单节点内存上限、并发上限问题，支持水平扩容，无中心节点，线上主流部署方式。1）哈希槽：集群共有16384个哈希槽，每个主节点分配固定数量的槽位。key通过CRC16算法计算哈希值，对16384取模，得到对应的槽位，从而定位到对应节点。2）集群架构：标准集群是3主3从，每个主节点对应一个从节点，主节点负责读写，从节点做备份、故障兜底。3）扩容缩容：支持在线迁移哈希槽，实现不停机扩容、缩容，不影响业务运行。4、哨兵和集群的区别？适用场景？1）哨兵模式：本质还是单主架构，所有数据都在一个主节点，从节点只是备份和读分担。优点：架构简单、运维简单；缺点：无法扩容，受单节点内存、并发限制。适用：中小型业务、数据量不大、QPS不高的场景。2）Cluster集群模式：分布式分片架构，数据分散在多个主节点，支持水平扩容。优点：海量数据、高并发、可无限扩容；缺点：架构复杂、运维成本高。适用：大型业务、大数据量、高QPS场景。五、Redis分布式锁面试题1、Redis实现分布式锁的原理？核心命令：SETkeyvalueNXEX过期时间1）NX：只有key不存在时才设置成功，保证只有一个客户端能获取锁。2）EX：设置锁的过期时间，防止客户端宕机导致锁无法释放（死锁）。3）value存储唯一ID：防止误删别人的锁，释放锁时先校验ID，一致再删除。2、分布式锁存在哪些问题？怎么解决？1）锁过期导致业务未执行完：业务执行超时，锁提前过期，其他线程抢占锁，引发并发问题。

解决方案：开启锁续期（看门狗机制），主流框架Redisson自带，定时检测业务是否执行完毕，未完成则自动延长锁过期时间。2）误删锁：线程执行过慢，锁过期后被其他线程获取，原线程删除新线程的锁。

解决方案：锁value存唯一UUID，删除前校验归属权，通过Lua脚本保证校验+删除原子性。3）主从锁失效问题：主节点加锁成功，未同步到从节点就宕机，从节点升级为主节点后，可重复加锁。

解决方案：使用Redlock红锁（多节点加锁），或直接用Zookeeper分布式锁（追求强一致性场景）。3、为什么要用Lua脚本？Lua脚本可以将多条Redis命令打包执行，保证多条命令的原子性，中间不会被其他请求打断。分布式锁释放、限流、批量操作等场景必须用Lua脚本，避免并发错乱问题。六、Redis实战优化面试题1、Redis热点Key问题怎么解决？热点Key是指单个keyQPS极高，打满单节点性能上限。解决方案：1）本地缓存兜底：接入JVM本地缓存，避免重复请求Redis。2）Key拆分：将一个热点key拆分为多个分片key，分散请求压力。3）集群倾斜优化：手动迁移热点槽位，分担节点压力。2、Redis大Key问题怎么解决？危害是什么？大Key危害：1）删除大key会主线程阻塞，引发卡顿、超时；2）网络传输量大，拖慢整体接口响应；3）主从同步延迟增大，引发数据不一致。解决方案：1）拆分大Key：将大集合、大哈希拆分为多个小key；2）异步删除：使用unlink替代del，后台异步删除，不阻塞主线程；3）