什么场景下会使用分布式缓存？｜阿里巴巴算法面经解析

60 秒回答模板

我会在三类典型场景下使用分布式缓存：第一是读多写少且数据重复访问率高，比如商品详情、用户配置、榜单、权限信息等，用缓存减少数据库压力；第二是热点和高并发场景，比如秒杀、活动页、热门内容，需要把请求挡在缓存层并配合限流、预热和过期策略；第三是计算或查询代价高的场景，比如复杂聚合、跨服务查询、外部接口结果缓存。使用时要同时考虑缓存一致性、TTL、淘汰策略、缓存穿透、击穿、雪崩、容量规划和降级方案，避免把缓存用成新的单点瓶颈。

考点 核心判断标准

主线 读多写少业务

易错点 只回答 Redis 很快，所以高并发时使用，没有解释业…

深入解析

核心判断标准

判断是否使用分布式缓存，核心不是看到 Redis 就加一层，而是看数据是否具备高复用、高读取频率、对毫秒级响应敏感、源存储访问代价高等特征。如果一次写入会被大量读取，或者一次计算结果会被多个请求复用，缓存收益通常很明显；反之，如果数据几乎只访问一次、强一致性要求极高、更新频率远高于读取频率，缓存反而会增加复杂度。

读多写少业务

最典型的场景是读多写少，例如商品详情、店铺信息、用户基础资料、配置项、字典表、城市区域数据、权限菜单等。这类数据写入或变更不频繁，但会在大量请求中反复读取，直接查数据库会造成连接数、IO 和查询 CPU 的浪费。把这类数据放入分布式缓存，可以让多台应用实例共享同一份缓存结果，避免本地缓存不一致和重复加载。

热点高并发场景

当某些数据在短时间内被集中访问时，分布式缓存可以承担削峰作用，比如秒杀商品库存展示、活动页面信息、热门文章、直播间基础信息、爆款商品价格等。此时数据库并不适合承接所有读请求，缓存层可以用更低的访问成本承载大部分流量。不过热点场景还要考虑预热、热点 key 拆分、本地缓存结合、限流和降级，否则单个热点 key 也可能压垮缓存节点。

降低慢查询和复杂计算

如果一次请求需要复杂 SQL、跨表聚合、跨服务调用、排序统计或访问外部接口，也适合把结果缓存起来。典型例子包括排行榜、推荐候选集、报表摘要、首页聚合模块和搜索条件聚合结果。这类数据的价值在于计算成本高，而不是单条数据本身很大。缓存可以把昂贵计算转化为快速读取，但需要明确结果的有效期和更新触发条件，避免用户看到长期过期的数据。

共享状态与分布式协同

分布式缓存还常用于多实例之间共享轻量状态，例如登录态 token、验证码、短期风控计数、接口幂等标记、分布式锁、限流计数器和会话信息。因为应用服务通常是无状态水平扩展的，不能依赖某一台机器的内存保存这些状态。使用 Redis 这类集中式缓存，可以让所有应用节点读写同一份短生命周期数据，但锁和计数场景要特别注意原子性、过期时间和异常释放问题。

保护数据库和外部依赖

缓存经常被用来保护后端资源，尤其是在数据库、搜索引擎、第三方接口或老系统承载能力有限时。业务请求先访问缓存，命中后直接返回，未命中才访问后端依赖，这能显著降低依赖系统的峰值压力。需要注意的是，缓存不是无限抗压层，必须配合空值缓存、互斥重建、随机过期、熔断降级等手段，否则在缓存失效或异常时，流量可能瞬间打到数据库形成雪崩。

一致性取舍

使用分布式缓存时一定要说明一致性取舍。多数业务使用缓存是接受短暂最终一致，而不是追求缓存和数据库每一时刻完全一致。常见策略是先更新数据库再删除缓存，或者通过消息、订阅、Binlog 同步来异步失效缓存。对于余额、库存扣减、交易状态这类强一致核心数据，不能简单依赖缓存作为事实来源，缓存最多用于展示或辅助判断，最终仍要以数据库或事务系统为准。

易错点

只回答 Redis 很快，所以高并发时使用，没有解释业务访问特征和收益来源。
把分布式缓存说成数据库替代品，忽略数据持久化、事务和强一致边界。
只列举商品详情、用户信息等例子，没有说明读多写少和命中率判断标准。
没有提到缓存穿透、击穿、雪崩，导致回答缺少高并发场景下的工程完整性。
忽略缓存与数据库一致性问题，默认写库后缓存一定会自动同步正确。
认为所有热点都能靠单个 Redis key 扛住，没有考虑热点 key 拆分和限流降级。

面试官追问

分布式缓存和本地缓存有什么区别？

本地缓存速度更快，因为不需要网络访问，但每个应用实例都有一份副本，容量有限且多实例之间一致性较难维护。分布式缓存由独立集群提供服务，多台应用共享同一份数据，容量和治理能力更强，适合登录态、热点数据、业务配置等跨节点共享场景。实际系统中也会组合使用，本地缓存抗极热点，分布式缓存承接共享数据。

为什么不用数据库索引解决所有性能问题？

数据库索引能优化查询路径，但不能消除高并发读请求带来的连接、锁、Buffer Pool、网络和 CPU 压力。对于大量重复读取的数据，每次都访问数据库仍然是浪费。分布式缓存把频繁访问的数据放到内存系统中，响应更快，也能把数据库资源留给事务写入、复杂查询和缓存未命中的请求。

缓存穿透怎么解决？

缓存穿透是指请求的数据既不在缓存中，也不在数据库中，攻击流量或异常参数会反复打到数据库。常见方案是缓存空值并设置较短 TTL，使用布隆过滤器提前拦截明显不存在的 key，对非法参数做校验和限流。需要注意空值缓存不能过长，否则新写入的数据可能在一段时间内被旧的空结果遮挡。

缓存击穿和缓存雪崩有什么区别？

缓存击穿通常是单个热点 key 过期，大量请求同时回源数据库重建缓存；缓存雪崩则是大量 key 同时失效，或者缓存集群整体不可用，导致后端系统被集中冲击。击穿常用互斥锁、逻辑过期、后台刷新解决；雪崩常用过期时间加随机值、多级缓存、限流降级、缓存高可用和数据预热解决。

如何保证缓存和数据库一致性？

常见做法是更新数据库成功后删除缓存，让后续请求重新加载新数据；对于更高要求的场景，可以结合消息队列、Binlog 订阅、延迟双删或版本号校验。要注意缓存和数据库很难在普通业务系统里做到绝对强一致，更多是通过短 TTL、重试补偿、幂等消费和监控告警，把不一致窗口控制在业务可接受范围内。