这个系列笔记其实攒了一段时间了。起因是上个月集中准备面试把 Redis 和 Caffeine 两套缓存相关的八股反复过了一遍顺手把当时整理的“427 缓存面经”翻出来做了二次梳理。之所以用“427”当代号是因为那天一天内面了四场二轮回来后把所有被问到的问题和答得不够顺的点全部记了下来算是一份很有现场感的面经沉淀。Redis 和 Caffeine 放在一起聊是因为它们几乎覆盖了后端缓存面试的两种典型问法一种是考察分布式缓存原理从数据结构问到持久化再问到缓存穿透另一种是考察单机缓存设计从淘汰算法问到异步加载再问到与业务代码的集成方式。两类问题表面上是两个技术方向内核却是同一个——你对“缓存数据什么时候失效、什么时候淘汰、什么时候更新”这三件事有没有清晰且可落地的判断。这篇文章不打算写成那种标题党面经合集而是尽量还原我当时从问题推导答案的思路。每个问题都补上了“面试官到底在问什么”以及“为什么这样答才稳”的拆解适合正在准备后端岗位面试的读者也适合平时在用 Redis 和 Caffeine 但没系统整理过原理的同行参考。1. 为什么 Redis 和 Caffeine 总被一起问1.1 面试官想看的其实不是背题能力很多人准备缓存八股时喜欢背“Redis 为什么快”“Caffeine 淘汰策略是什么”这类问题但面过几轮之后你会发现面试官真正在意的并不是你背得全不全而是你能不能把两个缓存组件放在同一个业务场景里说清楚。比如“Redis 挂了怎么办”“本地缓存和 Redis 数据不一致怎么处理”“热点数据打爆 Redis 怎么办”——这些问题任何一个都同时涉及 Redis 和 Caffeine单背任何一家的八股都扛不住。我遇到过最典型的一道题某支付服务的配置信息被高频读取QPS 大约两万左右缓存目前放在 Redis但每次读取都有网络开销问怎么优化。这道题的正确思路就是本地缓存 分布式缓存的二级结构Caffeine 承担进程内热点数据的快速读取Redis 承担集群内共享兜底。面试官听到你说“先用 Caffeine 挡第一层再用 Redis 兜底同时监听配置变更事件主动刷新本地缓存”之后通常会继续追问一致性问题这时候八股有没有背透一下子就暴露了。1.2 两条技术线的逻辑关系Redis 和 Caffeine 在面试题里的角色非常明确两条线不能搞混Redis 关注的是多实例共享、运维复杂、数据持久化、主从复制和集群分片Caffeine 关注的是单进程内的性能上限、内存可控、淘汰算法准确度和生命周期管理。很多人在复习时把两者割裂开结果就是答 Redis 持久化时头头是道问到 Caffeine 和 Guava Cache 的区别时却说不出所以然。实际上面试官把这两者放在同一轮面试里就是在看你对“缓存的分层架构”有没有全局感。Redis 是分布式层面的共享缓存Caffeine 是应用进程内的本地缓存两者组合时需要考虑数据一致性、更新策略和故障降级这些正是工程上最有价值的部分。2. Redis 经典八股底层推导2.1 数据结构不只考“有哪些”Redis 八股的第一关通常是数据结构。String、Hash、List、Set、ZSet 五种基础类型谁都能列出来但面试官问的往往是底层实现和编码转换的逻辑。比如 String 的底层是 SDS不是 C 字符串ZSet 的底层是跳表 哈希表的组合Hash 在小数据量时用 ziplist超过阈值后转成 hashtable。这些点光记住结论不够要理解为什么这么设计。我复习时把 ZSet 底层跳表的部分重新推导了一遍跳表本质上是用多级索引加速有序链表的查找平均时间复杂度 O(log n)实现起来比平衡树简单而且区间查询比平衡树更有优势。面试官如果追问“为什么用跳表而不用红黑树”你就可以答“红黑树是内存连续结构中常见的平衡方案但跳表在实现并发安全时更容易加锁分段”这就体现出了读源码的深度。2.2 持久化方案不能只背 RDB 和 AOFRedis 持久化是八股里几乎必考的内容但很多人只背了“RDB 是快照、AOF 是追加日志”一问到细节就卡壳。RDB 的启动参数 save 触发条件怎么设、子进程做 fork 时怎么处理内存页表、AOF 的三种刷盘策略对性能和可靠性的影响分别是什么这些才是真正拉开差距的地方。我当时给自己梳理了一条决策链如果业务能容忍最多几十秒的数据丢失RDB 完全够用如果每条写命令都不能丢就必须 AOF 并开启 everysec 的刷盘策略如果又想减少重启恢复时间又想尽量少丢数据就用 RDB AOF 混用Redis 4.0 之后支持了这种混合持久化方案。面到这个层面时答得越具体越能证明你真的用过而不是只看过概念。2.3 缓存穿透、击穿、雪崩的底层逻辑三个经典问题背后其实只有一个核心矛盾缓存是为了保护数据库但在缓存失效的瞬间如何防止大量请求直接打到数据库上。穿透是“查了不存在的数据导致每次都要查库”击穿是“热点 key 过期瞬间高并发同时打到 DB”雪崩是“大批 key 同时过期导致整体流量压垮 DB”。这三个问题的解法不是各写各的而是可以合并思考。穿透的解法包括布隆过滤器过滤掉不可能存在的 key以及缓存空值给一个短暂的过期时间击穿解法包括用分布式锁挡住重建流程以及热点 key 设置为永不过期然后在后台异步更新雪崩解法包括过期时间加随机偏移、多级缓存兜底、限流和熔断配合。面试时把这几个解法串成一条处理链来讲比单独背答案效果好得多。2.4 分布式锁的细节远比想象中多分布式锁是 Redis 八股里最容易翻车的话题因为网上资料写得极乱。最常见的实现是 SET nx px用一条命令保证“加锁 过期时间”的原子性。但面试官一定会追问锁过期了怎么办持锁线程还没执行完怎么办这就需要引入看门狗机制——在持锁期间每隔一段时间自动续期或者干脆用 Redisson 的锁封装它默认做了续期逻辑。还有一类进阶问题主从切换场景下锁是否可靠。Redis 的主从复制是异步的如果主节点加锁成功但还没同步到从节点主节点故障后从节点升主就会丢失锁信息。这里可以答 RedLock 思路但要注意 RedLock 本身存在争议更好的答法是说明业务对锁的强一致性要求是否真的需要用 RedLock还是普通的 SETNX 加看门狗就能满足。这样答既展示宽度又展示你的工程判断。3. Caffeine 面经的高频问题拆解3.1 为什么新项目不选 Guava CacheCaffeine 面经第一个高频问题就是“Guava Cache 和 Caffeine 有什么区别”。核心答案有两点一是淘汰算法不同Guava Cache 用的近似 LRUCaffeine 用 TinyLFU 的变种二是 Caffeine 统计命中率更准确、并发性能更好。但真正面到深处时面试官想听的是你对淘汰算法的理解而不只是一个结论。Caffeine 的 W-TinyLFU 可以展开成一个三层结构窗口区、试用区和保护区。新数据先进窗口区窗口区满后被驱逐的进入试用区试用区里的数据如果被再次访问提升到保护区保护区的数据长期未被访问会被淘汰。这个设计兼顾了 LRU 对突发流量的友好和 LFU 对长期高频数据的记忆功能比单纯 LRU 更准。能把这个过程讲清楚就能证明你不是只会用 CacheLoader。3.2 过期策略和驱逐策略的边界Caffeine 里有很多容易混淆的概念比如 expireAfterWrite、expireAfterAccess、expireAfter 三者之间的区别以及 maximumSize 和 maximumWeight 的关系。我复习时的经验是画一张小表帮自己理清触发条件expireAfterWrite写入后固定时长过期适合配置类数据expireAfterAccess读写后重置计时适合超时会话类数据maximumSize按 key 数量淘汰适合 key 数量可控的场景maximumWeight按权重淘汰适合缓存对象大小差异明显的场景。面到“缓存什么时候失效”这类问题时能准确说出这些参数含义和适用场景比背一堆定义更有说服力。还可以补充一点Caffeine 的驱逐是异步懒删除的理论上不会在每次访问时都去全量扫描判断过期这一层细节能体现你对性能的理解。3.3 异步加载和缓存null值Caffeine 的 buildAsync 系列接口是一个高频加分点。缓存异步加载通常用于即时响应 后台刷新的场景比如某个热点数据的读取链路耗时较长又不想让调用方每次阻塞等待就可以用 buildAsync 创建异步缓存配合 CompletableFuture 来做。这里要注意的是异步场景下如果缓存过期了多个线程同时请求同一个 key 时如何避免重复加载。Caffeine 提供了自动去重的机制内部会处理合并请求这一点在面试中也值得展开。另外 null 值处理也是个常被忽略的点Caffeine 默认不允许缓存 null如果你有“缓存空值防止穿透”的需求需要自己包装一层 Optional 或者其他标记对象。这个细节虽然小但在真实业务中经常遇到面试时主动提出来会显得你踩过坑。4. Redis Caffeine 多级缓存设计4.1 读路径与写路径的完整设计多级缓存的架构设计是面试里最容易出场景题的环节。读路径通常是先从 Caffeine 查未命中再查 RedisRedis 也没有就去查 DB然后反向填充两级缓存。这套流程好说但难在细节。比如 Caffeine 和 Redis 同时未命中后在填充 Redis 时要不要加分布式锁防止击穿如果只做了单机锁多实例并发情况下会出现什么效果我在整理“427 面经”时给自己定了一个标准答法读路径加“单机状态 分布式锁”双重保护本地用 ConcurrentHashMap 的 computeIfAbsent 或者 Caffeine 自带的同步加载能力做单进程内合并跨进程用 SETNX 锁做互斥双保险能挡住绝大多数并发重建场景。写路径则先更新 DB再删除 Redis 缓存最后通过事件机制通知各实例淘汰本地缓存的对应 key。4.2 一致性问题不能只谈延迟双删缓存和数据库一致性是必考场景题。网上的方案很多但面试官想听到的是“有取舍意识的方案”而不是背一个全能的招。Cache Aside 是最常用的模式先更新 DB 再删除缓存问题在删除缓存失败时会导致旧数据长时间存在。延迟双删的思路第一次删完等一会在删一次但等待时间是拍脑袋定的在多副本同步延迟不确定的场景下并不靠谱。更稳的方式是在缓存 value 中携带数据版本号或更新时间戳读取时发现版本落后就主动去 DB 拉新数据并回填缓存。Caffeine 做本地缓存时也可以用类似思路比如本地缓存的自动刷新机制 refreshAfterWrite能在后台周期性拉取最新值配合 Redis 的 pub/sub 通知批量失效就是一套工程上可落地的一致性方案。4.3 一套可参考的参数配置整理了这么多理论最后还是得落到能抄作业的参数上。我在某内部项目的实际配置是Caffeine 初始容量 100、最大容量 5000、写入后 5 分钟过期、写入后 1 分钟刷新这个配置适合配置表类数据和用户会话数据混合的场景。Redis 侧则设置 10 分钟过期时间并额外加一个随机浮动避免批量过期造成集中穿透。多级缓存最容易踩的坑是本地缓存过大导致内存占用飙升以及刷新频率太高反而拖累 DB。这两个问题相互矛盾必须在压测时用真实 QPS 调参。面试时如果你能说出“maximumSize 设多少、refreshAfterWrite 设多少、Redis 过期时间设多少”这套组合并解释为什么这么定就比空谈架构要好得多。5. 缓存场景题实战与踩坑记录5.1 场景题电商库存热点 key 如何处理场景题几乎是“427”那几轮面试里必出现的一类问题。当时最典型的一道某电商活动页的库存数据会被超高并发读取单 key QPS 打到 Redis 上限怎么处理我的回答是优先本地缓存扛流量峰值Caffeine 缓存热点库存值 1 秒后自动过期允许极端情况下读到旧库存同时用消息队列异步推送库存变更让各实例主动更新本地缓存。面试官追问“本地缓存过期期间的高并发怎么防击穿”我答了三点一是 Caffeine 自身的并发合并加载机制会合并掉大部分重复请求二是对 DB 查询做限流只放行一个重建请求三是如果对一致性要求没那么高可以短期直接返回旧值。这种“先给结论、再给补强方案、最后讲妥协边界”的答法是我复盘时总结出来最有效的答题节奏。5.2 一个本地缓存引发的线上事故这里插一个实际案例是我在某团队遇到的。某天一个非核心服务突然报警内存占用从 30% 飙到 85%排查下来是有人把用户维度的个性化数据放进了本地缓存还是永不过期的配置。局部缓存只该放“全实例一致的非核心数据”一旦放入少量私有数据内存膨胀和脏数据问题会同时爆发。那次之后我们定了两条规矩第一Caffeine 缓存的数据必须是可以接受分钟级延迟变更的数据第二每天凌晨统一清理一次本地缓存防止极端情况下的脏数据驻留。这两条看着普通但能避免很多低级事故面试时主动分享这种踩坑案例比任何华丽架构都更有说服力。5.3 高频问题速查表面的过程中会反复遇到一些高度相似的追问这里直接整理一张速查表方便大家考前快速过一遍该怎么回答 | 加分点 | 常见雷区 Redis 快的原因 | 基于内存 IO 多路复用 高效数据结构 | 只答“因为是内存数据库” 缓存击穿 | 热点 key 永不过期 互斥重建 | 不提锁的超时续期风险 Caffeine 和 Guava 差异 | W-TinyLFU 设计原理 | 只说“Caffeine 更快”不展开原因 多级缓存写入 | 更新 DB 后删 Redis 再通知清本地 | 不聊失败补偿机制 分布式锁可靠性 | 看门狗续期 主从切换风险 | 认为 RedLock 完美无缺点这张表只是框架核心思路是一个问题至少要准备到“这句话为什么对”的程度。结尾一些复盘后的感受整理这些内容时最大的感受是面试中能聊深的问题往往不是靠死记硬背的八股而是靠平时真正踩过的坑和想通过的方案。像 Redis 持久化选型、Caffeine 参数调优、分级缓存一致性这些内容如果你只是看面经你记住的是答案如果你自己动手搭过一版、压过一轮测试你记住的是决策路径。面试官追问的偏偏就是决策路径。建议准备缓存方向时不再按“Redis 题 / Caffeine 题”单独刷而是一上来就按“读场景 / 写场景 / 故障场景”分类整理把两个组件放到一条完整的数据链路里去理解。我自己这样做完之后在后续面试里很多问题还没等面试官展开就已经能猜到他想问的下一个分支是什么了。 Redis与Caffeine缓存面试核心原理与多级缓存设计解析
这个系列笔记其实攒了一段时间了。起因是上个月集中准备面试把 Redis 和 Caffeine 两套缓存相关的八股反复过了一遍顺手把当时整理的“427 缓存面经”翻出来做了二次梳理。之所以用“427”当代号是因为那天一天内面了四场二轮回来后把所有被问到的问题和答得不够顺的点全部记了下来算是一份很有现场感的面经沉淀。Redis 和 Caffeine 放在一起聊是因为它们几乎覆盖了后端缓存面试的两种典型问法一种是考察分布式缓存原理从数据结构问到持久化再问到缓存穿透另一种是考察单机缓存设计从淘汰算法问到异步加载再问到与业务代码的集成方式。两类问题表面上是两个技术方向内核却是同一个——你对“缓存数据什么时候失效、什么时候淘汰、什么时候更新”这三件事有没有清晰且可落地的判断。这篇文章不打算写成那种标题党面经合集而是尽量还原我当时从问题推导答案的思路。每个问题都补上了“面试官到底在问什么”以及“为什么这样答才稳”的拆解适合正在准备后端岗位面试的读者也适合平时在用 Redis 和 Caffeine 但没系统整理过原理的同行参考。1. 为什么 Redis 和 Caffeine 总被一起问1.1 面试官想看的其实不是背题能力很多人准备缓存八股时喜欢背“Redis 为什么快”“Caffeine 淘汰策略是什么”这类问题但面过几轮之后你会发现面试官真正在意的并不是你背得全不全而是你能不能把两个缓存组件放在同一个业务场景里说清楚。比如“Redis 挂了怎么办”“本地缓存和 Redis 数据不一致怎么处理”“热点数据打爆 Redis 怎么办”——这些问题任何一个都同时涉及 Redis 和 Caffeine单背任何一家的八股都扛不住。我遇到过最典型的一道题某支付服务的配置信息被高频读取QPS 大约两万左右缓存目前放在 Redis但每次读取都有网络开销问怎么优化。这道题的正确思路就是本地缓存 分布式缓存的二级结构Caffeine 承担进程内热点数据的快速读取Redis 承担集群内共享兜底。面试官听到你说“先用 Caffeine 挡第一层再用 Redis 兜底同时监听配置变更事件主动刷新本地缓存”之后通常会继续追问一致性问题这时候八股有没有背透一下子就暴露了。1.2 两条技术线的逻辑关系Redis 和 Caffeine 在面试题里的角色非常明确两条线不能搞混Redis 关注的是多实例共享、运维复杂、数据持久化、主从复制和集群分片Caffeine 关注的是单进程内的性能上限、内存可控、淘汰算法准确度和生命周期管理。很多人在复习时把两者割裂开结果就是答 Redis 持久化时头头是道问到 Caffeine 和 Guava Cache 的区别时却说不出所以然。实际上面试官把这两者放在同一轮面试里就是在看你对“缓存的分层架构”有没有全局感。Redis 是分布式层面的共享缓存Caffeine 是应用进程内的本地缓存两者组合时需要考虑数据一致性、更新策略和故障降级这些正是工程上最有价值的部分。2. Redis 经典八股底层推导2.1 数据结构不只考“有哪些”Redis 八股的第一关通常是数据结构。String、Hash、List、Set、ZSet 五种基础类型谁都能列出来但面试官问的往往是底层实现和编码转换的逻辑。比如 String 的底层是 SDS不是 C 字符串ZSet 的底层是跳表 哈希表的组合Hash 在小数据量时用 ziplist超过阈值后转成 hashtable。这些点光记住结论不够要理解为什么这么设计。我复习时把 ZSet 底层跳表的部分重新推导了一遍跳表本质上是用多级索引加速有序链表的查找平均时间复杂度 O(log n)实现起来比平衡树简单而且区间查询比平衡树更有优势。面试官如果追问“为什么用跳表而不用红黑树”你就可以答“红黑树是内存连续结构中常见的平衡方案但跳表在实现并发安全时更容易加锁分段”这就体现出了读源码的深度。2.2 持久化方案不能只背 RDB 和 AOFRedis 持久化是八股里几乎必考的内容但很多人只背了“RDB 是快照、AOF 是追加日志”一问到细节就卡壳。RDB 的启动参数 save 触发条件怎么设、子进程做 fork 时怎么处理内存页表、AOF 的三种刷盘策略对性能和可靠性的影响分别是什么这些才是真正拉开差距的地方。我当时给自己梳理了一条决策链如果业务能容忍最多几十秒的数据丢失RDB 完全够用如果每条写命令都不能丢就必须 AOF 并开启 everysec 的刷盘策略如果又想减少重启恢复时间又想尽量少丢数据就用 RDB AOF 混用Redis 4.0 之后支持了这种混合持久化方案。面到这个层面时答得越具体越能证明你真的用过而不是只看过概念。2.3 缓存穿透、击穿、雪崩的底层逻辑三个经典问题背后其实只有一个核心矛盾缓存是为了保护数据库但在缓存失效的瞬间如何防止大量请求直接打到数据库上。穿透是“查了不存在的数据导致每次都要查库”击穿是“热点 key 过期瞬间高并发同时打到 DB”雪崩是“大批 key 同时过期导致整体流量压垮 DB”。这三个问题的解法不是各写各的而是可以合并思考。穿透的解法包括布隆过滤器过滤掉不可能存在的 key以及缓存空值给一个短暂的过期时间击穿解法包括用分布式锁挡住重建流程以及热点 key 设置为永不过期然后在后台异步更新雪崩解法包括过期时间加随机偏移、多级缓存兜底、限流和熔断配合。面试时把这几个解法串成一条处理链来讲比单独背答案效果好得多。2.4 分布式锁的细节远比想象中多分布式锁是 Redis 八股里最容易翻车的话题因为网上资料写得极乱。最常见的实现是 SET nx px用一条命令保证“加锁 过期时间”的原子性。但面试官一定会追问锁过期了怎么办持锁线程还没执行完怎么办这就需要引入看门狗机制——在持锁期间每隔一段时间自动续期或者干脆用 Redisson 的锁封装它默认做了续期逻辑。还有一类进阶问题主从切换场景下锁是否可靠。Redis 的主从复制是异步的如果主节点加锁成功但还没同步到从节点主节点故障后从节点升主就会丢失锁信息。这里可以答 RedLock 思路但要注意 RedLock 本身存在争议更好的答法是说明业务对锁的强一致性要求是否真的需要用 RedLock还是普通的 SETNX 加看门狗就能满足。这样答既展示宽度又展示你的工程判断。3. Caffeine 面经的高频问题拆解3.1 为什么新项目不选 Guava CacheCaffeine 面经第一个高频问题就是“Guava Cache 和 Caffeine 有什么区别”。核心答案有两点一是淘汰算法不同Guava Cache 用的近似 LRUCaffeine 用 TinyLFU 的变种二是 Caffeine 统计命中率更准确、并发性能更好。但真正面到深处时面试官想听的是你对淘汰算法的理解而不只是一个结论。Caffeine 的 W-TinyLFU 可以展开成一个三层结构窗口区、试用区和保护区。新数据先进窗口区窗口区满后被驱逐的进入试用区试用区里的数据如果被再次访问提升到保护区保护区的数据长期未被访问会被淘汰。这个设计兼顾了 LRU 对突发流量的友好和 LFU 对长期高频数据的记忆功能比单纯 LRU 更准。能把这个过程讲清楚就能证明你不是只会用 CacheLoader。3.2 过期策略和驱逐策略的边界Caffeine 里有很多容易混淆的概念比如 expireAfterWrite、expireAfterAccess、expireAfter 三者之间的区别以及 maximumSize 和 maximumWeight 的关系。我复习时的经验是画一张小表帮自己理清触发条件expireAfterWrite写入后固定时长过期适合配置类数据expireAfterAccess读写后重置计时适合超时会话类数据maximumSize按 key 数量淘汰适合 key 数量可控的场景maximumWeight按权重淘汰适合缓存对象大小差异明显的场景。面到“缓存什么时候失效”这类问题时能准确说出这些参数含义和适用场景比背一堆定义更有说服力。还可以补充一点Caffeine 的驱逐是异步懒删除的理论上不会在每次访问时都去全量扫描判断过期这一层细节能体现你对性能的理解。3.3 异步加载和缓存null值Caffeine 的 buildAsync 系列接口是一个高频加分点。缓存异步加载通常用于即时响应 后台刷新的场景比如某个热点数据的读取链路耗时较长又不想让调用方每次阻塞等待就可以用 buildAsync 创建异步缓存配合 CompletableFuture 来做。这里要注意的是异步场景下如果缓存过期了多个线程同时请求同一个 key 时如何避免重复加载。Caffeine 提供了自动去重的机制内部会处理合并请求这一点在面试中也值得展开。另外 null 值处理也是个常被忽略的点Caffeine 默认不允许缓存 null如果你有“缓存空值防止穿透”的需求需要自己包装一层 Optional 或者其他标记对象。这个细节虽然小但在真实业务中经常遇到面试时主动提出来会显得你踩过坑。4. Redis Caffeine 多级缓存设计4.1 读路径与写路径的完整设计多级缓存的架构设计是面试里最容易出场景题的环节。读路径通常是先从 Caffeine 查未命中再查 RedisRedis 也没有就去查 DB然后反向填充两级缓存。这套流程好说但难在细节。比如 Caffeine 和 Redis 同时未命中后在填充 Redis 时要不要加分布式锁防止击穿如果只做了单机锁多实例并发情况下会出现什么效果我在整理“427 面经”时给自己定了一个标准答法读路径加“单机状态 分布式锁”双重保护本地用 ConcurrentHashMap 的 computeIfAbsent 或者 Caffeine 自带的同步加载能力做单进程内合并跨进程用 SETNX 锁做互斥双保险能挡住绝大多数并发重建场景。写路径则先更新 DB再删除 Redis 缓存最后通过事件机制通知各实例淘汰本地缓存的对应 key。4.2 一致性问题不能只谈延迟双删缓存和数据库一致性是必考场景题。网上的方案很多但面试官想听到的是“有取舍意识的方案”而不是背一个全能的招。Cache Aside 是最常用的模式先更新 DB 再删除缓存问题在删除缓存失败时会导致旧数据长时间存在。延迟双删的思路第一次删完等一会在删一次但等待时间是拍脑袋定的在多副本同步延迟不确定的场景下并不靠谱。更稳的方式是在缓存 value 中携带数据版本号或更新时间戳读取时发现版本落后就主动去 DB 拉新数据并回填缓存。Caffeine 做本地缓存时也可以用类似思路比如本地缓存的自动刷新机制 refreshAfterWrite能在后台周期性拉取最新值配合 Redis 的 pub/sub 通知批量失效就是一套工程上可落地的一致性方案。4.3 一套可参考的参数配置整理了这么多理论最后还是得落到能抄作业的参数上。我在某内部项目的实际配置是Caffeine 初始容量 100、最大容量 5000、写入后 5 分钟过期、写入后 1 分钟刷新这个配置适合配置表类数据和用户会话数据混合的场景。Redis 侧则设置 10 分钟过期时间并额外加一个随机浮动避免批量过期造成集中穿透。多级缓存最容易踩的坑是本地缓存过大导致内存占用飙升以及刷新频率太高反而拖累 DB。这两个问题相互矛盾必须在压测时用真实 QPS 调参。面试时如果你能说出“maximumSize 设多少、refreshAfterWrite 设多少、Redis 过期时间设多少”这套组合并解释为什么这么定就比空谈架构要好得多。5. 缓存场景题实战与踩坑记录5.1 场景题电商库存热点 key 如何处理场景题几乎是“427”那几轮面试里必出现的一类问题。当时最典型的一道某电商活动页的库存数据会被超高并发读取单 key QPS 打到 Redis 上限怎么处理我的回答是优先本地缓存扛流量峰值Caffeine 缓存热点库存值 1 秒后自动过期允许极端情况下读到旧库存同时用消息队列异步推送库存变更让各实例主动更新本地缓存。面试官追问“本地缓存过期期间的高并发怎么防击穿”我答了三点一是 Caffeine 自身的并发合并加载机制会合并掉大部分重复请求二是对 DB 查询做限流只放行一个重建请求三是如果对一致性要求没那么高可以短期直接返回旧值。这种“先给结论、再给补强方案、最后讲妥协边界”的答法是我复盘时总结出来最有效的答题节奏。5.2 一个本地缓存引发的线上事故这里插一个实际案例是我在某团队遇到的。某天一个非核心服务突然报警内存占用从 30% 飙到 85%排查下来是有人把用户维度的个性化数据放进了本地缓存还是永不过期的配置。局部缓存只该放“全实例一致的非核心数据”一旦放入少量私有数据内存膨胀和脏数据问题会同时爆发。那次之后我们定了两条规矩第一Caffeine 缓存的数据必须是可以接受分钟级延迟变更的数据第二每天凌晨统一清理一次本地缓存防止极端情况下的脏数据驻留。这两条看着普通但能避免很多低级事故面试时主动分享这种踩坑案例比任何华丽架构都更有说服力。5.3 高频问题速查表面的过程中会反复遇到一些高度相似的追问这里直接整理一张速查表方便大家考前快速过一遍该怎么回答 | 加分点 | 常见雷区 Redis 快的原因 | 基于内存 IO 多路复用 高效数据结构 | 只答“因为是内存数据库” 缓存击穿 | 热点 key 永不过期 互斥重建 | 不提锁的超时续期风险 Caffeine 和 Guava 差异 | W-TinyLFU 设计原理 | 只说“Caffeine 更快”不展开原因 多级缓存写入 | 更新 DB 后删 Redis 再通知清本地 | 不聊失败补偿机制 分布式锁可靠性 | 看门狗续期 主从切换风险 | 认为 RedLock 完美无缺点这张表只是框架核心思路是一个问题至少要准备到“这句话为什么对”的程度。结尾一些复盘后的感受整理这些内容时最大的感受是面试中能聊深的问题往往不是靠死记硬背的八股而是靠平时真正踩过的坑和想通过的方案。像 Redis 持久化选型、Caffeine 参数调优、分级缓存一致性这些内容如果你只是看面经你记住的是答案如果你自己动手搭过一版、压过一轮测试你记住的是决策路径。面试官追问的偏偏就是决策路径。建议准备缓存方向时不再按“Redis 题 / Caffeine 题”单独刷而是一上来就按“读场景 / 写场景 / 故障场景”分类整理把两个组件放到一条完整的数据链路里去理解。我自己这样做完之后在后续面试里很多问题还没等面试官展开就已经能猜到他想问的下一个分支是什么了。