Redis八股+Caffeine面经：本地缓存与分布式缓存分层设计实战

4月27号下午，我在某家公司面完一个Java后端岗，面试官在后半程突然把话题从Redis引到了Caffeine上。当时我愣了一下，因为大部分面经都是把Redis单独拎出来背，很少会把本地缓存和分布式缓存放在同一轮里问。回家之后我把整轮问答重新过了一遍，把这个“Redis八股 + Caffeine面经”的组合整理成了一份笔记，今天分享出来。

这份笔记适合两类人：一类是正在准备面试、想系统梳理缓存知识点的同学；另一类是已经在项目里用了Redis和Caffeine，但没想清楚两者边界、淘汰策略、一致性问题的人。我不是在给你标准答案，而是把那天面试官真正想听到的回答逻辑、以及后来我在项目里验证过的东西一起写出来。

1. 为什么Redis面经里会混着Caffeine一起问

1.1 开场问题：缓存系统是怎么分层设计的

大部分面试官不会一上来就让你背数据结构，而是先抛一个很宽的场景题：一个接口的QPS已经到几千甚至上万，数据库只能扛几百，你会怎么让系统不挂？

这道题的标准回答里一定会有缓存，但只说“用Redis”是不够的。面试官后面那句话往往是：那你觉得Redis这一层缓存够用吗？这时候如果你能主动提到“Redis前面还要加一层Caffeine本地缓存”，整个回答的层次就不一样了。

Caffeine是JVM进程内的缓存，Redis是跨进程的分布式缓存，两者不是替代关系，而是上下级关系。我那天回答时画了一条链路：请求先进Caffeine，Caffeine没命中再查Redis，Redis还没命中才打数据库。这个链路也符合实际系统里“多级缓存”的典型架构。

面试官接着问了一个关键问题：既然Redis已经能抗住大部分请求了，为什么还要在前面加Caffeine？我给的答案是：因为Redis再快也有一次网络RTT和序列化开销，Caffeine是纯内存对象访问，毫秒和微秒的差距在高QPS场景下会被放大，而且Redis集群的带宽和连接数也不是无限的。

1.2 本地缓存与分布式缓存的定位差异

Caffeine和Redis之间的选择，本质上是“速度”和“一致性”之间的取舍。我在准备面经时整理过一张对比表，面试时直接按这张表的思路往外讲，逻辑非常清晰。

这张表里最值得展开的是“一致性”。本地缓存最大的问题就是每个服务实例各存一份，同一个key在不同机器上的值可能不一样。那天面试官追问：如果你们服务部署了10个实例，一条数据在数据库改了，Caffeine里还是旧值，怎么办？

这个问题我放在后面的缓存一致性章节详细说。但先记住一个原则：本地缓存适合存“变化不那么频繁、即使短暂不一致也不致命”的数据，比如配置项、商品的基础信息、或者经过聚合计算的热点结果。像用户余额、订单状态这类强一致数据，一定要以Redis或数据库为准。

1.3 面试官问Caffeine的真实意图

把Caffeine塞进Redis面经，面试官大概率不是真的想考你某个API怎么用，而是想确认三件事。

第一，你有没有真正理解缓存的分层价值。只背Redis八股的人，通常会把Redis当成唯一的缓存工具。但实际高并发系统里，本地缓存几乎一定会出现在Redis前面，如果你从来没考虑过这一层，说明你做的项目可能并发量不够，或者你只负责写了CRUD。

第二，你知不知道本地缓存是怎么做淘汰的。Caffeine的核心是W-TinyLFU算法，面试官会顺着这个问LRU为什么不够好、LFU又有什么问题，最后引出Caffeine的优化思路。这部分不是死记硬背，如果你能讲清楚算法原理，基本就能证明你阅读过源码或者深入研究过。

第三，你能不能处理缓存一致性问题。架构里多了一层缓存，就多了一层数据不一致的风险。面试官想听到的答案不是“我们项目用了Cache Aside模式”这种一句话答案，而是你能说清楚为什么先删缓存再更新数据库、延迟双删为什么不能根治、以及项目里最终怎么妥协的。

所以，这一章节的定位不是孤立地考Caffeine，而是在考察一个后端工程师对“数据访问链路”的整体理解。

2. Redis高频八股：底层结构、过期与淘汰

2.1 五种基础数据类型，为什么String能扛住大多数场景

Redis八股里最基础的就是五种数据类型：String、List、Hash、Set、ZSet。面试官一般会从“你们项目里用了哪些类型”开始，然后顺势让你讲底层结构。

我的建议是不要只背“String是SDS、List是quicklist、ZSet是跳表+哈希表”，而是要把每种类型的“为什么”讲出来。

先看String。String底层有int、embstr、raw三种编码方式，长度小于某个阈值用embstr，超过阈值转成raw。关键是SDS（简单动态字符串）的设计：它记录了used长度，所以获取字符串长度的时间复杂度是O(1)，而且在拼接字符串时可以根据空闲空间决定是否需要扩容，避免频繁内存分配。

List底层不是单一结构，在元素数量少时用压缩列表（新版本是listpack），元素多了之后转成quicklist。quicklist本质上是一个双向链表，每个节点又是一个压缩列表。这个设计的目的是在“内存紧凑”和“增删性能”之间做平衡。

Hash和ZSet底层都涉及哈希表和跳表。ZSet为什么用跳表而不是平衡树？面试官很喜欢问这个。跳表实现起来比红黑树简单，而且区间查询在跳表上很容易实现，只要找到起点然后顺序遍历后继节点就行。配合一个哈希表用来存member到score的映射，就能同时支持O(1)查score和O(logN)范围查询。

回答的时候用一个案例串起来会更有说服力。比如我说过：我们项目里用ZSet做排行榜，用Hash存用户的基本信息，用String做接口级缓存，用Set做UV去重。面试官接着就会问为什么UV去重不用HyperLogLog，这又是一个可以展开的点，但注意别扯太远。

2.2 过期删除策略：惰性+定期，而不是定时

Redis的过期删除策略是我认为八股里最值得深挖的点之一，因为它直接体现了“性能与内存的博弈”。

Redis的key过期后并不会立刻从内存里消失。它采用的是惰性删除 + 定期删除的组合策略。

惰性删除的意思是：每次访问一个key时，先检查它是否已经过期，如果过期了就删除并返回nil。这种方式的好处是对CPU友好，只有被访问的key才会触发检查，不会浪费CPU主动扫描。坏处也很明显：如果过期的key一直不被访问，它会一直占着内存。

定期删除就是为了解决这个问题的。Redis每隔一段时间会随机抽取一部分设置了过期时间的key，检查它们是否过期，过期就删除。注意是“随机抽取”，不是全量扫描。这是为了让删除操作的控制成本可控，不会因为一次性扫描所有key导致主线程卡顿。

那为什么不用定时删除呢？每个key设一个定时器，到点立刻删除，这在内存上最及时，但每个定时器都需要额外的CPU和内存开销，在高并发场景下完全不可接受。所以Redis选择了“懒 + 抽检”的组合。

这里面试官还有一个高频追问：如果内存被大量过期key占满了怎么办？答案就是expire不是实时的，依赖惰性删除和定期删除可能来不及，所以还要有内存淘汰策略兜底。

我当时补了一句：如果一个key设置了过期时间，但它已经通过内存淘汰被移除，那就不会再执行过期删除了。面试官点头，说明他知道我理解了两条机制是独立的。

2.3 内存淘汰策略与maxmemory-policy

Redis的内存淘汰策略是八股里的必考项。核心要背的是8种策略，但更重要的是理解“如何选”。

可以把它们分成三类：

第一类是不处理，也就是noeviction。内存满了之后，写入命令直接返回错误，读请求还能正常服务。这个策略适合当成保护开关，但生产环境很少单独用它。

第二类是只针对设置了过期时间的key进行淘汰，包括volatile-lru、volatile-lfu、volatile-random、volatile-ttl。这个适用于“缓存数据都有过期时间，且可以安全丢弃”的场景。

第三类是对所有key进行淘汰，包括allkeys-lru、allkeys-lfu、allkeys-random。这个适用于“Redis里存的都是缓存数据，没有必须长期保留的数据”的场景。

面试时，最好能说清楚LRU和LFU的区别。LRU按“最近访问时间”淘汰，问题是一个key曾经被访问过，之后很长时间不被访问，它仍然可能留在缓存里。LFU按“访问频率”淘汰，问题是一旦某个key的历史频率过高，即使它现在已经不热了，也很难被淘汰。

Redis实现的LRU是近似LRU，不是严格的LRU，因为它不会对所有key维护一个访问时间链表，而是采样后淘汰。LFU则用了Morris计数器的思路，频率计数会随时间衰减，避免“老的热点永远占着位置”。

我通常会这样回答：如果业务数据有明显的热频差异，选allkeys-lfu；如果只是通用缓存、希望实现简单，选allkeys-lru。不要用volatile类策略，除非你能保证所有key都设置了过期时间，否则没设过期时间的key永远不会被淘汰，风险很大。

3. Caffeine面经：本地缓存的实现细节

3.1 Caffeine的加载方式：Cache、LoadingCache、AsyncLoadingCache

Caffeine面试题不像Redis那么密集，但一旦开始问，问得都很细。首先要分清三种缓存接口。

Cache是最基础的同步缓存，获取一个key时如果未命中，可以直接计算并手动写入。LoadingCache内置了load方法，当key不存在时会自动调用加载逻辑，省去手动判断的代码。AsyncLoadingCache则是异步加载，适合加载逻辑比较耗时、不想阻塞请求线程的场景。

我建议在面试里给一个简单的配置例子，证明你真的用过，而不是光背概念。比如：

Cache<String, UserInfo> cache = Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(Duration.ofMinutes(5)) .recordStats() .build();

这个配置看起来简单，但里边有几个容易被追问的细节：maximumSize和maximumWeight有什么区别？expireAfterWrite和expireAfterAccess有什么区别？recordStats是干嘛的？

maximumSize按条数限制，maximumWeight按权重限制，如果每个缓存key的“内存占用”差异很大，用weight更合理。expireAfterWrite是写入后固定过期，expireAfterAccess是最后一次访问后过期，后者更适合读多写少的数据。recordStats会记录命中率、加载耗时等指标，生产环境一定要开，否则你根本不知道缓存到底有没有发挥作用。

Caffeine还支持refreshAfterWrite，也就是写入后多久自动刷新。这个和expireAfterWrite容易混淆。refresh是在后台异步刷新key的值，刷新期间请求还能拿到旧值，所以不会因为一个key过期而阻塞大量线程。但如果执行刷新时数据源挂了，它会把异常抛出来还是继续用旧值？默认配置下会因为加载失败返回异常，所以一般要配合自定义逻辑做降级。

我当时在项目里就是直接用LoadingCache + refreshAfterWrite，把热点配置放在本地，每30秒刷新一次，效果很好。面试官对这个方案很感兴趣，因为不是所有人都会想到用refresh来替代expire，把“锁等待”变成“异步更新”。

3.2 W-TinyLFU淘汰算法：为什么比LRU更聪明

Caffeine面试题里最容易卡住人的是W-TinyLFU。如果你不了解它的原理，很难解释Caffeine凭什么比Guava Cache更优秀。

先回忆LRU的问题：它只考虑“最近是否被访问”，不考虑“历史访问频率”。比如一个key在过去一分钟被访问了一万次，另一key刚刚被访问了一次，如果新key正好触发了淘汰，LRU可能会把高频key淘汰掉，但明明高频key更值得保留。

W-TinyLFU的设计思路是把缓存分成两个区域：窗口区和主区。窗口区很小，用于容纳新进入的数据，避免新数据因为频率低而直接被淘汰。主区存放长期存活的数据，使用LFU策略进行淘汰。

它用了一个叫做Count-Min Sketch的计数结构，用多个哈希函数映射到一个固定大小的频率表里，用空间换时间，近似地统计访问频率。因为不需要精确计数，所以内存占用很低。

窗口区还有一个准入机制：一个新来的key要进入主区，必须它的估算频率高于主区候选淘汰key的频率，否则就只留在窗口区。这就避免了“一次性热点”占据主区位置。

面试时不要背名词，用一句话概括它：W-TinyLFU通过窗口期给新数据机会，又通过频率计数保护真正的热数据，同时用Count-Min Sketch把计数开销降到可控。这句话足够让面试官知道你真的理解了这个算法。

如果面试官继续深挖，你还可以说：Caffeine默认不对缓存内容做全局锁，它通过多个内部队列和缓冲来降低并发竞争，这也是它性能高的原因之一。

3.3 缓存一致性：先更新数据库还是先删缓存

做缓存设计逃不开一致性问题。面试里最经典的问法是：Cache Aside模式下，更新数据时应该“先删缓存再更新数据库”，还是“先更新数据库再删缓存”？

先说结论：大多数场景采用“先更新数据库，再删缓存”，也就是Cache Aside的推荐顺序。为什么？因为先删缓存再更新数据库，在并发读请求下会出现一个窗口期：缓存删了，但数据库还没更新，另一个线程查到旧数据写回缓存，后续读到的还是旧值。

反过来，先更新数据库再删缓存，虽然也存在窗口期，但窗口期非常短，只有“数据库更新完成到缓存删除完成”这段时间。而且如果删除缓存失败，旧数据会继续留在缓存里，这个问题需要通过重试或者订阅binlog等机制来解决。

这里就会引出延迟双删。延迟双删是在先删缓存、再更新数据库之后，等几百毫秒再删一次缓存，目的是清掉之前并发读可能写回的旧值。但延迟双删并不能根治问题，因为延迟时间很难精确控制，而且多了一次额外操作。

那么本地缓存和Redis并存的场景下怎么做一致性？我的实践是：在更新数据库成功后，先删Redis，再通过异步通知或者版本号让各个服务实例的Caffeine失效。Caffeine没有像Redis那样的删除订阅机制，但你可以把缓存key设计成带版本号的，本地缓存只认最新版本，或者每次刷新时对比数据版本。

我还在项目里用过一个更简单粗暴的方案：对强一致要求高的数据不放在Caffeine里，只放在Redis，或者只放在数据库，不引入第二层缓存。这个方案看起来不够炫，但能够从根上避免多级缓存的一致性问题。我在面试里给了这个答案，面试官反而很认可，因为说明我知道什么时候该放弃“高级方案”。

4. 一套可以直接用的缓存设计方案

4.1 从QPS和数据特征决定用几级缓存

面试聊到缓存，最后一定会让你落到系统设计。我给过一套回答框架，现在拆开讲。

第一步，先算QPS和数据库的瓶颈。假设单库能抗500 QPS，接口的峰值QPS是10000，那你至少要降低99%的数据库请求。如果Redis能抗住混合读写，理论上只需要Redis一层也能行。但Redis的瓶颈通常在带宽和连接数，如果key又大又热门，单实例Redis也可能被打爆。所以需要按数据特征拆。

第二步，判断数据特征。热点非常集中的数据，比如商品详情、首页推荐列表，非常适合放到Caffeine。因为10000次请求里可能有9000次都在读同一个key。放进本地缓存后，这9000次根本不会打到Redis，Redis压力瞬间降下来。

第三步，确定每层的容量和过期时间。Caffeine的maximumSize可以根据JVM堆内存设置，一般几万到几十万条足够。Redis的容量看预算和机器规格，但也要给每条key评估大小。过期时间要错开，避免所有key在同一秒过期。

这套思路最大的价值是：它不是靠“感觉”决定用Redis还是Caffeine，而是根据热点比例和QPS来做推理。面试官听完会认为你有容量规划意识。

4.2 穿透、击穿、雪崩防护三板斧

缓存三兄弟是面试八股的高频题，但如果只是背定义，面试官一下就能听出来。我把这三个问题放在一个上下文里讲。

缓存穿透：请求查询一个根本不存在的数据，每次都会穿过缓存打到数据库。这时候哪怕缓存有十万个key也没用，因为查的key不在里面。解决方案有两种，一是对空结果也做短暂缓存，比如缓存一个空对象并设置较短的过期时间；二是在缓存前面加布隆过滤器，把不存在的key直接拦截掉。

缓存击穿：某个热点key恰好过期，大量并发请求同时打到数据库。和穿透的区别是击穿是“单个key过期”，穿透是“查询不存在的key”。解决思路是互斥锁，在缓存重建时加锁，只允许一个线程去加载数据库，其他线程等待锁释放后直接读取缓存。或者用Caffeine的refreshAfterWrite异步刷新，避免热点key过期瞬间阻塞所有请求。

缓存雪崩：大量key在同一时间过期，或者Redis实例本身挂了，导致所有请求打到数据库。预防措施是过期时间加一个随机值，避免key齐刷刷过期；同时Redis要做高可用，比如主从加哨兵，或者集群模式，不能单点。

我面试时回答完这三个点，都会补一句：这些方案不是互斥的，穿透和击穿可以同时存在，生产系统里通常要组合使用。这句话会让你的答案显得更有实战感。

4.3 监控：命中率、延迟、淘汰数

缓存设计再好看，上线后不加监控等于白做。面试时最后如果问落地，我一定会讲监控。

Redis本身的INFO stats里有个keyspace_hits和keyspace_misses，通过这两个值可以算出缓存命中率。命中率如果低于80%，说明缓存的价值没有发挥出来，要么key设计不合理，要么过期时间太短。

Caffeine是通过recordStats()来收集统计信息的。你可以定期输出CacheStats，看hitCount、missCount、evictionCount和loadSuccessCount。evictionCount突然变大，说明缓存容量不够或者数据写入过于频繁，需要调整最大容量或过期策略。

除了命中率，还有一个容易忽略的指标是平均缓存访问延迟。Caffeine本身访问就是微秒级，但如果加载逻辑很慢，loadSuccessCount会暴露出加载耗时过长的问题。Redis这边可以用SLOWLOG查看慢查询，尤其要注意大key操作和复杂命令。

监控的意义不仅在于排查问题，它也是面试时展示工程素养的机会。你可以说：我会把命中率、淘汰数、加载耗时打到监控系统里，按小时观察趋势，如果命中率突然跳水，就会排查是否有批量key过期或数据热点迁移。

5. 面经避坑与实战问题排查实录

5.1 容易在八股里翻车的细节

有些细节不翻一翻源码真的很容易答错，我整理几个我实际被问过、或者听过别人翻车的点。

第一个坑：Redis的String类型能存多大？答案是512MB，但这个数字本身不是重点，重点是你要知道String不适合存大对象，一大对象会带来网络传输和内存拷贝的浪费，还会增大阻塞风险。

第二个坑：Redis事务是原子的吗？面试官指望你回答“MULTI/EXEC不是真正的原子性，它只是按顺序执行，中间某个命令失败不会回滚前面的命令”。如果你只说“Redis事务是原子的”，基本就被判死刑了。

第三个坑：Caffeine的maximumSize设置过小会有什么问题？它不是报错，而是频繁淘汰和重新加载，导致命中率下降、Load次数飙升。实际表现是接口耗时不稳定，监控上看loadSuccessCount非常大。

第四个坑：把expireAfterWrite和refreshAfterWrite搞混。我之前在一次面试里回答“refreshAfterWrite会在过期后自动删除key”，面试官当场纠正说refresh是覆盖旧值，不是删除。这个点非常值得记住。

第五个坑：Redis Cluster下不能执行跨slot的MGET、MSET、Pipeline多key操作。很多人背多级缓存方案时会顺手说“把多个key一起查出来”，在Cluster模式下这会出现CROSSSLOT错误，只能用Hash Tag解决，或者写循环单key查询。

5.2 实战中踩过的一些缓存坑

每个做后端的人应该都被缓存坑过，这里写几个我自己踩过的真实问题。

第一个是缓存穿透打爆数据库。早期项目里有一个查询接口，用户传入的ID是连续的整数，但很多ID没有对应数据。当时没有做空缓存，也没有布隆过滤器，结果有人写了个脚本批量爬，每个不存在的ID都穿透到数据库，数据库连接瞬间被打满。后来加了空值缓存Map，虽然简单，但非常有效。

第二个是key同时过期导致的抖动。我们曾经给一批用户维度的缓存统一设置了2小时过期时间，结果每天固定时间点接口耗时从50ms飙到500ms。排查后发现就是大量key在同一秒过期，导致缓存雪崩。后来把过期时间改成“基础过期时间 + 随机0到300秒”，耗时曲线立刻平了。

第三个是Caffeine缓存和Redis缓存不一致。本地缓存里的配置数据更新频率很低，但有一次运营后台改动配置后，线上服务要等10分钟才能感知到。我们一开始把expireAfterWrite设成了10分钟，后来改成refreshAfterWrite每分钟刷新，再配合一个版本号字段，问题才算解决。

这几个坑告诉我：缓存设计不是配一个参数就完事，它需要你持续观察监控，及时调整策略。面试时讲这些真实经历，比背任何八股都更能打动面试官。

5.3 除了背八股，还能怎么准备

如果你还有时间准备，我会建议不要只刷面经。我自己准备“Redis八股 + Caffeine面经”时，做了一件很有价值的事：写了一个Demo项目，模拟多级缓存场景。

具体来说，就是用一个本地接口，第一次请求查数据库，第二次请求走Caffeine，然后把数据同步写到Redis。再用压测工具并发打这个接口，观察加Caffeine前后的TPS和P99延迟变化。这个过程会让你真正理解本地缓存的价值。

然后故意制造几个故障场景：手动删除Redis里的缓存，观察击穿；把Caffeine的maximumSize调小，观察淘汰率；把数据库查不出的数据请求打进来，观察穿透。这些实验做完，你对缓存的理解会远超背题。

面试时，当面试官问“你项目里遇到过缓存问题吗”，你可以顺手把实验过程中的现象、排查思路和改进方案讲一遍，这比回答“遇到过，后来加了缓存”要有说服力得多。八股是基础，但真正的分水岭是你有没有在实践中验证过这些知识点。

我在准备阶段还养成了一个习惯：每道面试题都写一个“为什么”的注释。比如Redis为什么快，不只是“内存操作”，还因为IO多路复用、单线程避免上下文切换、高效的数据结构。Caffeine为什么比Guava Cache快，不只是一个W-TinyLFU，还因为它对并发读多写少的场景做了大量无锁优化。把每个结论还原成原理，面试官才愿意相信你是真的懂。