加上缓存

解题思路：

这是最基础的操作命令，但真正用到时还要分清秒级、毫秒级和绝对时间戳三个变体，才能在缓存时长需要精细控制时选对命令。

详细步骤：

最终答案：EXPIRE key seconds

扩展知识：

• EXPIRE key seconds - 设置键的过期时间（秒）
• PEXPIRE key milliseconds - 设置键的过期时间（毫秒）
• EXPIREAT key timestamp - 设置键在指定时间戳过期
• TTL key - 查看键的剩余生存时间（秒）

示例：

解题思路：

三者最容易混着记，要按「成因 → 数据是否存在 → 并发特征」三个维度对照着看：穿透是查不存在的数据，击穿是热点 key 过期，雪崩是大量 key 同时失效或缓存服务宕机。

详细步骤：

三种缓存问题的区别：

详细解释：

1. 缓存穿透：用户查询的数据在缓存和外部 API 中都不存在，每次请求都会访问外部 API。

2. 缓存击穿：某个热点 key 突然过期，此时大量请求同时访问这个 key，导致请求全部打到外部 API。

3. 缓存雪崩：大量缓存 key 在同一时间过期，或者 Redis 服务器宕机，导致所有请求都涌向外部 API。

最终答案：

穿透——查询的数据压根不存在，请求直接打到外部 API，用布隆过滤器或缓存空对象防；击穿——热点 key 过期瞬间大量请求涌入，用互斥锁或逻辑过期防；雪崩——大量 key 同时过期或 Redis 宕机，用随机过期时间加高可用架构与降级方案防。

解题思路：

这题没有唯一答案，关键是能说清三种方案各自的一致性代价：删除缓存比改写缓存更简单，主动更新最一致但最费事，而设置过期时间只是兜底。

详细步骤：

常见方案：

方案一：缓存失效策略

当外部 API 数据更新时，主动使缓存失效：

方案二：设置缓存过期时间

• 给缓存设置合理的过期时间
• 过期后自动从外部 API 重新获取

方案三：主动更新缓存

各种方案对比：

最终答案：

三种方案按代价从低到高排列：① 缓存失效策略——外部 API 数据更新后主动删除缓存，配合合理的过期时间兜底，代价最低但存在短暂不一致窗口；② 主动更新缓存——一致性最好，但要在更新与缓存之间处理并发与失败；③ 只设过期时间——实现最简单，但一致性最弱。实践中通常以①为主、②用于关键数据、③作最后防线。

解题思路：

要按「能力 → 场景」两列来记：先说每种结构提供什么操作（键值、有序、字段、去重、带分数排序），再落到具体业务对象上。

详细步骤：

Redis 五大基本数据结构：

扩展数据结构：

• Bitmap - 签到统计、用户在线状态
• HyperLogLog - UV 统计
• Geospatial - 附近的人、地理位置

最终答案：

String 用于键值缓存、计数器和分布式锁；List 用于消息队列与最新列表；Hash 用于存储对象和购物车；Set 用于去重、好友关系和抽奖；ZSet 用于排行榜与带权重的排序。

解题思路：

这道题要的是一个能落地的流程，而不是一句「加个缓存」。重点是 key 怎么拼、过期时间怎么设，以及未命中和查不到这两种情况分别怎么处理。

详细步骤：

最终答案：

1. 使用 user: 命名规范，便于管理
2. 使用 SETEX 原子操作设置值和过期时间
3. 空值也缓存，防止缓存穿透
4. 合理设置过期时间，平衡性能和数据新鲜度

完整流程是：用 user:{id} 拼 key → 查 Redis → 命中直接返回；未命中则调用外部 API 取数，用 SETEX 原子写入并设置 30 分钟过期，同时把回源结果返回给用户；对查询不到的用户写入带较短过期时间的空值标记，避免同一个不存在的 key 反复回源。四个关键点：统一的 user: 命名规范便于管理、用 SETEX 原子设置值与过期时间、空值也要缓存以防穿透、过期时间在性能与数据新鲜度之间取平衡。