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

Redis高频面试题及详细答案（实战版）一、Redis基础认知1、说说你对Redis的理解？它有什么特点？Redis是一款开源的、基于内存的高性能键值对数据库，和传统MySQL这类关系型数据库不同，它是非关系型数据库，主要用于缓存、限流、分布式锁、消息队列等场景。核心特点主要有这几点：高性能：数据全程存储在内存中，读写速度极快，单机QPS能达到10万+，远高于磁盘数据库。多数据类型支持：不止简单的key-value，还支持字符串、哈希、列表、集合、有序集合等多种数据结构，能适配不同业务场景。持久化能力：虽然是内存数据库，但支持RDB和AOF两种持久化方式，能防止服务重启后数据全部丢失。单线程模型：核心读写命令单线程执行，避免了多线程的锁竞争、上下文切换开销，保证了命令执行的原子性。高可用、可扩展：支持主从复制、哨兵模式、集群模式，能实现故障自动转移、海量数据分片存储。功能丰富：支持过期删除、事务、发布订阅、Lua脚本、限流等实用功能。2、Redis为什么速度这么快？这是面试高频问题，核心原因不是单一因素，是多方面优化叠加的结果：纯内存操作：所有数据读写都在内存中完成，没有磁盘IO的耗时，这是最核心的原因。单线程避免资源竞争：核心命令处理采用单线程，不用加锁、没有多线程上下文切换、线程竞争的开销，执行效率极高。IO多路复用模型：采用epoll多路复用机制，单线程可以监听大量客户端连接，高效处理海量请求，不会因为连接多造成阻塞。数据结构高效：底层每种数据类型都做了极致优化，比如压缩列表、跳表等，查询和操作的时间复杂度极低。简单的命令执行逻辑：Redis命令设计简单，执行流程轻量化，没有复杂的语法解析、事务日志冗余操作。补充：Redis单线程仅指命令执行核心线程，持久化、集群心跳等辅助操作是多线程执行的。3、Redis单线程为什么不会阻塞？很多人误以为单线程处理请求一定会阻塞，其实不会。Redis的单线程是基于IO多路复用实现的，核心逻辑是：线程不会主动等待某个请求完成，而是通过epoll监听所有客户端socket连接，一旦有请求就绪，就依次读取、执行命令、返回结果。整个过程是异步非阻塞的，不会因为某一个客户端请求卡住，就影响其他请求。但如果执行耗时极高的命令（比如keys*、flushall、大量数据的lua脚本），会阻塞主线程，导致整个Redis服务卡顿，这也是生产环境禁止使用高危命令的原因。4、Redis支持哪些数据类型？日常分别用在什么场景？Redis常用的核心数据类型有5种，生产场景使用率最高，还有几种特殊类型适配复杂业务：String（字符串）：最基础类型，支持字符串、数字、二进制数据。

场景：用户信息缓存、验证码、计数器、分布式限流、点赞数、访问量统计。Hash（哈希）：key对应多个field-value键值对，类似Java的Map。

场景：存储结构化数据，比如用户详情、商品信息、订单数据，比单独创建多个Stringkey更节省内存。List（列表）：有序可重复的字符串列表，底层是双向链表。

场景：消息队列、任务队列、用户浏览记录、评论列表。Set（集合）：无序、不可重复的字符串集合。

场景：好友去重、点赞用户去重、共同好友、抽奖活动、权限去重。ZSet（有序集合）：不可重复、自带权重排序的集合。

场景：排行榜、延时队列、带权重的任务排序、热门商品排名。特殊类型：Bitmap（位图，用于签到、状态标记）、HyperLogLog（基数统计，用于UV统计）、Geo（地理位置，用于附近的人/门店）、Stream（可靠消息队列）。二、Redis持久化机制1、Redis两种持久化方式：RDB和AOF区别？Redis内存数据断电、重启会丢失，持久化就是把内存数据落地到磁盘，两种方式各有优劣，生产环境一般同时开启。RDB（快照持久化）定期把当前Redis的全量内存数据生成快照，保存到磁盘的.rdb文件中。可以手动触发（save、bgsave），也可以配置定时触发。优点：文件体积小、恢复速度快、对主线程影响小（bgsave通过子进程执行），适合做冷备份。缺点：会丢失最后一次快照后的增量数据，数据完整性一般；频繁快照会占用磁盘IO和CPU资源。AOF（日志持久化）以日志形式，记录Redis执行的每一条写命令，追加到.aof文件末尾，重启时重放日志恢复数据。优点：数据安全性极高，支持秒级甚至无数据丢失；日志追加写入，不会影响主线程性能。缺点：日志文件体积大，数据恢复速度比RDB慢；长期运行日志会冗余，需要定期重写压缩。2、RDB的save和bgsave区别？save：同步持久化，主线程直接执行快照保存，期间阻塞所有读写请求，生产环境绝对不用。bgsave：异步持久化，主线程fork子进程，由子进程完成快照写入，主线程正常处理业务请求，不阻塞，是默认的持久化方式。3、AOF重写机制是什么？为什么需要重写？AOF会持续记录所有写命令，长期运行后日志文件会越来越大，里面存在大量冗余命令（比如多次修改同一个key、无效的删除命令）。AOF重写就是Redis后台自动触发的机制：fork子进程，读取当前内存中的最新数据，生成一组最简命令替换旧的冗余日志，大幅压缩文件体积，且不会丢失数据。重写过程不会阻塞主线程，不影响业务正常运行。4、生产环境RDB和AOF怎么配置？主流方案：同时开启RDB+AOF优先用AOF保证数据不丢失，兜底用RDB做快速恢复和冷备份。Redis重启恢复数据时，会优先加载AOF文件，因为数据完整性更高。不建议只开RDB：存在数据丢失风险；不建议只开AOF：恢复速度慢，无高效备份文件。三、Redis过期删除与内存淘汰1、Rediskey过期删除策略有哪些？Rediskey设置过期时间后，不会实时删除，采用「惰性删除+定期删除」结合的策略：惰性删除：key过期后不会立刻删，等到下次客户端访问这个key时，Redis先判断是否过期，过期则直接删除并返回空。

优点：节省CPU资源，不用主动遍历；缺点：大量过期key长期不被访问，会一直占用内存。定期删除：Redis后台定时随机抽取一批设置了过期时间的key，检查并删除过期key，循环遍历所有过期字典。

优点：解决惰性删除的内存积压问题；缺点：是随机抽样，无法删除所有过期key。两种策略互补，既不浪费CPU，又能最大限度释放内存。2、Redis内存淘汰机制有哪些？分别适用场景？当Redis内存达到最大限制，且还有新数据写入时，会触发内存淘汰策略，一共6种：noeviction（默认）：不淘汰任何数据，内存满了直接报错，拒绝写入。适合数据量固定、不允许丢数据的场景。allkeys-lru：从所有key中，淘汰最近最少使用的key。最常用，适合绝大多数缓存场景。volatile-lru：只从设置了过期时间的key中，淘汰最近最少使用的key。适合部分热点数据永久保留的场景。allkeys-random：随机淘汰任意key，几乎不用。volatile-random：随机淘汰过期key，几乎不用。volatile-ttl：优先淘汰剩余过期时间最短的key。适合需要优先清理快过期数据的场景。生产环境allkeys-lru是首选，适配大部分业务缓存场景。四、缓存经典问题（击穿、穿透、雪崩）1、什么是缓存穿透？怎么解决？定义：客户端查询Redis和数据库都不存在的数据，比如恶意请求随机无效ID，请求直接穿透到数据库，大量无效请求会压垮数据库。解决方案：空值缓存：查询数据库为空时，在Redis缓存空值，设置短过期时间，避免重复穿透。布隆过滤器：提前将所有有效数据ID存入布隆过滤器，请求先过过滤器，无效请求直接拦截。接口限流、参数校验：拦截非法参数、恶意高频请求。2、什么是缓存击穿？怎么解决？定义：热点key过期瞬间，大量并发请求同时访问该key，缓存失效，所有请求直接打向数据库，瞬间压垮库。解决方案：热点key永不过期：对核心热点数据，不设置过期时间，从根源避免击穿。互斥锁：缓存失效时，只允许一个请求查询数据库并更新缓存，其他请求等待重试。过期时间随机偏移：批量key设置过期时间时，增加随机秒数，避免批量同时过期。3、什么是缓存雪崩？怎么解决？定义：大量缓存key同时过期，或者Redis服务宕机，导致所有请求全部访问数据库，造成数据库压力过载、服务瘫痪。解决方案：过期时间打散：给缓存过期时间加随机值，避免批量过期。搭建Redis高可用架构：主从+哨兵/集群，避免单点宕机。服务降级、熔断：缓存失效时，直接返回默认数据，拒绝大量请求访问数据库。多级缓存：本地缓存（Caffeine）+Redis分布式缓存，双重保障。4、缓存和数据库数据一致性问题怎么解决？生产环境无法做到绝对实时一致，只能保证最终一致，主流方案：常规方案（先更新数据库，再删除缓存）：业务更新数据时，先改MySQL，成功后删除Redis缓存，下次查询自动加载最新数据。性价比最高，适合绝大多数场景。延迟双删：更新数据后立刻删缓存，间隔几百毫秒再删一次，解决并发更新导致的缓存脏数据。定时任务兜底：定时同步数据库数据到缓存，清理脏数据。高一致性场景：采用Canal监听MySQLbinlog，实时更新/删除缓存，数据一致性更高。不推荐先删缓存再更新数据库，极易出现短时间脏数据问题。五、Redis高可用（主从、哨兵、集群）1、Redis主从复制原理？主从复制就是一台主节点（master）负责读写，多台从节点（slave）同步主节点数据，从节点默认只读，分担读压力，实现读写分离。复制过程分三步：全量复制：从节点首次连接主节点，主节点执行bgsave生成RDB快照，发送给从节点，从节点加载快照完成初始化。增量复制：全量同步后，主节点后续的写命令，实时同步给从节点。断线重连：从节点断线重连后，通过复制偏移量和积压缓冲区，同步断线期间缺失的数据，无需全量复制。缺点：主从架构没有自动故障转移能力，主节点宕机后，需要手动切换主从，无法保证高可用。2、哨兵模式的作用和原理？哨兵是基于主从架构的高可用方案，哨兵是独立的进程，一般部署3个，核心作用：监控、故障转移、配置通知。监控：实时监测主节点、从节点的健康状态。故障判定：多个哨兵共同投票，确认主节点客观下线，避免误判。自动转移：主节点宕机后，哨兵自动选举最优从节点升级为新主节点，其他从节点同步新主节点数据。配置通知：将新的主节点地址同步给客户端，业务自动切换连接。适用场景：数据量不大、需要高可用、无需分片扩容的业务。3、RedisCluster集群原理？哈希槽机制？Redis集群是分布式分片方案，解决单节点内存上限、并发上限问题，支持海量数据存储和水平扩容。核心是哈希槽（slot）机制：集群总共16384个哈希槽，每个主节点分配固定数量的槽位。写入key时，通过CRC16算法计算key的哈希值，对16384取模，得到对应的槽位，从而定位到对应主节点存储数据。集群特点：支持水平扩容，新增节点只需迁移部分槽位，不影响业务。每个主节点搭配从节点，单个节点宕机不影响整体集群可用。支持读写分离，分担集群压力。缺点：不支持跨槽位多key批量操作，事务支持有限。六、Redis分布式锁1、Redis分布式锁实现原理？分布式锁核心目的：保证分布式环境下，同一时间只有一个线程执行临界代码。主流实现命令：SETkeyvalueNXEX过期时间NX：key不存在才创建，保证加锁互斥性。EX：设置锁过期时间，防止服务宕机导致死锁。2、分布式锁存在的问题及解决方案？问题1：锁过期但业务没执行完，导致锁失效、并发冲突。

解决：开启锁续期机制（看门狗），业务未结束时，自动延长锁过期时间。问题2：误删别人的锁，线程执行慢，锁过期被其他线程获取，原线程删锁导致误释放。

解决：锁的value存储唯一ID，删锁前先判断ID，匹配成功再删除，且必须用Lua脚本保证「判断+删除」原子性。问题3：主从延迟导致锁失效，主节点加锁成功，未同步到从节点就宕机，从节点升级后主锁丢失。

解决：使用Redlock算法，或优先使用Zookeeper分布式锁解决强一致性场景。3、Redisson了解吗？核心优势？Redisson是Java最常用的Redis分布式锁框架，封装了分布式锁的各种复杂逻辑，不用自己手写Lua脚本、续期逻辑。核心优势：自带看门狗续期机制，自动解决锁过期问题。支持可重入锁、公平锁、读写锁、联锁等多种锁模式。所有加锁、释放锁逻辑基于Lua脚本，保证原子性。自动处理锁误删、并发竞争问题，稳定性远高于手写锁。七、Redis高频疑难问题1、Redis为什么不适合存储大量冷数据？Redis是内存数据库，内存资源昂贵，大量冷数据长期占用内存，会浪费服务器资源，还会导致热点数据被淘汰，降低缓存命中率。冷数据更适合用MySQL、ES等磁盘数据库存储。2、Redis事务了解吗？和MySQL事务区别？Redis事务通过MULTI、EXEC、DISCARD、WATCH实现，核心是批量命令一次性执行。和MySQL事务最大区别：Redis事务不支持回滚。如果事务中某条命令语法错误，整个事务会终止；如果是运行时逻辑错误，会跳过错误命令，继续执行后续命令，无法回滚。所