2026吃透Redis面试夺命连环85问3天学会redis分布式锁redis缓存redis集群redis面试题这绝对是Redis面试天花板核心能力速览能力项说明主题类别Redis 分布式锁、缓存设计、集群架构、底层原理、面试问答适用人群Java/后端开发、系统架构师、准备 Redis 面试的候选人核心技能分布式锁实现与原理、缓存穿透/击穿/雪崩治理、Redis Cluster/哨兵/主从架构必备基础Redis 基本命令、一种编程语言以 Java 为例、基础网络知识推荐环境Linux 服务器或本地虚拟机Redis 6.x/7.xJava 8启动方式Redis 源码编译 / Docker 容器 / 云 Redis 实例是否支持 API支持Redis 提供 RESPE 协议标准接口批量任务支持可通过 Pipeline、Lua 脚本、SCAN 实现批量操作先看结论2026 年的 Redis 面试已经从“会不会用”进化到“能不能讲清楚为什么”。面试官不再满足于听到“Redis 是单线程的”“缓存能抗压”这种结论而是一层层追问Why 单线程还快分布式锁到底怎么保证原子性Cluster 扩缩容时槽位怎么迁移缓存击穿和缓存雪崩的解决思路有什么区别这篇文章把 Redis 面试中最常出现的 85 个问题整理成一张知识网络按“分布式锁、缓存、集群、底层原理、面试突击”五个方向切分配合可执行的本地环境搭建步骤和 Java 实战代码让你在 3 天内形成自己的面试答题体系而不是死背八股。1. Redis 面试准备的前提先把环境跑起来1.1 本地安装 Redis准备面试和写 demo 之前先把 Redis 跑在本地。最省事的方式是用 Docker也可以直接用源码编译。# 方式一使用 Docker 启动 Redis 7.x docker run -d --name redis-local \ -p 6379:6379 \ -v redis-data:/data \ redis:7-alpine # 方式二编译安装 Redis 7.x wget https://download.redis.io/releases/redis-7.0.14.tar.gz tar -xzf redis-7.0.14.tar.gz cd redis-7.0.14 make make install # 启动 redis-server --port 6379 --daemonize yes redis-cli -p 6379 ping1.2 确认 Redis 版本安装完成后用redis-cli --version查看版本。2026 年的面试里Redis 6.x 已经开始淘汰Redis 7.x 是主流Redis Stack带 JSON、Bloom Filter、Search 模块也在很多互联网公司落地。如果只背旧版知识点面试时很容易被版本迭代问题问住。1.3 准备一个 Java 工程Java 后端面试中Redis 相关题目基本绕不开 Jedis 和 Lettuce以及 Spring Data Redis。准备一个 Spring Boot 项目引入依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.redisson/groupId artifactIdredisson-spring-boot-starter/artifactId version3.27.2/version /dependency这个工程后续用来实战分布式锁、缓存和 Pipeline 用例。2. 2026 Redis 面试核心题型分布先把 85 问做成一张分类地图后面按模块展开。模块常考问题数量占比典型问题Redis 数据结构和底层实现20%SDS、跳表、压缩列表、quicklist、listpack 的区别缓存设计25%缓存穿透、击穿、雪崩、一致性、失效策略分布式锁20%SET NX、Redisson、Redlock、锁续期、可重入高可用与集群20%主从复制、哨兵、Cluster 槽位、脑裂持久化与性能优化10%RDB/AOF、Pipeline、事务、Lua 脚本综合设计题5%电商秒杀、排行榜、好友关注、滑动窗口限流从热搜词“Redis分布式锁、缓存失效、分布式缓存、服务器集群”能看出面试大概率不会只问孤立的命令而是把 Redis 放进一个业务场景里比如“秒杀系统怎么防止超卖”“订单缓存怎么保证一致性”“Redis 集群扩容后数据怎么迁移”。这要求你既有底层原理基础又有方案设计能力。3. Redis 底层数据结构与字符串实现3.1 为什么 Redis 快Redis 常用“单线程 多路复用”来解释核心优势。严格来说Redis 的网络 IO 和命令执行主线程是单线程但对持久化、异步删除、部分模块任务用了额外线程。单线程避免了多线程上下文切换和锁竞争但这只是表象。真正让 Redis 快的是纯内存操作。高效的数据结构设计例如 SDS 和跳表。IO 多路复用机制基于 epoll 处理大量连接。命令执行长度短且大部分命令是 O(1) 或 O(logN)。面试时不要只说“单线程”要往下拆为什么单线程还能支撑高并发答案是基于内存和 IO 多路复用。为什么 6.0 以后引入多线程答案是为了优化网络 IO 的读写性能但命令执行仍然是单线程所以不会因为多线程引入数据竞争。3.2 String 字符串SDS 而不是 C 字符串Redis 的 String 底层叫 SDSSimple Dynamic String它不是 C 语言的 char 数组。SDS 的设计解决了三个问题获取字符串长度的时间复杂度从 O(N) 变成 O(1)。避免缓冲区溢出SDS 会自动扩容。减少修改字符串时频繁分配内存通过空间预分配和惰性空间释放做优化。面试时如果能画出 SDS 结构struct sdshdr { int len; // 已使用的长度 int alloc; // 已分配的总长度 char buf[]; // 字节数组 };3.3 字符串面试高频场景缓存对象把对象序列化为 JSON 存到 String。计数器INCR、DECR、INCRBY用于点赞数、访问量。分布式 IDINCR 时间戳。限流SET key value EX seconds配合计数。4. List、Hash、Set、ZSet 与底层实现4.1 ListList 在 Redis 3.2 之前的底层的 ziplist之后是 quicklist。quicklist 本质上是双向链表 多个压缩列表节点组成减少链表的指针开销也降低内存碎片。List 高频面试题怎么用 List 实现消息队列LPUSH生产者BRPOP消费者阻塞读取。怎么取固定窗口内的最新内容LRANGE key 0 N。为什么 Redis 的 List 做消息队列不靠谱因为消息可能丢失、没有确认机制、没有回溯和死信队列专业场景还是要用 MQ。4.2 HashHash 底层是 ziplist 或 hashtable。当 field 数量少且 value 长度短时用 ziplist 当超过阈值后转为 hashtable。Hash 高频场景存储对象属性比如用户信息HSET user:1001 name zhangsan age 25。减少序列化转换开销比 String 存 JSON 更便于修改单个字段。电商购物车每个用户一整个 Hashfield 是商品 IDvalue 是数量。面试常问Hash 和 String 存对象怎么选如果对象经常需要整体读取String 更合适如果只修改其中某个字段Hash 更省内存和带宽。4.3 SetSet 底层是 intset 或 hashtable。它的核心特性是无序、不允许重复、支持集合运算。高频考题用户标签、兴趣推荐SADD添加SINTER求共同标签。抽奖去重SPOP随机弹出。点赞去重SADD保证一个用户只能点赞一次。4.4 ZSetZSet 是面试重灾区。底层是跳表skiplist dict。dict 用于存储 member 到 score 的映射跳表用于按 score 排序和范围查询。高频考题排行榜ZADD leaderboard 100 user1ZREVRANGE leaderboard 0 9 WITHSCORES。延迟队列score 存未来执行时间戳消费端用ZRANGEBYSCORE取到期任务。滑动窗口限流score 用时间戳每次请求前删除窗口外数据再统计窗口内数量。面试官常问为什么 ZSet 用跳表而不用红黑树答案是跳表实现简单区间查找性能稳定而且 Redis 需要支持ZRANGE这类范围操作。Redis 的作者 antirez 在源码注释中提到跳表比红黑树更易实现、更易调试这是官方层面的理由。5. Redis 持久化RDB 与 AOF5.1 RDB 快照RDB 是全量快照将某一时刻的数据写入二进制文件。默认触发策略是save 900 1、save 300 10、save 60 10000意味着 900 秒内至少 1 次修改就触发快照。RDB 的优点文件紧凑适合备份和灾难恢复。恢复速度快。子进程做 fork主进程不阻塞磁盘 IO。RDB 的缺点可能会丢失上一次快照之后的数据。fork 时如果内存量巨大短暂阻塞风险存在。面试题RDB 怎么做到不阻塞主进程答案是使用 fork 写时复制Copy On Write机制。fork 瞬间子进程共享父进程内存之后主进程修改某页内存时才会复制出一个副本因此 RDB 过程中主进程通常可以继续提供写服务但 fork 本身需要消耗时间。5.2 AOF 日志AOF 记录每个写命令以追加方式写入文件通过appendfsync策略控制磁盘同步配置项说明安全性always每次写入都刷盘最安全性能低everysec每秒刷一次默认最多丢 1 秒数据no由操作系统决定性能高安全性低AOF 重写当文件过大时Redis 会根据当前数据生成最小命令集合并写成一个新文件。重写过程也是通过子进程完成同时主进程将新写命令缓存下来重写结束后再追加。5.3 怎么选2026 年的面试好的回答是“生产环境通常两种都开AOF 保证数据安全RDB 做快速恢复。Redis 重启时优先加载 AOF因为 AOF 数据完整性更高。如果允许丢几分钟数据只开 RDB 也可以。”6. Redis 缓存三大问题穿透、击穿、雪崩这是 Redis 面试题中命中率最高的模块。热搜词“缓存失效、缓存治理、线上缓存”都和这一块密切相关。6.1 缓存穿透概念查询一个不存在的数据Redis 查不到数据库也查不到请求直接打到数据库。如果有恶意攻击者不断构造不存在的 key数据库会被拖垮。解决思路缓存空值不存在的 key 也缓存一个空值设置短过期时间比如 60 秒。布隆过滤器在缓存前加一层 Bloom Filter判断 key 是否可能存在。参数校验接口层拦截非法请求。代码示例public String getUserById(String userId) { // 1. 查 Redis String user redisTemplate.opsForValue().get(user: userId); if (user ! null) { return user; } // 2. 缓存中没有查数据库 UserDO userDO userMapper.selectById(userId); if (userDO null) { // 3. 缓存空值防止穿透 redisTemplate.opsForValue().set(user: userId, , 60, TimeUnit.SECONDS); return null; } // 4. 回写缓存 String json JSON.toJSONString(userDO); redisTemplate.opsForValue().set(user: userId, json, 30, TimeUnit.MINUTES); return json; }6.2 缓存击穿概念某个热 key 在缓存过期的一瞬间大量并发请求同时打到数据库。它和穿透的区别是key 在数据库里存在只是缓存刚好过期。解决思路互斥锁重建缓存时加锁只让一个线程查数据库并写缓存其他线程等待重试。逻辑过期不给 key 设置物理过期时间而是在 value 里保存逻辑过期时间后台异步更新。热点 key 永不过期物理上不设置过期时间但在逻辑层做定时刷新。互斥锁代码示例分布式锁的应用场景public String queryHotData(String key) { String value redisTemplate.opsForValue().get(key); if (value ! null) { return value; } String lockKey lock: key; String lockValue UUID.randomUUID().toString(); Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, lockValue, 10, TimeUnit.SECONDS); if (Boolean.TRUE.equals(locked)) { try { // 双重检查 value redisTemplate.opsForValue().get(key); if (value ! null) { return value; } // 查数据库 value queryDatabase(key); redisTemplate.opsForValue().set(key, value, 30, TimeUnit.MINUTES); return value; } finally { // 释放锁使用 Lua 脚本保证原子性 String script if redis.call(get,KEYS[1]) ARGV[1] then return redis.call(del,KEYS[1]) else return 0 end; redisTemplate.execute(new DefaultRedisScript(script, Long.class), Collections.singletonList(lockKey), lockValue); } } // 没有获取到锁等待后重试 try { Thread.sleep(50); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return queryHotData(key); }6.3 缓存雪崩概念大量 key 在同一时间集中过期或者 Redis 整个实例宕机导致大量请求直接压到数据库。解决思路过期时间加随机值让过期时间分散避免“集体过期”。多级缓存本地缓存Caffeine Redis 分布式缓存。Redis 高可用主从 哨兵或者 Cluster 模式。服务降级与熔断数据库压力过大时快速失败或返回空数据。构建缓存加锁参考缓存击穿的互斥锁方案。代码示例// 给过期时间加随机值 int baseTimeout 60 * 60; int randomTimeout new Random().nextInt(600); redisTemplate.opsForValue() .set(key, value, baseTimeout randomTimeout, TimeUnit.SECONDS);6.4 缓存一致性先更新数据库还是先删缓存这是个“没有唯一标准答案”的问题但面试官要看你能不能把两种方案的利弊讲清。方案一先更新数据库再删除缓存。优点简单。缺点删除缓存失败时缓存里是旧数据。方案二先删缓存再更新数据库。缺点并发下存在“先删缓存后写数据库中间有请求把旧数据写回缓存”的问题。方案三延迟双删。public void updateUser(UserDO userDO) { // 1. 先删缓存 redisTemplate.delete(user: userDO.getId()); // 2. 更新数据库 userMapper.updateById(userDO); // 3. 延迟 500ms 后再次删除 scheduledExecutor.schedule(() - { redisTemplate.delete(user: userDO.getId()); }, 500, TimeUnit.MILLISECONDS); }方案四订阅 binlog如 Canal 删除缓存。最稳妥适合对一致性要求极高的场景。面试回答的口径是缓存一致性无法做到完全强一致只能根据业务容忍度选择最终一致性方案。核心是“缓存只是加速层数据库才是最终数据源”。7. Redis 分布式锁从 SET NX 到 Redisson 到 Redlock7.1 什么是分布式锁分布式锁是为了解决多个进程或服务实例之间互斥访问共享资源的问题。Java 里的synchronized和ReentrantLock只能锁单机分布式环境下必须借助外部存储。Redis 分布式锁的基本原则互斥性任意时刻只有一个实例能持有锁。原子性加锁和释放锁要保证原子操作。超时释放避免锁持有者宕机导致死锁。可重入性同一个线程可以重复获取锁。自动续期业务执行时间超过锁超时时间时能够自动续期。7.2 基础实现SET NX EX最简单的加锁命令SET lock:order:1001 uuid-xxx NX EX 30NX表示只有当 key 不存在时才设置成功EX 30表示锁 30 秒后自动过期。对应的 Java 代码SetParams params SetParams.setParams().nx().ex(Duration.ofSeconds(30)); String result jedis.set(lock:order:1001, requestId, params); if (OK.equals(result)) { // 获取锁成功 }释放锁不是简单的DEL而是要验证 value 是自己的然后执行删除。如果直接DEL可能删掉别人的锁。正确释放锁必须用 Lua 脚本if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end这段 Lua 脚本保证了“判断 key 的 value 是否等于当前持有锁的标识”和“删除 key”两个操作的原子性。面试时请背诵这段脚本并解释为什么不能先用GET判断再用DEL因为GET和DEL是两条命令中间可能发生其他线程持有锁或者锁已经过期并已被别人获取直接DEL会误删别人的锁。7.3 原生命令方案有哪些缺陷没有自动续期。如果业务执行超过锁过期时间锁自动失效其他线程会进入临界区。不具备可重入能力。加锁失败后需要自己实现轮询等待。解决方式使用 Redisson 客户端。它内置了看门狗WatchDog机制和可重入锁实现。7.4 Redisson 分布式锁实战Autowired private RedissonClient redissonClient; public void createOrder(OrderDTO orderDTO) { String lockKey lock:order: orderDTO.getOrderId(); RLock lock redissonClient.getLock(lockKey); boolean isLocked false; try { // 尝试加锁最多等待 5 秒自动释放 30 秒 isLocked lock.tryLock(5, 30, TimeUnit.SECONDS); if (!isLocked) { throw new RuntimeException(系统繁忙请稍后重试); } // 业务逻辑检查库存、创建订单、扣减库存 doCreateOrder(orderDTO); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new RuntimeException(获取锁被中断, e); } finally { if (isLocked lock.isHeldByCurrentThread()) { lock.unlock(); } } }Redisson 的 WatchDog 默认在锁过期前自动续期默认续期时间是 30 秒。如果你没有显式设置 leaseTime看门狗就会启动。如果你在tryLock中指定了leaseTime看门狗不会自动续期。面试官常问看门狗的实现原理是什么回答思路是Redisson 在获取锁成功后会启动一个定时任务每隔leaseTime / 3时间也就是默认 10 秒检查锁是否仍然被自己持有如果是就重置锁的过期时间到 30 秒。任务在当前线程释放锁后停止。7.5 Redlock多节点高可用分布式锁Redlock 是 Redis 官方提出的算法核心是“获取锁请求依次发给 N 个独立 Redis Master超过半数节点加锁成功且加锁总耗时小于锁过期时间才算获取锁成功”。Config config new Config(); config.useSentinelServers() .addSentinelAddress(redis://node1:6379, redis://node2:6379, redis://node3:6379) .setMasterName(mymaster); RedissonClient client Redisson.create(config); RLock lock client.getLock(redlock:order);Redlock 的争议点存在 Redis 节点时钟跳跃导致的锁失效问题。客户端持有锁期间发生 GC 停顿可能导致锁过期但业务还在执行。并不适合所有场景不少架构师认为它不如“数据库唯一索引 事务”。面试回答建议先讲清楚 Redlock 的算法过程再补充它的应用边界。能提到“Martin Kleppmann 和 antirez 关于 Redlock 的争论”是加分项这证明你不仅会背框架还了解分布式系统领域的经典讨论。7.6 分布式锁面试必背清单分布式锁要满足哪些条件SET NX EX 和 SETNX 的区别是什么为什么释放锁要用 Lua 脚本Redisson 看门狗的工作原理是什么Redlock 怎么解决主节点宕机问题Redlock 有什么缺点分布式锁和数据库悲观锁、乐观锁怎么选秒杀场景中分布式锁和 Redis 原子操作DECR谁更好锁重入怎么实现锁的粒度怎么设计建议按用户维度、订单维度拆锁而不是全局锁。8. Redis 事务与 Lua 脚本8.1 Redis 事务的基本机制Redis 事务通过MULTI、EXEC、DISCARD、WATCH实现。MULTI开启事务。EXEC执行事务队列中的所有命令。DISCARD丢弃事务。WATCH乐观锁监听 key如果执行时 key 被其他客户端修改事务失败。Redis 事务不支持回滚。如果事务执行过程中某条命令出错前面的命令已经生效后面的命令继续执行不会回滚。面试题Redis 事务为什么不能回滚官方文档的观点是Redis 命令只有在语法错误或类型错误时才会失败大部分错误可以通过开发阶段发现引入回滚会显著增加复杂度与 Redis 追求简单高效的设计原则冲突。8.2 Lua 脚本真正的原子性Redis 2.6 开始支持 Lua 脚本EVAL命令会原子执行脚本整个脚本执行期间不会插入其他命令。这是分布式锁释放、限流、批量操作的底层基础。-- 简单的库存扣减脚本 local stock redis.call(GET, KEYS[1]) if not stock then return -1 end if tonumber(stock) tonumber(ARGV[1]) then return 0 end redis.call(DECRBY, KEYS[1], ARGV[1]) return 1调用脚本redis-cli -p 6379 EVAL ... 1 stock:1001 1在 Redisson 源码中很多操作都用 Lua 脚本封装。比如 tryLock 的加锁逻辑就是一段 Luaif (redis.call(exists, KEYS[1]) 0) then redis.call(hset, KEYS[1], ARGV[2], 1); redis.call(pexpire, KEYS[1], ARGV[1]); return nil; end if (redis.call(hexists, KEYS[1], ARGV[2]) 1) then redis.call(hincrby, KEYS[1], ARGV[2], 1); redis.call(pexpire, KEYS[1], ARGV[1]); return nil; end return redis.call(pttl, KEYS[1]);这里的hset说明 Redisson 可重入锁是用 Hash 结构实现的field 是线程唯一标识value 是重入计数。8.3 Pipeline 与批量操作Pipeline 不是事务。它通过一次网络请求发送多条命令减少 RTT往返时延适用于批量写入场景。Redis Cluster 模式下Pipeline 要求命令的 key 必须落在同一个槽位否则可能报错。ListObject results redisTemplate.executePipelined((RedisCallbackObject) connection - { for (int i 0; i 10000; i) { connection.stringCommands().set( (pipeline:key: i).getBytes(), (value: i).getBytes()); } return null; });9. Redis 集群架构主从、哨兵、Cluster9.1 主从复制主从复制是 Redis 高可用的基础。一个 Master 可以挂多个 SlaveSlave 只提供读服务。同步过程简要描述Slave 发送PSYNC命令。Master 执行BGSAVE生成 RDB 文件同时把后续写命令缓存到缓冲区。将 RDB 文件发给 SlaveSlave 加载。把缓冲区的写命令发送给 SlaveSlave 回放最终达到一致。主从复制的坑复制风暴多个 Slave 同时全量复制Master 压力大。主从延迟从节点读取到旧数据。脑裂网络分区时Master 和 Slave 都能对外提供写服务恢复后数据冲突。9.2 哨兵模式哨兵Sentinel负责监控主节点状态主节点宕机后自动从从节点中选举出一个新的主节点。工作流程每个哨兵周期性向所有节点发送PING。主观下线某个哨兵发现主节点超时。客观下线多个哨兵投票确认主节点真的不可用。选举 Leader 哨兵。从从节点中选出新主节点。通知其他从节点和新客户端更新主节点地址。哨兵模式解决了主从复制中的“主节点宕机后无法自动切换”的问题但整个集群仍然只有一个主节点写写能力有限。9.3 Redis Cluster真正的分布式Redis Cluster 采用无中心化架构数据通过哈希槽Hash Slot分布。整个集群默认有 16384 个槽位每个节点负责一部分槽位。# 创建集群三个主节点 三个从节点 redis-cli --cluster create \ 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 \ 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \ --cluster-replicas 1槽位计算公式hash_slot CRC16(key) % 16384Cluster 模式下客户端连接任意节点都能访问。如果 key 不在当前节点节点会返回MOVED重定向指令客户端根据返回信息重新请求正确的节点。(error) MOVED 866 127.0.0.1:7002Cluster 的面试核心点为什么是 16384 个槽因为 CRC16 算法产生 16 位二进制数取值范围是 0 到 65535。Redis 作者经过评估认为 16384 个槽在集群规模、心跳消息传输大小和迁移复杂度之间达到了合理平衡。为什么不把每个节点上的数据用一致性哈希一致性哈希需要客户端做哈希环计算Cluster 的槽位机制让数据迁移更精确。Cluster 扩容过程新节点加入从其他节点迁移部分槽位数据。整个迁移过程中客户端访问被迁移的 key会收到ASK重定向。9.4 集群模式下的分布式锁Redis Cluster 模式下使用 Redisson 仍然可行但它的锁天然绑定了某个 key通过GETSLOT找到对应节点。Redlock 方案在 Cluster 环境中依然有适用场景但复杂度会上升。更稳妥的做法是结合业务把锁的 key 设计成同一个槽位比如lock:{order}:{orderId}利用哈希标签保证同一个订单的锁落在同一节点。10. Redis 高级用法与常见设计题10.1 基于 Redis 的限流方案固定窗口限流String key rate:limit: userId; Long count redisTemplate.opsForValue().increment(key); if (count 1) { redisTemplate.expire(key, 60, TimeUnit.SECONDS); } if (count 100) { throw new RuntimeException(请求过于频繁); }滑动窗口限流用 ZSetString key rate:sliding: userId; long now System.currentTimeMillis(); long windowSize 60_000L; int maxCount 100; redisTemplate.opsForZSet().removeRangeByScore(key, 0, now - windowSize); Long count redisTemplate.opsForZSet().zCard(key); if (count ! null count maxCount) { throw new RuntimeException(请求过于频繁); } redisTemplate.opsForZSet().add(key, String.valueOf(now), now); redisTemplate.expire(key, 60, TimeUnit.SECONDS);令牌桶算法更适合需要突发流量控制的场景但在纯 Redis 实现中需要维护令牌数和上次补充时间通常用 Lua 脚本完成。10.2 排行榜// 添加分数 redisTemplate.opsForZSet().add(rank:game:1001, player:1, 1000); redisTemplate.opsForZSet().incrementScore(rank:game:1001, player:2, 500); // 获取前 10 SetZSetOperations.TypedTupleObject top10 redisTemplate.opsForZSet().reverseRangeWithScores(rank:game:1001, 0, 9); // 获取某个玩家的排名 Long rank redisTemplate.opsForZSet().reverseRank(rank:game:1001, player:1);10.3 延迟队列String key delay:order:timeout; // 生产端订单创建 30 分钟后自动取消 redisTemplate.opsForZSet().add(key, orderId, System.currentTimeMillis() 30 * 60 * 1000); // 消费端轮询到期元素 SetObject expiredOrders redisTemplate.opsForZSet() .rangeByScore(key, 0, System.currentTimeMillis(), 0, 100);10.4 秒杀系统设计秒杀场景的核心是“防止超卖 限制并发”。Redis 方案预热库存到 Redis用DECR扣减。拦截重复请求用 Set 保存用户 ID。异步下单扣减成功后发送 MQ数据库异步完成订单写入。public boolean seckill(String userId, String goodsId) { // 1. 判断是否已经购买过 Boolean hasUser redisTemplate.opsForSet().isMember(seckill:users: goodsId, userId); if (Boolean.TRUE.equals(hasUser)) { return false; } // 2. 扣减库存 Long stock redisTemplate.opsForValue().decrement(seckill:stock: goodsId); if (stock null || stock 0) { // 恢复库存并返回失败 redisTemplate.opsForValue().increment(seckill:stock: goodsId); return false; } // 3. 记录用户 redisTemplate.opsForSet().add(seckill:users: goodsId, userId); return true; }真实生产环境中DECR扣减后如果数据库写失败需要回补库存整个链路还需要配合事务消息做最终一致性。面试时注意点只讲 Redis 扣库存是不够的要讲清楚“Redis 做前置拦截数据库做最终确认”。11. Redis 性能优化与常见问题排查11.1 大 Key 问题大 Key 指的是 String 类型 value 过大或集合类型元素数量过多。大 Key 会导致删除时阻塞主线程。迁移时占用大量带宽。慢查询增多。排查方式redis-cli --bigkeys处理方式拆分大 key。对 Hash 使用HSCAN分批删除。使用UNLINK异步删除。11.2 热 Key 问题热 Key 指某个 key 访问量极高单节点成为瓶颈。解决思路本地缓存 Redis。访问打散hotkey_1、hotkey_2多个副本读请求随机读任一副本写时更新所有副本。热点 key 永不过期 后台刷新。11.3 慢查询通过SLOWLOG GET查看慢查询命令。redis-cli -p 6379 slowlog get 10常见的慢命令KEYS *、HGETALL、SMEMBERS、ZRANGEBYSCORE在一个超大的 key 上执行。生产环境禁止使用KEYS *应该用SCAN代替。11.4 内存碎片与淘汰策略Redis 删除过期 key 使用惰性删除 定期删除。内存达到maxmemory上限后触发淘汰策略策略含义noeviction不淘汰直接报错allkeys-lru对全部 key 使用 LRU 算法volatile-lru对设置了过期时间的 key 使用 LRUallkeys-random随机淘汰volatile-random对设置过期时间的 key 随机淘汰volatile-ttl对设置过期时间的 key 中剩余寿命更短的 key 优先淘汰高频面试题Redis 的 LRU 是真正的 LRU 吗不是。Redis 的近似 LRU 通过抽样方式淘汰默认采样 5 个 key从中选出最近最少使用的 key 淘汰因此它不是完全精确的 LRU。11.5 Redis 连接数打满怎么办排查思路INFO clients查看当前连接数。CONFIG GET maxclients查看最大连接数限制。检查客户端是否有连接泄漏。考虑使用连接池。Spring Data Redis 的 Lettuce 默认基于 Netty连接是共享的连接数通常不是瓶颈。如果是 Jedis务必配置 JedisPool。12. 2026 Redis 面试答题通用框架12.1 是什么 - 解决了什么问题 - 底层机制 - 优缺点 - 使用场景这套五段式结构几乎适用所有 Redis 面试题。比如被问到“Redis 主从复制”不要只答“主节点写从节点读”按下面的顺序组织回答是什么主从复制是一台主节点和一台或多台从节点之间的数据副本同步机制。解决什么问题读写分离、故障转移的节点基础、横向扩展读能力。底层机制全量同步 增量同步复制积压缓冲区PSYNC 命令。优缺点实现简单、读扩展方便但主从延迟存在故障自动转移需要哨兵。使用场景读多写少、一致性要求不高的场景。12.2 缓存一致性问题的万能套路先确认一致性等级强一致还是最终一致。给出技术方案Cache Aside、延迟双删、binlog 订阅。指出潜在问题删除缓存失败、并发窗口。给出补偿方案消息队列重试本地消息表。挑明结论分布式环境没有免费的强一致最终一致是常态。12.3 像面试官一样总结核心技术面试官问 Redis 时会格外看重你对“为什么”的把握。随便抽一个知识点比如“为什么 Redis 使用单线程执行命令”你如果能从 IO 多路复用、内存访问时延、避免锁竞争、命令原子性四个角度回答基本上就能让面试官认可你的基础。13. 3 天突击路线规划第 1 天数据结构、持久化、缓存问题上午Redis 五大数据结构 底层实现SDS、跳表、quicklist。下午RDB/AOF 缓存穿透、击穿、雪崩 缓存一致性。晚上用 Java 写缓存三大问题的 demo把缓存空值、互斥锁、延迟双删的代码跑通。第 2 天分布式锁、事务、Lua上午SET NX EX、Lua 脚本、Redisson 可重入锁。下午Redlock、看门狗、锁续期、锁粒度、锁误删。晚上用 Redisson 实现一个库存扣减服务模拟并发场景测试超卖。第 3 天集群、性能、综合设计上午主从复制 哨兵模式搭建用redis-cli --cluster搭建 Cluster。下午大 Key、热 Key、慢查询、淘汰策略、Pipeline。晚上刷题。覆盖 85 问特别是设计题秒杀、排行榜、延迟队列、好友关系。14. 常见问题与排查清单问题现象可能原因排查方式解决方案分布式锁失效业务执行时间超过锁过期时间检查业务耗时和锁 leaseTime使用 Redisson 看门狗自动续期缓存击穿热点 key 过期瞬间大量并发请求观察 Redis QPS 和数据库慢 SQL互斥锁、逻辑过期缓存雪崩大量 key 同一时间过期检查过期时间配置过期时间加随机值Redis 内存暴涨大 Key 或配置未限制redis-cli --bigkeysINFO memory拆分 key、设置 maxmemory 策略主从数据不一致网络延迟导致复制延迟INFO replication查看 offset优化网络、考虑强一致场景不用缓存Cluster 写入报 MOVED客户端没有做重定向处理检查客户端版本使用支持 Cluster 的客户端如 Lettuce、Redisson连接数打满客户端没有使用连接池INFO clients增加连接池配置或限制非法连接15. 最佳实践与合规提醒任何缓存方案首先明确业务容忍度允许丢多久数据、允许多大延迟。分布式锁不是万能的DECR、Lua、ZSet 都能在特定场景取代锁。生产环境谨慎使用KEYS、FLUSHALL、CONFIG SET。维护好 Redis 的监控指标包括INFO stats、INFO replication、INFO memory、SLOWLOG。涉及用户隐私数据缓存时必须设置合理过期时间并做数据脱敏。不要用 Redis 存放明文密码、身份证号等敏感信息必须加密存储且符合个人信息保护相关法规要求。对业务中使用的 Redis 命令和脚本做权限控制避免未授权访问。线上 Redis 实例必须配置密码禁止绑定公网 IP。发布新任务或做压测前先在小规模环境验证观察内存和 CPU 变化不要直接在生产环境执行批量脚本。16. 总结与下一步Redis 面试在 2026 年真正拉开差距的地方在于你能否把分布式锁、缓存和集群三个模块打通理解。分布式锁背后的原子性、Redis 事务和 Lua 脚本是一套东西缓存穿透、击穿、雪崩背后是缓存和数据库的一致性模型集群的背后是数据分片、复制和高可用的权衡。建议你先把基础环境搭好再按第一天、第二天、第三天的小步任务逐个验证。最容易踩的坑不是不会背概念而是花大量时间背八股却连SET NX EX和 Lua 脚本都没跑过一遍。真正的胜利是把代码跑通、把现象记录下来、把差异讲清楚这样面试时你说出来的每一个结论才落得了地。