在移动端开发中，针对一个高频访问的API（如用户信息查询），如何设计缓存策略以减少用户等待时间？请说明缓存层次、缓存数据选择、失效策略及常见问题处理（如缓存穿透、雪崩、击穿）。
Tencent软件开发-移动客户端开发方向难度：中等
答案
1) 【一句话结论】针对高频访问的API，应采用分层缓存（内存+数据库），结合LRU淘汰、TTL过期及主动失效策略，并设计布隆过滤器防穿透、随机过期防雪崩、互斥锁防击穿，以平衡性能与一致性。
2) 【原理/概念讲解】
老师口吻：移动端API缓存的核心是“快”与“稳”，需分层次设计。
- 缓存层次：第一层是内存缓存（如Redis），速度快，用于存储热点数据；第二层是数据库（或文件系统），用于持久化存储。
- 缓存数据选择：优先缓存用户信息、登录状态、首页推荐等高频访问且变化不频繁的数据（类比：就像超市的货架，把热销商品放在显眼位置，减少用户等待）。
- 失效策略：
- TTL（Time To Live）：指定时间后自动失效（主动失效，如用户信息缓存1小时过期）；
- 主动失效：业务逻辑触发（如用户信息更新时，主动删除缓存，再更新数据库）；
- 被动失效：根据数据变化（如数据库更新时，通知缓存系统删除对应数据）。
- 常见问题：
- 缓存穿透：查询不存在的数据（如空用户ID），导致所有请求都落库，消耗资源；
- 缓存雪崩：大量缓存同时失效（如TTL统一为0点），导致请求全部落库，系统崩溃；
- 缓存击穿：高并发下热点数据失效（如用户登录接口），所有请求竞争数据库，压力激增。
3) 【对比与适用场景】
| 策略 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| LRU | 最近最少使用淘汰 | 优先淘汰最久未使用的数据 | 热点数据多，内存有限 | 需维护时间复杂度 |
| TTL | 时间过期 | 指定时间后自动失效 | 数据变化频率固定，过期时间明确 | 可能导致数据不一致 |
| 主动失效 | 业务逻辑触发删除 | 实时更新缓存 | 数据更新频繁，需立即同步 | 需额外通知机制 |
| 布隆过滤器 | 用于缓存穿透防御 | 确定数据不存在时快速返回 | 防止缓存穿透，减少无效请求 | 可能存在误判（假阳性） |
4) 【示例】
伪代码（用户信息查询缓存逻辑）：
def get_user_info(user_id):
# 检查内存缓存（Redis）
user_info = redis.get(f"user:{user_id}")
if user_info:
return json.loads(user_info)
# 缓存未命中，查询数据库
user_info_db = db.query("SELECT * FROM users WHERE id = ?", user_id)
if user_info_db:
# 存入内存缓存，设置TTL（如1小时）
redis.setex(f"user:{user_id}", 3600, json.dumps(user_info_db))
return user_info_db
else:
return None
5) 【面试口播版答案】
（约90秒）
“面试官您好，针对高频访问的API（如用户信息查询），我会采用分层缓存策略。首先，缓存层次上，用内存缓存（如Redis）作为第一层，数据库作为第二层。缓存数据选择上，优先缓存用户信息、登录状态等热点数据。失效策略方面，结合TTL（比如1小时过期）和主动失效（用户信息更新时删除缓存），同时用LRU淘汰冷数据。然后处理常见问题：缓存穿透用布隆过滤器，缓存雪崩用随机过期时间，缓存击穿用互斥锁。具体来说，比如用户查询时，先查Redis，若没有再查数据库，存入Redis并设置TTL，用户信息更新时主动删除缓存。这样既能减少用户等待时间，又能保证系统在高并发下的稳定性。”
6) 【追问清单】
- 问：如何解决缓存穿透？
回答要点：用布隆过滤器预判不存在的数据，返回错误或空值，避免请求落库。 - 问：缓存雪崩怎么处理？
回答要点：为缓存设置随机过期时间，避免同时失效；或用双缓存（主缓存+备用缓存）。 - 问：缓存击穿如何应对？
回答要点：对热点数据加互斥锁，保证同一时间只有一个请求去数据库，其他请求等待锁释放后的缓存结果。 - 问：缓存更新策略？
回答要点：用户信息更新时，先删除缓存（主动失效），再更新数据库，保证数据一致性。 - 问：缓存预热？
回答要点：系统启动时预加载热点数据到缓存，减少首次查询延迟。
7) 【常见坑/雷区】
- 坑1：只说TTL而忽略LRU，导致冷数据占用内存。
雷区：未考虑缓存淘汰机制，导致内存溢出。 - 坑2：缓存穿透未处理，导致数据库压力过大。
雷区：未用布隆过滤器，所有不存在的数据都落库，影响性能。 - 坑3：缓存雪崩未处理，导致大量请求同时落库。
雷区：所有缓存同时失效，数据库瞬间压力激增，系统崩溃。 - 坑4：缓存击穿未加锁，导致高并发下所有请求都落库。
雷区：热点数据失效时，所有请求竞争数据库，导致数据库压力激增。 - 坑5：缓存更新策略错误，导致数据不一致。
雷区：未主动失效，导致缓存数据与数据库数据不同步。