纸上得来终觉浅，绝知此事要躬行。到了下篇，我们不再纠结底层指令，而是切换到 架构师视角，看 Redis 如何左右战局。

---

📑 下篇目录

• 提问五：Redis 五种数据类型的常用场景有哪些，如何实现分布式锁和排行榜

• 提问九：Redis 如何解决缓存穿透，缓存击穿和缓存雪崩问题

---

五、Redis 五种数据类型的常用场景有哪些，如何实现分布式锁和排行榜

1. 场景精讲

• String：缓存对象 JSON、分布式 ID（INCR）、分布式锁（SETNX）、计数器（阅读量）。

• Hash：存储对象（用户信息/商品详情，支持单独改字段）、电商购物车（HINCRBY 增减数量）。

• List：轻量级消息队列（LPUSH + BRPOP）、最新动态时间线（LRANGE 取最新 N 条）。

• Set：标签系统（SADD）、共同好友（SINTER 交集）、抽奖去重（SPOP 随机弹出）。

• Sorted Set：实时排行榜（ZINCRBY 更新分数）、延时队列（Score 存时间戳，ZRANGEBYSCORE 取到期任务）。

2. 如何实现分布式锁？

核心原则：SET key value NX EX seconds（原子性设置锁，只有 Key 不存在时才成功）。

• 解锁：必须配合 Lua 脚本校验 Value（防止超时误删别人的锁）。

• 进阶（Redisson）：引入“看门狗”机制自动续期，解决业务执行超时锁自动释放的问题。

3. 如何实现排行榜（以游戏积分榜为例）？

• 玩家积分更新：ZADD rank 100 player1 或 ZINCRBY rank 10 player1。

• 查询 Top 10：ZREVRANGE rank 0 9 WITHSCORES（按分数从高到低取前 10）。

• 查询玩家排名：ZREVRANK rank player1（返回从 0 开始的名次）。

---

九、Redis 如何解决缓存穿透，缓存击穿和缓存雪崩问题

这是 Redis 生产环境 必考的灵魂三问，也是架构防御战的最高体现。

1. 缓存穿透（数据根本不存在）

现象：大量请求查询 DB 中不存在的数据（如 id=-1），绕过缓存直接击穿 DB。
解决方案：

• 方案 A（缓存空对象）：DB 查询为空时，缓存一个空值（null）并设置较短过期时间（如 5 分钟），防止反复穿透。

• 方案 B（布隆过滤器）：最彻底防御。在缓存前置一层布隆过滤器，将存在的数据 Key 映射进去。请求来了先过布隆，判断“不存在”则直接拦截，判断“可能存在”才放行（极低误判率）。

2. 缓存击穿（热点 Key 过期）

现象：某个访问极高的热点 Key（如双 11 秒杀商品）突然过期，大量并发请求同时打到 DB。
解决方案：

• 方案 A（互斥锁 SETNX）：当缓存失效时，第一个请求抢到分布式锁去 DB 查并重建缓存，其他请求短暂等待或重试。只让一个线程查 DB。

• 方案 B（逻辑过期）：缓存不设置物理过期时间，而是在 Value 中存逻辑过期字段。检测到过期时，异步线程去更新缓存，当前请求返回旧数据（适用于容忍短暂不一致的高并发场景）。

3. 缓存雪崩（大面积 Key 同时失效 / Redis 宕机）

现象：大量缓存同一时间集体失效，或 Redis 节点宕机，洪水般的请求涌入 DB 导致数据库崩溃。
解决方案：

• 方案 A（过期时间加随机偏移）：设置 TTL 时加上一个随机数（如 3600 + random(0,300)），避免大面积 Key 同时过期。

• 方案 B（高可用集群）：部署 Redis 主从+哨兵或 Cluster，确保 Redis 本身不挂。

• 方案 C（熔断与限流）：引入 Sentinel/Hystrix，当 DB 压力陡增时自动熔断降级，返回友好错误信息，保护核心业务。

---

🎯 写在最后（全文终章）

到这里，《Redis 系统知识完全拆解》上、中、下三篇就全部结束了。

回顾征途：

• 上篇，我们看懂了单机到集群的架构史诗、RESP 协议的极简美学、五大金刚的数据秘笈，以及 Pipeline 与 Lua 的底层对决。

• 中篇，我们钻进了 fork() 与写时复制的内核缝隙，理清了过期与淘汰的微妙权衡。

• 下篇，我们跃升为架构师，手持 Redis 利刃，斩落分布式锁与缓存三大魔头。

整个互联网架构，一半是缓存，一半是数据库。得缓存者，得吞吐。懂 Redis 者，得天下。

如果这三篇文章让你在某个深夜有了恍然大悟的瞬间，或者在你的面试/实战中助你一臂之力，请不要吝啬你手中的 点赞、收藏和关注。我是 CodeStats，我们下个系统底层技术（MySQL 或 Kafka？）系列再见！