面经策

Redis 通常应用于哪些场景？ ​

  • 标签：后端、Redis

🏛 业务架构师 ​

Redis 的典型场景我按业务功能归类，每个都标注"用 Redis 的理由"：

  • 缓存热点数据（第一场景）：商品详情、用户信息——DB 毫秒级 vs Redis 微秒级，用 10 台 Redis 挡掉 90% 读流量，省 90 台 DB，缓存架构是成本结构问题；
  • 排行榜：ZSet 实时更新（销量榜、打赏榜）——运营活动的实时仪表盘；
  • 计数器：incr 原子自增——阅读量、点赞数、限流计数；
  • 分布式锁：并发互斥（防重复提交、任务调度防重跑）——注意"锁是优化不是正确性依赖"；
  • 会话存储：登录态集中存（Session 共享、token 白名单）——多实例部署的前提；
  • 签到/活跃标记：Bitmap，1 亿用户一天 12MB——海量布尔状态的唯一经济解；
  • UV 统计：HyperLogLog，十几 KB 数十亿独立访客，0.81% 误差的划算交易；
  • 简单消息/队列：ListStream 做轻量异步（正式 MQ 的前置替代，注意可靠性边界）；
  • 附近的人/店：GEO 地理位置；
  • 验证码/一次性 token：TTL 自动过期。

架构判断的三个原则：

  1. 先问数据丢了会怎样：可再生的（缓存、计数）放心放；不可再生的（订单事实、资金）永远以 DB 为事实源——Redis 的持久化是"尽力而为"，不是数据库承诺；
  2. Redis 是"数据结构即服务"：业务建模时先看哪种结构匹配访问模式（字段级更新用 Hash、排序用 ZSet），选对结构 = 省一次自研；
  3. 成本意识：内存比磁盘贵百倍，冷数据别放 Redis——容量水位线（70%）与 TTL 纪律是日常治理动作。

一句话：Redis 解决的是**"热点 + 实时 + 高并发"的数据访问问题**，边界内它是性价比之王，越界（当主库用）就是事故预算。

🏗 系统架构师 ​

我把 Redis 的应用场景按数据结构能力归类：

  • 缓存（最普遍）：热点数据缓存、页面片段缓存、查询结果缓存——读 QPS 10 万级、毫秒响应，给 DB 降两个数量级压力；配合本地缓存（Caffeine）组成多级缓存；
  • 计数器/限流：INCR 原子计数——播放量、点赞数、接口调用配额、RateLimiter 限流窗口（ZSET 滑窗、Lua 令牌桶）；
  • 分布式锁与协调：SET NX + 过期时间做互斥（Redisson），秒杀防超卖、定时任务防重跑；
  • 排行榜/排序：ZSET——热度榜、积分榜、延迟队列（score=时间戳轮询）；
  • 会话存储：集中 Session（Spring Session），支撑集群水平扩缩容；
  • 去重与判存：Set（抽奖、标签）、Bitmap（签到、日活，亿级用户仅 MB 级）、HyperLogLog（UV 估算 12KB）、布隆过滤器（缓存穿透防御）；
  • 消息队列：List 阻塞队列 / Stream 消费组（轻量场景）/ Redisson 延迟队列——低可靠要求场景省去重型 MQ；
  • 地理位置：GEO 附近的人/店；
  • 全局 ID：INCR/INCRBY 号段分配。

架构定位认知：Redis 的价值 = 内存速度 + 丰富结构原子操作，但它是"可丢失的最佳努力存储"（异步持久化有窗口），我的红线：能丢的进 Redis（缓存）、不能丢的在 DB，把 Redis 当唯一事实源的设计都要重新审视。

💻 全栈开发专家 ​

我按"结构选型 + 一句话实现"过一遍，都是真用过的：

  • 对象缓存（最主流）：商品详情、用户信息，Cache Aside 模式（读 miss 回源回填，写先更 DB 后删缓存），TTL 兜底防脏。
  • 分布式缓存/Session 共享：spring-session-redis，多实例登录态统一存 Redis，重启不丢会话。
  • 分布式锁：SET NX EX + Lua 释放，或 Redisson RLock；防重复提交、定时任务防并发执行。
  • 排行榜：ZSET，ZINCRBY 加分 + ZREVRANGE 取 Top N + ZREVRANK 查名次。
  • 计数器/限流：INCR 原子计数（阅读数、点赞数）；固定窗口限流 INCR+EXPIRE，令牌桶用 Lua。
  • 去重/存在性判断：Set（抽奖名单、共同好友），海量去重用 HyperLogLog（UV，12KB 误差 0.81%），防缓存穿透用布隆过滤器。
  • 延迟队列：ZSET score 存执行时间戳，轮询 ZRANGEBYSCORE key 0 now LIMIT 0 10 捞到期任务（订单超时关闭的轻量方案）。
  • 分布式 Session 之外的社交场景：GEO 附近的人/店（GEOADD/GEOSEARCH）。
  • 简单消息流：Stream 消费组（XADD/XREADGROUP/XACK），偶尔替代小规模 MQ。

统一工程规范：key 命名 业务:模块:标识、所有 key 必须带 TTL（除了明确的白名单）、大 key 和热 key 定期巡检（--bigkeys）、缓存与 DB 一致性方案先想清楚再写代码——场景会选，坑也能避开，这题才算过。