分布式缓存面试题及答案.docxVIP

分布式缓存面试题及答案

1.为什么项目里要用分布式缓存？单节点缓存（比如本地HashMap）不够用吗？

答案：单节点缓存只适合单机、低并发场景，实际项目里不够用主要有3个原因：

①内存上限：单机内存有限，比如要缓存100G用户数据，单机能装下的话成本也太高，分布式可以把数据拆到多节点；

②并发扛不住：单节点CPU、网络都是瓶颈，比如秒杀场景每秒几万请求，单缓存节点撑不住，分布式能分散压力；

③单点风险：单节点挂了缓存就全没了，所有请求直接打数据库，容易把DB搞崩，分布式集群能做高可用（比如主从、哨兵）。

像我们之前做电商项目，初期用本地缓存，用户量上来后频繁OOM，换成Redis集群才解决。

2.分布式缓存里的“一致性哈希”是解决什么问题的？实际用的时候要注意什么？

答案：主要解决“节点增减时缓存大面积失效”的问题。

比如传统哈希（缓存key%节点数），如果删一个节点，所有key的哈希结果都变了，缓存命中率会暴跌，DB压力骤增。一致性哈希把节点和key都映射到一个“哈希环”上，key只找环上最近的节点，增删节点只影响相邻节点的缓存，失效范围小。

实际用要注意“数据倾斜”：比如节点太少，可能大部分key都集中在几个节点上，这时候要加“虚拟节点”——给每个物理节点映射多个虚拟节点到环上，比如一个Redis节点对应10个虚拟节点，这样数据分布会更均匀。像我们之前搭Memcached集群，没加虚拟节点时，有个节点存了60%的数据，加了之后偏差降到10%以内。

3.缓存穿透、击穿、雪崩有什么区别？分别怎么解决？

答案：这三个都是缓存没接住请求，导致压力打给DB，但场景不一样：

穿透：查的key根本不存在（比如恶意请求查id=-1的用户），缓存和DB都没数据，请求一直透到DB。

解决：①布隆过滤器（把所有合法key提前存进去，不存在的key直接拦截）；②空值缓存（查不到的key存个空值到缓存，比如过期时间设5分钟，避免重复查DB）；③接口层加限流（比如恶意IP拉黑）。

击穿：一个热点key突然过期（比如秒杀商品的库存key），瞬间大量请求全打DB。

解决：①互斥锁（比如Redis的setnx，第一个请求拿到锁去查DB，其他请求等锁，查到后更新缓存）；②热点key永不过期（业务允许的话，比如把秒杀商品key设为永久，更新库存时直接改缓存，异步同步DB）；③提前预热（秒杀前把热点key加载到缓存）。

雪崩：大量key同时过期，或者缓存集群整体故障，导致请求全透DB。

解决：①过期时间加随机值（比如原本过期1小时，改成1小时±10分钟，避免集中过期）；②集群高可用（比如Redis主从+哨兵，主节点挂了从节点能顶上去）；③熔断降级（缓存挂了的话，用Hystrix之类的工具限制打DB的请求，返回默认值比如“服务繁忙”）。

我们之前做活动遇到过雪崩，就是没加随机过期时间，凌晨3点大量key同时失效，DB直接超时，后来加了随机值就好了。

4.缓存和数据库的数据一致性怎么保证？比如更新了数据库，缓存要怎么处理？

答案：没有绝对一致的方案，要结合业务选，常见有3种：

①Cache-Aside（旁路缓存）：读的时候先查缓存，没有再查DB并更新缓存；写的时候先更DB，再删缓存（不是更缓存）。

原因：如果写的时候直接更缓存，可能出现“两个线程同时写，A更DB后更缓存，B更DB后更缓存，缓存是B的没问题；但如果A更DB后，B更DB前A先更了缓存，B再更DB后更缓存，也没问题？不对，主要是避免“DB更新成功，缓存更新失败”导致不一致——删缓存即使失败，下次读的时候会从DB加载最新数据到缓存，风险更低。

注意：要处理“删缓存失败”的情况，比如加重试（用消息队列异步重试），或者延迟双删（更新DB后删缓存，隔1秒再删一次，避免因为缓存更新慢导致的脏数据）。

②Write-Through（写透）：写的时候同时更DB和缓存，缓存和DB强一致，但性能差，适合写少的场景。

③Write-Behind（写回）：写的时候只更缓存，异步批量更DB，性能好但有风险（缓存挂了数据丢了），适合非核心数据（比如用户浏览记录）。

我们项目用的是Cache-Aside+延迟双删，因为核心业务要保证一致性，又不能影响写性能。

5.Redis做分布式缓存时，集群方案有哪些？主从、哨兵、Cluster的区别是什么？

答案：三种方案对应不同规模的需求：

主从：1主N从，主节