Redis 这个关键词，在 Java 岗位面试里出现的频率大概仅次于 JVM 和 MySQL。这不是空穴来风——校招还是社招，只要你简历上写了"使用 Redis 做了缓存"，面试官大概率会顺着这条线一路追问：数据结构有哪些、底层怎么存的、持久化怎么做的、缓存穿透怎么解决、集群怎么搭的。很多候选人背了一堆八股，被问到"为什么"就卡壳；也有不少开发把概念背得滚瓜烂熟，一落到真实生产场景里就露馅。
这篇文章把我这些年整理的 Redis 应试与实战知识体系做一次完整梳理。既适合准备面试的同学，也适合刚接手 Redis 相关项目的开发，你会发现很多"背过但没理解"的点，在这里都能找到对应的原理、场景和踩坑记录。文章会从数据结构、持久化、缓存三大难题、集群高可用、内存管理、Java 落地避坑这几个维度展开，尽量按面试官追问的思路来组织内容，而不是写成一本冷冰冰的手册。
1. 数据结构不只是背名字：底层实现才是分水岭
1.1 String 的三种编码与使用边界
Redis 有五种基础数据结构，这是最基础的八股。但只背出"String、Hash、List、Set、ZSet"五个名字，面试基本也就停留在及格线了。真正拉开差距的是：每种结构底层是怎么存的、为什么 Redis 要设计多种编码方式、在什么场景下选什么结构。
先说 String。String 在 Redis 内部有三种编码：int、embstr、raw。存整数时直接用 int 编码，省去字符串对象的额外开销；字符串长度小于等于 44 字节时用 embstr，RedisObject 和 SDS 简单动态字符串分配在同一块连续内存里，一次内存分配就能搞定；超过 44 字节就转成 raw，头信息和数据分开分配。为什么是 44？因为 redisObject 头部加 SDS 头加结束符一共占 20 字节，配合 64 字节的一次性分配，44 刚好是数据区的最大容量。面试时能说出"存在阈值转换"这个机制，就说明你真看过底层实现。
String 能做的事远不止缓存 JSON。INCR/DECR 做计数器和发号器，SETNX 做分布式锁的雏形，SETEX 做限流窗口。我印象很深的一个案例：某电商项目的优惠券库存直接用 INCR 的负数判断超卖，比数据库乐观锁的方案省了无数轮询和重试。当然，这个方案有精度和持久化的问题，后面讲分布式锁时再展开。
1.2 集合类型的底层演进
Hash、List、Set、ZSet 四个结构的底层，在 Redis 7.0 前后有比较大的变化，这也是近几年面试题里经常"翻新"的考点。
Hash 在元素少、值小的时候用 ziplist 压缩列表，超过 512 个元素或某个 key 的 value 超过 64 字节就转成 hashtable。为什么小的时候用压缩列表？因为它是一块连续内存，对 CPU 缓存友好，遍历时指针跳转少。缺点也明显：插入删除需要移动内存，所以只适合小规模。
List 早期用 ziplist 或 linkedlist，后来演进成 quicklist——本质是"多个 ziplist 用双向链表串起来"，兼顾内存紧凑和插入删除的灵活性。Redis 7.0 之后又引入 listpack 替代 ziplist，核心原因是 ziplist 存在连锁更新问题：某个节点长度变化可能引发后续节点 prevlen 字段的级联扩容，最坏情况复杂度极高。listpack 每个节点只保存自己的长度，从根上避免了连锁效应。
Set 底层是 intset 或 hashtable。当所有元素都是整数且数量不超过 512 时用 intset，有序数组存储，查找走二分；一旦出现非整数元素或数量超限，就升级成 hashtable。
ZSet 是面试里最爱问的：底层是跳表加哈希表。哈希表负责按成员名查找分数，跳表负责按分数排序和范围查询。为什么用跳表而不用平衡树？官方给出的理由是跳表实现直观、调试简单、内存占用可控，范围查询只需要在多层索引上做几次跳跃，实现复杂度远低于红黑树的再平衡过程。面试答出"跳表用空间换时间，多层索引辅助范围查询"，再加一句"ZSet 在元素少于 128 个时其实也用压缩列表"，这个回答就相当饱满了。
1.3 不常见的结构才是加分项
基础五件套之外，Redis 还提供了 Bitmap、HyperLogLog、Geo、Stream 等扩展结构。面试答完五种基础结构后，如果能主动补一句"我还用过 Bitmap 做签到和布隆过滤器，用 HyperLogLog 做 UV 统计，用 Stream 做轻量消息队列"，往往能让面试官眼前一亮。
Bitmap 本质还是 String，只不过把比特位当作独立的状态位来用。一周签到记录用 7 个 bit 就能存下，GETBIT/SETBIT 操作位，BITCOUNT 统计签到天数。几亿用户做日活统计也可以按天用 Bitmap 存储，位运算做交集并集，性能极其夸张。
HyperLogLog 是概率数据结构，用来做大规模去重计数。原理是哈希后统计二进制串里低位连续零的最大长度，零越多代表基数越大，再配合多个桶做平均修正。误差在 0.81% 左右，但内存固定只有 12KB。做网站 UV 统计、渠道流量去重这类场景非常合适——精确到个位没有意义，内存节省却实实在在。
Stream 在 5.0 引入，是可持久化的消息队列，支持消费者组、ACK 机制。很多团队把 Redis 直接当 MQ 用，我不太推荐在核心链路这么干，Redis 的持久化和消息堆积能力对比专业 MQ 还是弱，但轻量场景下完全够用。特别是配合 XREADGROUP 做消费者组消费，比 List 左进右出的 BRPOP 模式靠谱得多，至少支持消费者确认和未消费消息重新投递。
2. 持久化机制：RDB 与 AOF 的每一步都在做取舍
2.1 RDB 快照的原理与真实代价
RDB 是 Redis 默认的快照持久化方式，生成压缩的二进制文件，默认叫 dump.rdb。触发方式分两类：save 命令同步阻塞执行，bgsave 命令异步后台保存。生产环境一般只用 bgsave 和配置里的自动触发规则——900 秒内 1 个 key 变化、300 秒内 10 个 key 变化、60 秒内 10000 个 key 变化，满足任意一条就触发。
bgsave 的核心是 fork 子进程做快照写入，父进程继续对外服务。这里的关键机制是写时复制（Copy-On-Write）：fork 出的子进程和父进程共享同一份内存页表，子进程开始写快照时，如果父进程刚好修改了某个内存页，内核会先把这一页复制一份给父进程，子进程读到的始终是 fork 那一刻的旧数据。这样一来，快照反映的是 fork 时刻的内存状态，不会混合中间状态。
代价是：写操作越频繁，复制内存页的开销越大，极端情况下会造成父进程短暂阻塞。我见过一个真实案例：实例内存接近 8GB，写入流量又大，bgsave 期间瞬时 CPU 冲高，客户端大面积超时。解决办法是错峰执行 bgsave，同时调低自动触发阈值，避免高流量时段触发快照。
RDB 的致命缺点只有一个：丢数据。因为是定时快照，两次快照之间的写入全丢。默认配置下最坏可能丢 60 秒的数据。缓存场景无所谓，但对一致性要求高的业务就不够看了。
2.2 AOF 日志：写后日志与刷盘策略
AOF 是写后日志——先执行命令，再把命令以 Redis 协议格式追加到文件末尾。为什么是写后而不是写前？因为 Redis 的语法检查在命令执行阶段，写后日志天然避免记录错误命令，而且不会阻塞写命令的执行。代价是：如果宕机恰好发生在"命令执行完、日志还没写入"的窗口期，这步操作还是会丢。
因此才有刷盘策略。AOF 有 appendfsync 三种配置：always 每写一条就 fsync，最安全但性能掉一个量级；everysec 每秒 fsync，最多丢一秒数据，这是默认配置；no 交给操作系统刷盘，速度快但可能丢更多数据。生产环境几乎都用 everysec。我实测过 Redis 官方 benchmark，always 和 everysec 的吞吐差距可以达到五到十倍，大多数业务承受不起 always 的性能开销。
AOF 还有个绕不开的概念叫重写（rewrite）。日志是追加式的，时间长了文件会无限膨胀，所以 Redis 提供 BGREWRITEAOF，fork 子进程把当前内存数据重新写成一份最小化的写命令序列。重写期间父进程的新写命令先积攒在缓冲区，重写完成后合并进去，避免日志丢失。
2.3 混合持久化与生产配置建议
Redis 4.0 之后支持混合持久化，开启 aof-use-rdb-preamble yes 后，AOF 文件前半部分是一份 RDB 快照，后半部分是重写期间的增量命令。这样既保留 RDB 快速加载的优势，又避免 AOF 全量重放太慢。不少团队的生产配置就是：AOF 开启 everysec 加混合持久化，自动 RDB 关掉或保留很低频的阈值。
面试问到"RDB 和 AOF 怎么选"，我的回答思路是看丢数据容忍度。能接受最多丢几分钟、追求加载速度，选 RDB；不能丢太多、能接受性能略降，选 AOF everysec；又想恢复快又不想丢太多，直接混合模式。重点是说出"为什么"——RDB 是某个时间点的快照所以恢复快但丢数据多，AOF 是每条命令的日志所以丢得少但启动要重放。把这条逻辑讲清楚，比单纯念配置项强得多。
3. 缓存三大难题：穿透、击穿、雪崩的完整解法
3.1 穿透：查的是一根本不存在的数据
缓存穿透指的是请求的数据在缓存和数据库里都不存在，导致每次请求都直接打到数据库。攻击者只要构造一堆不存在的 key，比如随机负数 ID 查订单，就能把数据库打挂。
常规解法有三个，面试建议按顺序答。第一，接口层做参数校验，非法参数直接拦截。第二，缓存空值——查不到数据库就缓存一个 null，设置短过期时间比如 60 秒，后续同类请求会被缓存挡掉。第三，布隆过滤器——启动时把所有合法 key 预加载到布隆过滤器，请求先判断 key 是否存在，不存在直接返回。布隆过滤器有误判率，但只会把"不存在"误判成"存在"，不会反向误判，所以用在穿透拦截场景很合适。
布隆过滤器的原理是大型位数组加多个哈希函数。插入时把 key 通过 k 个哈希函数映射到位数组的 k 个位置全部置 1；查询时看 k 个位置是否都为 1，只要有 1 个不是，一定不存在。代价是删除困难——不能直接清位，否则会影响其他 key 的判断。所以基于 Redis String 位图实现的布隆过滤器要配合定期重建，才能解决误报率随时间升高的问题。
3.2 击穿：热点 key 过期的瞬间并发风暴
击穿是"某个热点 key 在过期瞬间，大量并发请求同时涌向数据库"——比如秒杀商品详情、热点话题的缓存失效。数据库一瞬间扛几万 QPS，直接崩掉。
解法一：互斥锁。用 SETNX 让第一个请求去重建缓存，其他请求在锁外等待，缓存重建完成后统一返回。伪代码大概是：
String value = redis.get(key); if (value == null) { // setIfAbsent(key_lock, token, 过期时间) if (redis.setIfAbsent(key_lock, "1", 10, TimeUnit.SECONDS)) { // 只有拿到锁的请求查数据库并回填 value = db.query(key); redis.set(key, value, expireTime); redis.delete(key_lock); } else { // 没拿到锁，短暂 sleep 后重试读缓存 Thread.sleep(50); value = redis.get(key); } }这里要特别注意锁的过期时间不能太短，否则缓存还没重建完锁就失效了，多个线程又会同时进库。稳妥的做法是用 Redisson 的看门狗自动续期，锁超时默认 30 秒，每 10 秒检查一次是否还持有，持有就续期。
解法二：逻辑过期。缓存里不设实际 TTL，而是存入一个"过期时间戳"，查询时对比：发现逻辑过期后返回旧值给调用方，同时只让一个线程异步去更新缓存。好处是"永远不出现空窗期"，用户拿到的还是旧数据，新数据在后台刷新。缺点是数据一致性有一段时间的延迟，适合能容忍短暂旧数据的场景，比如商品详情页、排行榜。
3.3 雪崩：大面积 key 同时失效
雪崩是击穿的扩大版：大量 key 在同一时间段过期，或者整个 Redis 实例宕机，请求全部打到数据库。典型场景是缓存设置了统一的过期时间，比如所有分类数据都设定在整点过期。
解法从两个层面入手。缓存层面：过期时间加随机值，比如基础 1 小时再随机加 0 到 10 分钟，打散失效时间；热点数据改为逻辑过期，后台统一刷新。架构层面：Redis 做高可用部署，主从加哨兵，避免单点宕机；应用层加本地缓存做兜底，数据库侧做限流降级。我管这套组合叫"分层缓冲"：本地 Caffeine 一层，Redis 一层，数据库再加读写分离和连接池保护。即使 Redis 挂了，本地缓存还能扛住一部分热点请求，给恢复争取时间。
3.4 这个环节的加分回答
面试官问完三个"兄弟"之后通常追加一句："你们项目里实际遇到的是哪种，怎么解决的？"这时候只背概念就会露馅。合理的回答要结合具体业务：比如某活动页的 SKU 详情缓存失效导致数据库打满，最终用互斥锁加提前预热解决。记得把"为什么选这个方案"讲清楚——预热解决的是预期内的高峰，锁解决的是预期外的突发并发。有了这个"业务场景加方案取舍"的结构，回答质量立刻不一样。
4. 高可用与集群：主从、哨兵、Cluster 一次理清
4.1 主从复制：同步链路是怎么建立的
主从复制的目的是读写分离和数据冗余。从节点启动后向主节点发起同步，链路分两步。第一步全量同步：主节点 fork 子进程生成 RDB 快照发给从节点，同时把同步期间的新写命令缓冲到复制积压缓冲区 repl_backlog。第二步增量同步：从节点加载完 RDB 后，主节点把 backlog 里后续的命令继续发过去，之后一直靠这种命令传播保持同步。
这里有两个高频考点。一是为什么需要 backlog，大小怎么设置？repl_backlog 是环形缓冲区，默认 1MB。从节点断连太久，需要追的偏移量已经被覆盖，就只能重新全量同步。生产上建议把 repl-backlog-size 调到 64MB 甚至 128MB，减少全量同步的概率。二是 replication id 和 offset。Redis 6.0 之后用这两个值标识复制位置，从节点提升为主节点时会生成新的 replid，老 replid 保留一段时间，让其他从节点还能找到同步起点。
4.2 哨兵：自动故障转移是怎么选主的
哨兵解决"主节点挂了没法自动切换"的问题。哨兵集群通常部署奇数个节点，三五个起步，它们之间通过 gossip 协议互相通信，共同监控主从节点的状态。
主节点被判为客观下线需要两个阶段。主观下线：单个哨兵发现主节点超过 down-after-milliseconds 毫秒没响应。客观下线：多个哨兵达到 quorum 数量都认为主节点不可用。之后哨兵集群发起 leader 选举，选出一个哨兵执行故障转移，再挑选一个从节点提升为新主。
选主规则是问得非常多的一题：过滤掉断连和没有复制的从节点，然后按优先级 replica-priority（配置值越小越优先）、复制偏移量越大越优先、运行 ID 越小越优先的次序选。为什么要按这个顺序？因为要选数据最完整、和主节点差异最小的节点，才能把数据丢失降到最低。把这句话说出来，面试官就知道你真的理解故障转移的本质。
4.3 Redis Cluster：16384 个槽位背后的设计
Cluster 模式的核心是分片。数据被哈希到 16384 个槽位上，每个节点负责一段槽区间。客户端根据 key 的 CRC16 校验值对 16384 取模，找到槽位归属的节点直接访问。请求的 key 不在当前节点时，节点返回 MOVED 错误并告诉客户端正确地址；槽位正在迁移时，返回 ASK 让客户端到目标节点重试。
几个经典追问值得准备。为什么是 16384 而不是更多？官方当时的考虑是：全量槽位信息每个节点都要广播，槽位越多网络包越大；16384 对常见的几百上千节点规模已经足够，CRC16 的分布也很均匀。
为什么 Cluster 不支持跨节点的多 key 操作？不同 key 可能哈希到不同槽位，而 Redis 单线程模型下的原子性只保证在单个实例内，跨节点事务无法实现。解决方案是用 hash tag：把 key 写成 {user123}.orders 这种形式，CRC16 只对花括号里的内容计算，强制相关 key 落到同一个槽。我做过订单扩展，就是靠 hash tag 实现的批量读。
集群模式下的客户端怎么知道槽位分布？以 Java 为例，Lettuce 和 Jedis 的集群客户端启动时会自动获取槽位映射表并本地缓存，槽位变更时通过重定向响应触发刷新。所以客户端配置集群地址时只需要配一个节点，它会自动发现整个集群。
Cluster 适合数据量大、分片需求明确的场景。但要注意：Cluster 模式只支持 db0，不支持多 key 的 Lua 脚本（除非 key 在同一个槽），批量操作也受限。选型必须拿业务实际的操作模式来评估，不能为了上集群而上集群。
5. 内存管理：过期删除与淘汰策略怎么配合
5.1 过期 key 是惰性删还是定期删
Redis 的 key 过期删除采用"惰性删除加定期删除"组合策略。
惰性删除：每次访问 key 时检查是否过期，过期就删除并返回空。省 CPU，但有致命问题——过期 key 一直不被访问就一直占内存，所以必须靠定期删除兜底。
定期删除：Redis 每隔一段时间，由 hz 配置控制频率，默认每秒执行约十次，随机抽取一批设置了过期时间的 key，删掉其中已过期的。如果抽样里过期比例超过四分之一，就继续循环处理。这样把删除动作摊薄到各个时间片，避免一次性大扫除阻塞主线程。
面试追问点：为什么不用定时器精准到期删除每个 key？因为 Redis 是单线程，精准到期触发会打断当前命令的执行，大量定时器也会消耗主线程资源。随机抽样加惰性，本质是在内存占用和 CPU 开销之间做折中。这个回答能体现你对"单线程调度代价"的理解，很加分。
5.2 八种内存淘汰策略怎么选
当内存达到 maxmemory 限制后，Redis 会根据淘汰策略清理 key。常见的有：
- noeviction：不淘汰，写命令直接报错，这是默认值
- allkeys-lru / volatile-lru：按 LRU 近似算法淘汰
- allkeys-lfu / volatile-lfu：按 LFU 近似算法淘汰
- allkeys-random / volatile-random：随机淘汰
- volatile-ttl：优先淘汰剩余存活时间最短的 key
值得注意：volatile 系列只对设置过过期时间的 key 生效。如果所有 key 都没设 TTL，volatile-lru 等于 noeviction，照样报错。所以生产环境里缓存的 key 一定要统一设置过期时间，否则淘汰策略形同虚设。
LRU 和 LFU 的区别是高频题。LRU 按最近访问时间淘汰，LFU 按访问频次淘汰。LRU 容易被一次性的大量访问污染——某个 key 被促销流量扫一下排到队头，之后再也不用了，却把真正高频的热点挤掉。LFU 通过频次衰减避免这种污染，实现更复杂。Redis 的 LRU 也不是严格 LRU，而是近似采样：默认采样 5 个 key 淘汰其中最久没用的，目的是省内存、避免维护全量访问链表。
5.3 内存分析与 key 设计
生产环境最实用的命令是 redis-cli --bigkeys 和 MEMORY USAGE。--bigkeys 扫描所有 key，统计最大的 string、list、hash 等类型，是排查大 key 的第一利器。MEMORY USAGE 命令可以查看某个 key 实际占用内存字节数，用来验证序列化方式对内存的影响。
key 设计这块面试官也爱听。规范的业务 key 要带前缀，比如 user:info:123、order:detail:456789，冒号分段，业务模块放开头。好处是便于按前缀用 SCAN 排查，也便于 Cluster 场景下用 hash tag 控制分布。value 序列化尽量紧凑：能存数字不存字符串，能压缩尽量压缩。Spring Data Redis 默认的 JDK 序列化会把 class 信息也写进字节流，非常浪费内存，换成 GenericJackson2JsonRedisSerializer 往往能省一半以上体积。
6. Java 落地踩坑记录与面试避坑清单
6.1 大 key、热 key：这两个坑我真实踩过
先说大 key。我负责过一个报表模块，往 Redis 里塞了一个 List，业务方每天推一次全量数据，结果这个 List 存了几百万个元素，占了将近 200MB。后果是什么？删除这个 key 的时候 Redis 主线程要遍历整个 List 释放内存，整个实例卡了近两秒，期间其他业务的读写全部排队超时。排查过程：先看慢查询日志发现 DEL 操作耗时惊人，再做 --bigkeys 扫描定位到大 key，最后改成按批删除（LRANGE 取一部分再 LTRIM），或者干脆换存储方案。
热 key 是相反的场景。某个直播间的在线人数 key，活动期间每秒几万次访问都打到同一个实例，虽然 Redis 单线程扛得住，但网络带宽和延迟会出现抖动。处理思路：应用层加一份短生命周期本地缓存，比如存 1 秒；或者用多副本 key，如 key:0 到 key:9，把读流量分散到多个 key 上，写的时候同步更新所有副本。
这两个问题都属于"平时不出现，一出现就是事故"的类型，建议监控体系里加上 big key 扫描和热点 key 检测，定期跑一遍。
6.2 Java 客户端与连接池调优
Java 里最常用的两个客户端是 Jedis 和 Lettuce。Spring Boot 2.x 默认用 Lettuce，底层是 Netty，连接异步共享，但有个经典坑：共享连接模式下，如果某个操作卡住或触发慢查询，同一个连接上的其他命令全部排队受牵连。在并发量高、命令耗时波动大的场景，反而建议切回 Jedis 连接池模式，每个线程从池里拿独立连接，故障隔离开来。我处理过的一个生产事故，就是 Lettuce 默认共享连接被一个超慢的大 key 操作阻塞，后续所有命令排队，最后靠拆分大 key 加部分场景切换 Jedis 才彻底解决。
连接池参数设置经验：maxTotal 不是越大越好，建议从业务峰值 QPS 的十分之一起步，结合单连接吞吐实测调整；maxIdle 保持略小于 maxTotal，避免频繁创建销毁连接；minIdle 保证低位流量时连接就绪。更重要的是设置合理超时：连接超时给两三秒，读超时按最慢命令的 P99 留余量，比如一到两秒，避免无限等待拖垮应用线程池。
6.3 分布式锁与 Lua 脚本
分布式锁的八股版本是"SET key value NX EX 10"，释放时用 Lua 脚本保证比较和删除的原子性：
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end这个脚本解决的核心问题："比较 value 是否是自己设置的 token"和"删除 key"必须是原子操作，否则会出现 A 线程删掉 B 线程锁的经典错乱。面试追问会到"锁过期了怎么办"——答案是看门狗续期。Redisson 的实现是启动后台定时任务，默认每 10 秒检查一次锁是否还持有，持有就续期到 30 秒。再往下追问就是 RedLock 争议：多个独立 Redis 实例加锁保证容错，但业界对 RedLock 的批评不少，生产环境很少落地。我会明确告诉面试官：单机加哨兵场景下 Redisson 普通锁完全够用，RedLock 作为扩展了解即可。
Lua 脚本的另一个典型用法是限流。滑动窗口限流用 ZSet：每次请求添加一个成员，删除窗口之前的成员，统计窗口内数量。这套逻辑拆成多个命令执行有竞态风险，放进 Lua 脚本就原子了。这也是面试"Redis 限流怎么做"的标准答法之一：先讲 ZSet 加 Lua 的思路，再补一段计数器实现，足够展示掌握程度。
6.4 高频追问速查表
到这里，我把面试中最容易被追问的 Redis 场景整理成一张速查表，出门前再扫一眼很有用：
| 追问点 | 一句话结论 |
|---|---|
| Redis 为什么快 | 纯内存加单线程避免锁竞争，IO 多路复用，数据结构编码紧凑 |
| 单线程为什么还能高并发 | 瓶颈在网络 IO 不在 CPU，IO 多路复用让单线程处理大量连接 |
| Redis 和 Memcached 的区别 | 数据类型更丰富，支持持久化、集群、多种淘汰策略 |
| 缓存一致性怎么保证 | 没有银弹：先更新数据库再删缓存，配合延迟双删或消息队列兜底 |
| 分布式锁可靠吗 | 单主 Redis 在主从切换极端情况下可能丢锁，要求极高时换专业协调组件 |
| SCAN 和 KEYS 的区别 | KEYS 全量阻塞，SCAN 游标式增量遍历，生产环境用 SCAN |
| 为什么 Redis 6.0 引入多线程 | 只在网络 IO 处理上多线程，命令执行仍是单线程，提升大流量下 IO 吞吐 |
这张表里的每一行都能展开几百字，建议挑自己薄弱的几行，回到前几节的对应部分补一遍。背答案只是底线，能讲清"为什么"才是真正的分水岭。
最后分享一个我自己的学习方法：准备 Redis 面试时，别按知识点清单背，按"一条写请求从客户端到 Redis 再到持久化、复制、集群的全链路"来组织知识。一个 key 写入之后，它走哪条数据结构路径、怎么编码、过期后被哪套机制清理、如何持久化、主从之间怎么同步、集群里怎么定位——这条链路走通了，你会发现所谓八股其实都能串起来。真正面试时，回答的深度就体现在你能把一个点讲成一条线，而不是蹦出一个孤立名词。
另外提醒一句：所有涉及 Redis 的代码和配置上线前，都过一遍慢查询日志和 big key 扫描。这两个动作成本极低，但关键时刻真的能救命。
