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

Redis高频面试题及详细答案（实战版）一、Redis基础认知（入门必问）1、说说Redis是什么？优缺点是什么？答案：Redis是一款开源的、基于内存的高性能键值对数据库，也常被称作数据结构数据库，支持字符串、哈希、列表、集合、有序集合等多种数据结构。日常开发中主要用作缓存、分布式锁、限流、消息队列、计数器等场景。优点：性能极高：纯内存操作，单机QPS能达到10万+，响应速度极快；数据类型丰富：相比Memcached只支持字符串，Redis支持多种复杂数据结构，适配更多业务场景；支持持久化：可以将内存数据落地到磁盘，重启后数据不丢失；功能全面：支持过期删除、事务、发布订阅、Lua脚本、分布式集群；原子性操作：所有单命令都是原子性的，多命令可通过Lua脚本保证原子性。缺点：内存受限：数据存在内存中，机器内存大小决定存储容量，不适合存储海量冷数据；持久化有损耗：RDB、AOF持久化过程会占用少量CPU和磁盘IO，高并发场景有轻微性能开销；单机存在瓶颈：单线程模型虽无锁竞争，但单核CPU性能上限固定，超大流量需要集群扩容。2、Redis为什么这么快？核心原因有哪些？答案：很多人误以为Redis快是因为单线程，其实核心是内存操作+高效模型+极简设计，具体四点：纯内存读写：所有数据都在内存中，避免了磁盘IO的缓慢耗时，这是最核心原因；单线程多路复用：核心工作线程单线程，避免了多线程锁竞争、线程切换的开销，同时通过IO多路复用机制，能同时监听大量客户端连接，不会阻塞；数据结构高效：底层使用优化后的简单数据结构，比如跳表、哈希表，查询、增删时间复杂度极低；极简的编码设计：Redis底层用C语言编写，代码执行效率高，没有虚拟机层的额外开销。补充：Redis6.0之后引入多线程，但只是用来处理网络IO、读写数据，核心命令执行依旧是单线程，保证命令执行的串行性和原子性。3、Redis单线程模型，会不会有性能瓶颈？答案：会有瓶颈，但日常业务大部分场景都能覆盖。瓶颈主要在CPU单核性能，因为核心命令单线程执行，只能利用单核CPU。如果出现大量复杂命令、超大key操作、频繁持久化，就会打满单核CPU，导致请求阻塞。规避方案：避免使用耗时命令：keys、flushall、hgetall、sort等；拆分大key、热key，避免单key占用大量执行时间；超大流量场景搭建集群，分片分担压力。二、Redis数据结构（高频重点）1、Redis常用的数据类型有哪些？各自适用场景？答案：String字符串：最基础类型，支持增删改查、自增自减。适用场景：缓存用户信息、配置信息、计数器、限流、分布式session；Hash哈希：key-value嵌套结构，一个key对应多个字段。适用场景：存储结构化数据，比如用户详情、商品信息、订单数据，比单独创建多个String更节省内存；List列表：有序可重复，底层是双向链表。适用场景：简单消息队列、排行榜、时间线记录、日志列表；Set集合：无序不可重复，支持交集、并集、差集。适用场景：用户点赞、收藏、好友关系、去重统计；ZSet有序集合：不可重复、自带权重排序。适用场景：各类排行榜（积分、热度）、延时队列、带权重的排序统计；2、什么是大key？大key有什么危害？怎么处理？答案：大key定义：通常指String类型value超过10KB，或Hash、List、Set、ZSet元素数量超过1000个的key。危害：阻塞线程：读取、删除大key耗时过长，单线程会被阻塞，后续所有请求超时；内存占用不均：集群分片场景下，大key会导致节点内存失衡，负载不均衡；网络卡顿：传输大key数据会占用大量带宽，拖慢整体接口响应；持久化耗时：大key会增大RDB、AOF持久化的压力，触发频繁磁盘写入。解决方案：拆分key：将一个大key拆分为多个小key，比如大Hash拆分为多个小Hash；渐进式删除：不用del直接删，用hscan、sscan分批遍历删除，避免一次性阻塞；限制数据体量：业务层做限制，避免单key存储过多数据；定期巡检：通过redis-cli工具定期排查线上大key，提前优化。三、Redis持久化（必问核心）1、Redis持久化有几种方式？区别是什么？答案：Redis支持两种持久化方式：RDB快照和AOF日志，生产环境一般开启两者混合持久化。RDB（快照持久化）原理：按照配置的时间周期，定期将内存中全量数据生成快照，保存到磁盘的.rdb文件中。优点：文件体积小、恢复速度快、对日常性能影响小；缺点：会丢失最后一次快照后的增量数据，数据一致性一般；持久化时fork子进程，超大内存场景会有短暂卡顿。AOF（日志持久化）原理：记录每一条写操作命令，追加到.aof日志文件中，重启时重放日志恢复数据。优点：数据安全性高，支持秒级数据恢复，丢失数据极少；缺点：文件体积大，恢复速度慢，长期运行日志会持续膨胀，需要定期重写压缩。2、AOF的三种刷盘策略是什么？各自优缺点？答案：always（每次写都刷盘）：每执行一条写命令，立刻写入磁盘。数据最安全，几乎不丢数据，但IO开销极大，性能最差，基本不用；everysec（每秒刷盘）：默认策略，每秒批量将日志刷入磁盘。性能均衡，最多丢失1秒数据，生产环境首选；no（系统自动刷盘）：交给操作系统决定刷盘时机。性能最高，但宕机时会丢失大量数据，不适合核心业务。3、Redis重启恢复数据的优先级？答案：Redis重启时，优先加载AOF文件恢复数据。原因：AOF数据完整性更高，RDB是定时快照存在数据丢失风险。只有当AOF文件不存在时，才会加载RDB文件。生产环境开启混合持久化后，AOF重写时会先写入RDB全量数据，再追加增量日志，兼顾恢复速度和数据安全性。四、缓存三大问题（面试重中之重）1、缓存穿透、缓存击穿、缓存雪崩的区别及解决方案？一、缓存穿透现象：查询数据库和缓存都不存在的数据，比如恶意伪造id、负数id，请求直接打到数据库，压垮DB。解决方案：空值缓存：查询为空时，缓存空值或默认值，设置短期过期时间；布隆过滤器：提前过滤不存在的key，拦截非法请求；接口层校验：参数合法性校验、限流、黑名单拦截。二、缓存击穿现象：热点key过期瞬间，大量并发请求同时打到数据库，单节点DB压力骤增。解决方案：互斥锁：过期时只允许一个请求更新缓存，其他请求等待；热点key永不过期：核心热点数据取消过期时间，后台异步更新；过期时间随机偏移：避免大量key同时过期。三、缓存雪崩现象：大量缓存key同时失效，或Redis集群宕机，所有请求直接访问数据库，导致数据库雪崩宕机。解决方案：过期时间加随机值：打散过期时间，避免批量失效；搭建Redis高可用集群：主从+哨兵/集群，避免单点宕机；服务层限流、降级、熔断：缓存失效时，拒绝多余请求，保护DB；多级缓存：本地缓存+Redis分布式缓存，双重兜底。2、缓存和数据库双写一致性问题怎么解决？答案：没有绝对完美的方案，根据业务一致性要求选择，主流方案如下：1、普通业务（允许短暂不一致）：先更新数据库，再删除缓存优势：性能高、实现简单，绝大多数互联网业务首选。即使出现短暂不一致，缓存过期后会自动修复。2、高一致性业务：延时双删步骤：更新数据库→删除缓存→延迟几百毫秒→再次删除缓存。规避更新期间旧数据再次写入缓存的问题。3、强一致性业务：分布式锁+更新读写操作加分布式锁，保证同一数据同一时间只有一个线程操作，彻底避免不一致，但性能开销较大。4、终极方案：订阅Binlog异步更新缓存通过Canal监听数据库Binlog日志，异步更新Redis缓存，解耦业务代码，一致性更高，适合大型项目。五、Redis高可用（主从、哨兵、集群）1、Redis主从复制原理？答案：主从复制就是一台主节点（master）负责读写，多台从节点（slave）同步主节点数据，只负责读，实现读写分离。复制分为两个阶段：全量复制：从节点首次连接主节点，主节点生成RDB快照，发送给从节点，从节点加载快照完成全量同步；增量复制：全量同步完成后，主节点后续的写命令，会实时同步给从节点，保证数据一致。缺点：主从模式没有自动故障转移，主节点宕机后，需要手动切换从节点为主节点，无法保证高可用。2、Redis哨兵模式作用及原理？答案：哨兵是基于主从模式的高可用监控组件，解决主从模式无法自动故障转移的问题。生产环境一般部署3个哨兵节点。核心作用：监控：实时监控主、从节点运行状态；故障判定：主节点宕机后，哨兵集群投票判定客观下线；自动转移：自动选举最优从节点升级为主节点，其他从节点同步新主节点；通知：将节点变更信息同步给客户端。缺点：哨兵模式依旧是单主节点，写能力无法扩容，海量写流量场景不适用。3、Redis集群模式原理？哈希槽是什么？答案：RedisCluster集群解决哨兵模式写瓶颈问题，支持分片扩容、读写高可用，默认6个节点（3主3从），可横向扩展。哈希槽原理：集群总共分配16384个哈希槽，所有主节点平分这些槽位。写入数据时，通过公式CRC16(key)%16384计算key对应的槽位，将数据路由到对应主节点。优势：支持横向扩容，新增节点只需迁移部分槽位；主从冗余，单个主节点宕机不影响整体集群可用；分布式存储，分担读写压力。六、分布式锁（实战高频）1、Redis实现分布式锁的原理？答案：核心是互斥、防死锁、可重入、高可用，基础实现命令：SETkeyuuidNXEX过期时间参数解释：NX（不存在才设置，保证互斥）、EX（自动过期，防止死锁）、uuid（唯一标识，防止误删别人的锁）。加锁逻辑：通过上面命令抢占锁，成功则执行业务，失败则重试或等待；解锁逻辑：通过Lua脚本判断uuid是否匹配，匹配则删除锁，避免误删。2、分布式锁存在的问题？Redisson怎么解决？答案：原生Redis锁的问题：锁超时释放：业务执行超时，锁自动过期，导致其他线程抢占锁，出现并发问题；不支持可重入：同一个线程无法重复加锁；无公平机制：多个线程抢占锁无序。Redisson解决方案：看门狗机制：锁即将过期、业务未执行完时，自动续期，彻底解决锁超时问题；支持可重入锁：记录线程加锁次数，次数归零才释放锁；支持公平锁、读写锁、联锁，适配复杂业务；基于Lua脚本保证加锁解锁原子性。七、Redis实战优化（进阶面试）1、Redis过期key的删除策略？答案：Redis采用惰性删除+定期删除结合的策略：惰性删除：key过期后不立刻删除，下次访问该key时，才判断过期并删除。节省CPU资源，但会堆积大量过期冷数据，占用内存；定期删除：后台线程定时随机抽取部分过期key删除，循环清理，减少内存占用。不会占用过多CPU，兼顾性能和内存。如果内存满了，会触发内存淘汰策略进一步清理数据。2、Redis内存淘汰策略有哪些？默认是什么？答案：默认策略：noeviction，内存满了直接报错，不删除任何数据。常用生产策略：allkeys-lru：优先淘汰最近最少使用的key，通用场景首选；volatile-lru：只淘汰