Redis 高频面试题及详细答案（实战接地气版）

Redis高频面试题及详细答案（实战接地气版）一、Redis基础认知（必问基础）1、说说你对Redis的理解？它有什么特点？Redis是一款开源的内存型键值对数据库，日常开发里主要当缓存、分布式锁、消息队列、计数器来用。核心特点我总结为这几点，都是实战常用的：纯内存操作，速度极快：绝大部分数据存在内存，读写性能很高，单机QPS能扛10万+。高性能单线程模型：核心读写命令单线程执行，避免了多线程锁竞争、上下文切换的开销，这是它快的核心原因之一。（注意：Redis6.0后多线程只用来处理IO，核心命令还是单线程）数据持久化：支持RDB、AOF两种持久化方式，重启后数据不会全部丢失，弥补纯内存数据库易失的问题。数据结构丰富：不止简单的String，还有List、Hash、Set、ZSet、Bitmap、HyperLogLog等，能适配各种业务场景。高可用、可集群：支持主从复制、哨兵、Cluster集群，能实现故障自动转移、水平扩容，满足线上高可用需求。支持多数据库：默认16个库，业务上可以做数据隔离，不同业务分库存储。2、Redis为什么单线程还这么快？很多人误以为单线程就是慢，其实Redis单线程快是有原因的，核心四点：纯内存操作：所有读写都是内存交互，没有磁盘IO的耗时，这是最关键的一点。避免线程开销：单线程无需加锁、不存在线程竞争、上下文切换的损耗，代码执行效率极高。IO多路复用：采用epoll/select模型，一个线程能监听大量客户端连接，不会因为连接多就阻塞。命令执行简单：Redis命令都是简单的内存运算，没有复杂逻辑，执行耗时极短。补充：Redis6.0引入多线程，只是把网络IO、读写缓冲区做成多线程，核心的数据读写命令依然是单线程，保证了线程安全，不用加锁。3、Redis常见数据结构及实际业务场景只记理论没用，面试重点看场景匹配，我整理的都是线上常用场景：String（字符串）：最基础结构，支持增删改查、自增自减。场景：用户信息缓存、手机号验证码、分布式Session、计数器（点赞数、浏览量）。Hash（哈希）：适合存储结构化数据，key-value嵌套结构，节省内存。场景：用户详情、商品信息、订单基础信息（不用频繁序列化整个对象）。List（列表）：有序可重复，两头操作高效。场景：简单消息队列、用户点赞列表、时间线消息、日志队列。Set（集合）：无序不可重复，支持交集、并集、差集。场景：好友共同关注、商品标签去重、抽奖去重、黑名单过滤。ZSet（有序集合）：不可重复、自带权重排序。场景：排行榜（销量、积分、热度）、延时任务、带权重的队列。Bitmap（位图）：位运算，极度省内存。场景：用户签到记录、活跃状态统计、批量状态标记。HyperLogLog：基于概率算法，极小内存统计基数。场景：页面UV统计、独立访客统计（允许极小误差）。二、Redis持久化核心（高频重点）4、RedisRDB和AOF区别？各自优缺点？线上怎么选型？Redis持久化就是把内存数据落地到磁盘，防止重启丢数据，两种机制原理完全不同。RDB（快照持久化）定期把全量内存数据生成二进制快照文件保存到磁盘，默认dump.rdb。可以手动save（阻塞）、bgsave（后台子进程执行），也可以配置定时自动触发。优点：文件体积小、恢复速度快、占用CPU低，适合做冷备份。缺点：会丢数据，两次快照之间的新增数据没落地，宕机就丢失；无法实时持久化。AOF（日志持久化）把客户端每一条写命令追加记录到日志文件（appendonly.aof），重启时重放日志恢复数据，支持秒级持久化。优点：数据安全性高，支持每秒/每次写都落地，最多丢1秒数据。缺点：日志文件体积大，恢复速度比RDB慢，频繁刷盘会稍微影响性能。线上选型方案普通业务（主流）：RDB+AOF同时开启，兼顾性能和数据安全。AOF保证数据不丢失，RDB做快速备份恢复。纯缓存业务：只开RDB或者不开持久化，丢数据不影响业务。金融、支付核心业务：只开AOF且配置always模式，最大限度保证数据安全。5、AOF重写机制了解吗？为什么需要重写？AOF是持续追加写命令，运行久了日志文件会极度膨胀，比如一个key反复修改几十次，日志会存几十条命令，但最终只需要最后一条生效。所以Redis会触发AOF重写：开启子进程，读取当前内存最新数据，生成一套最简命令覆盖旧日志，删除冗余无效命令，大幅缩小文件体积。重写过程不会阻塞主进程，而且重写期间新的写命令会单独缓存，重写结束后合并写入，保证数据一致性。三、缓存三大问题（面试必考重中之重）6、缓存穿透、缓存击穿、缓存雪崩区别？解决方案？这三个问题是Redis面试必问，一定要区分场景，解决方案都是实战落地的。（1）缓存穿透场景：查询数据库和缓存都没有的数据，比如恶意传不存在的用户ID、负数ID，请求直接打到数据库，缓存永远不命中，高并发下压垮数据库。解决方案：空值缓存：查询为空时，缓存一个空对象，设置短期过期时间，避免重复穿透。布隆过滤器：提前把所有有效key存入布隆过滤器，请求先过过滤器，无效key直接拦截。接口层校验：参数合法性校验、限流、黑名单拦截恶意请求。（2）缓存击穿场景：热点key过期瞬间，大量并发请求同时打向数据库，瞬间压垮DB。比如秒杀活动的热门商品key过期。解决方案：互斥锁（分布式锁）：key过期后，只放行一个请求查数据库、更新缓存，其他请求等待重试。热点key永不过期：核心热点数据手动取消过期时间，从根源避免击穿。过期时间随机偏移：批量key统一过期时，加随机秒数，避免集中过期。（3）缓存雪崩场景：大量缓存key同时过期/Redis服务宕机，所有请求全部直达数据库，导致数据库瞬间过载崩溃，引发服务雪崩。解决方案：过期时间打散：给所有key过期时间加随机偏移，避免批量过期。搭建高可用集群：主从+哨兵/Cluster，避免单机宕机导致整体不可用。服务降级、熔断：高并发时兜底，直接返回默认值，不查DB。多级缓存：本地缓存（Caffeine）+Redis分布式缓存，双重兜底。7、缓存和数据库一致性问题怎么解决？没有绝对的强一致，只有适配业务的最优方案，主流两种策略：（1）普通业务（最终一致）先更新数据库，再删除缓存（业界标准方案）原因：如果先删缓存再更DB，并发场景下会出现旧数据回填，导致缓存脏数据；先更DB再删缓存，即使删除失败，也只是短暂脏数据，等待过期即可自愈。（2）高一致业务引入消息队列异步重试删除缓存：更新DB成功后发MQ，消费端删除缓存，删除失败无限重试，保证最终一致。补充：不建议频繁更新缓存，只删不更，查询时回填，减少无效更新操作。四、Redis高可用（主从、哨兵、集群）8、Redis主从复制原理？主从就是一主多从，主节点负责读写，从节点只做备份、读请求，分担压力，核心分三个阶段：握手阶段：从节点启动后，主动连接主节点，发送同步请求。全量复制：主节点执行bgsave生成RDB文件，发送给从节点，从节点加载文件完成全量数据同步。期间主节点新的写命令会缓存，同步完成后补发。增量复制：全量同步完成后，主节点后续所有写命令，实时同步给从节点，保持数据一致。缺点：主从架构没有自动故障转移，主节点宕机后，需要手动切换主节点，无法满足高可用。9、Redis哨兵机制作用？工作原理？哨兵是为了解决主从架构无法自动故障转移的问题，本质是独立的监控进程。核心三大作用：监控、通知、自动故障转移工作流程：多个哨兵节点实时监控主、从节点状态，每秒发送心跳检测。主观下线：单个哨兵检测到主节点超时，先标记主观下线。客观下线：多个哨兵（超过半数）确认主节点宕机，判定客观下线。自动选举：哨兵集群投票，选出最优从节点升级为新主节点。故障转移：旧主节点恢复后，自动降级为从节点，挂载到新主上。适用场景：中小规模项目，能实现高可用，但无法扩容，存储容量受限于单主节点。10、RedisCluster集群原理？怎么分片？为什么需要集群？哨兵模式只能高可用，不能扩容，数据都存在主节点单机，数据量大、并发高就扛不住，所以需要Cluster集群。核心原理：哈希槽分片Cluster总共有16384个哈希槽，每个主节点分配一部分槽位。写入key时，通过公式CRC16(key)%16384计算槽位，定位到对应主节点读写数据。集群特点：支持水平扩容：新增节点只需迁移部分槽位，无需停机。自带高可用：每个主节点搭配从节点，主宕机自动切换从节点。去中心化：无中心节点，所有节点平等，互相通信。线上大规模Redis全部用Cluster集群，兼顾高可用、高并发、大容量。五、Redis经典实战问题11、Redis过期键删除策略？内存淘汰策略？过期键删除（针对过期key）三种策略配合使用：惰性删除：key过期后不立即删，下次访问时检测到过期再删除，节省CPU。定期删除：后台线程定时随机抽查一批key，删除过期数据，避免内存堆积。主动淘汰：内存满时触发内存淘汰，清理过期key。内存淘汰策略（内存达到maxmemory时触发）线上最常用2种：allkeys-lru（主流）：优先淘汰最近最少使用的key，适合通用缓存业务。volatile-lru：只淘汰带过期时间的key，保留永久数据。其余策略基本不用，面试记住这两个即可。12、Redis分布式锁实现原理？有什么问题？怎么优化？基础实现（SETNXEX）核心命令：SETlock_key随机值NXEX过期时间NX：key不存在才创建，保证互斥。EX：设置过期时间，防止死锁。存随机值：防止误删别人的锁。解锁流程：先判断value是否是自己存的随机值，一致再删除，用Lua脚本保证原子性。存在的问题&优化方案锁过期业务没执行完：出现锁失效、并发问题。优化：开启锁续期（看门狗机制），Redisson自带实现。单机锁不安全：主从异步复制，主节点宕机锁没同步到从节点，导致锁失效。优化：使用Redlock红锁（多节点加锁，半数成功才算加锁成功）。线上开发直接用Redisson，不用手写分布式锁，稳定可靠。13、Redis为什么适合做缓存？不适合做什么？适合做的场景：热点数据缓存、接口高频查询缓存。分布式锁、限流、计数器、排行榜。简单延时队列、消息队列、会话存储。不适合做的场景：海量冷数据存储：内存成本太高，不如MySQL、ES。强一致性事务场景：Redis不支持事务回滚，无法满足金融级强一致。大数据持久化存储：磁盘存储效率低，不是专业存储中间件。六、进阶面试题（中高级必问）14、Redis事务了解吗？为什么不支持回滚？Redis事务是批量命令一次性执行，核心命令：MULTI（开启事务）、EXEC（执行）、DISCARD（放弃）、WATCH（乐观锁）。特点：事务执行中，命令语法错误会整体放弃执行。运行时错误不回滚，正确命令正常执行，错误命令报错跳过。不支持回滚的原因：Redis追求高性能、简单高效，回滚机制会大幅增加代码复杂度和性能开销，而且Redis事务简单，运行时错误极少，官方认为没必要做回滚。15、Redis缓冲区溢出问题？常见两类缓冲区溢出，线上容易出故障：主从复制缓冲区溢出：主从同步期间，主节点写入数据过快，缓冲区存不下，导致同步失败、全量重同步。优化：调大repl-buffer大小、拆分大key。客户端缓冲区溢出：客户端读取过