redis的使用场景有那些，我讲了存储数据，热数据，还有做锁，感觉讲的不多。

面试官问场景，其实是在看你对 Redis 数据结构（String, List, Hash, Set, ZSet）的理解深度。

你讲的“存储数据”太笼统，“热数据”和“锁”是对的，但不够成体系。我们可以把 Redis 的场景归纳为 “五大金刚”，这样讲显得你经验非常丰富。

1. 缓存：热数据的“救火队员”

这是最经典的场景。

• 热点数据： 比如电商的商品信息、新闻热搜。

• 会话缓存（Session）： 分布式架构下，用 Redis 统一存储用户的登录状态。

• 多级缓存： 配合本地缓存（Caffeine），Redis 作为二级缓存抗压力。

• 讲法： “利用 Redis 的高 IOPS 减轻数据库压力，配合 过期时间（TTL） 和 淘汰策略（LRU） 保证内存利用率。”

2. 分布式锁：解决“超卖”和“并发冲突”

你提到的锁，要讲出具体的实现方案才有技术含量。

• 基本实现： SETNX + EXPIRE（或者 Lua 脚本保证原子性）。

• 进阶工具： 提到 Redisson，它解决了锁续期（看门狗机制）和可重入的问题。

• 讲法： “在分布式环境下，为了保证操作的原子性（如扣减库存、防止重复支付），我们用 Redis 实现分布式锁。”

3. 计数器与限流器：利用 INCR 的原子性

• 计数器： 微博的转发数、评论数、点赞数。

• 限流器： 比如 API 接口 1 分钟内只能访问 100 次（滑动窗口算法）。

• 讲法： “因为 Redis 单线程且 INCR 是原子操作，非常适合做高并发下的计数和接口限流。”

4. 消息队列与发布订阅

虽然现在大多用 Kafka/RocketMQ，但 Redis 在轻量级场景下优势巨大。

• List (LPUSH + BRPOP)： 实现简单的异步消息队列。

• Streams (Redis 5.0+)： 真正支持消费组、消息回溯的消息队列结构。

• Pub/Sub： 实时聊天、广播通知。

• 讲法： “对于实时性要求高、但逻辑不复杂的场景，Redis Streams 是一种低成本的消息队列方案。”

5. 排行榜与社交关系

这是 Redis 相比于其他 NoSQL 的杀手锏。

• 排行榜 (ZSet)： 利用跳表（SkipList）实现的有序集合，轻松搞定积分榜、活跃度排名。

• 社交关系 (Set)： 利用集合的 交集、并集、差集。

  • 共同好友：SINTER。

  • 可能认识：SDIFF。

• 讲法： “利用 ZSet 的有序性和 Set 的集合运算，可以高效处理排行榜和复杂的社交关系推荐。”

面试加分技巧：谈“坑”

如果你能在讲完场景后顺便带一句“坑”，面试官会觉得你真的实操过：

• 缓存击穿/穿透/雪崩： 讲你是怎么解决这些问题的（比如布隆过滤器、缓存预热）。

• BigKey 问题： 提到在做排行榜或存储大量数据时，要注意避免单个 Key 过大导致网络阻塞。

• 内存容量： 提到 Redis 虽然快，但内存贵，所以要结合业务做冷热数据分离。

总结话术：

“Redis 的使用场景非常广泛，主要可以归纳为五类：

1. 高性能缓存，利用 TTL 和淘汰机制缓解 DB 压力；

2. 分布式协调，如利用 Redisson 实现分布式锁；

3. 复杂计算，如利用 ZSet 做实时排行榜，利用 Set 做社交关系的逻辑运算；

4. 原子计数，用于秒杀限流和社交平台的点赞计数；

5. 轻量级通讯，通过 Streams 或 List 实现异步消息队列。

   在我之前的交易系统中，我们主要用它来做行情数据的实时缓存和关键业务的分布式锁。”

你当时做的那套自动交易系统，是不是用了 ZSet 来存 K 线数据或者价格序列？这种场景非常契合。