Redis 缓存与高性能存储课程

🎯 课程目标

从 Redis 零基础到能独立设计缓存方案、排行榜、限流器、分布式锁等高频后端场景。

👥 适合谁

有 1 年以上 JS/TS 经验的前端工程师，想掌握服务端缓存与高性能存储。

⏱️ 学习时长

认真学完约需 2-3 周，每天 1-2 小时。完成所有练习和实战任务是关键。

📍 课程地图（20 节）

阶段	内容	关键产出
总览（2节）	课程地图、安装与 CLI	Redis 环境就绪，能执行基本命令
数据结构（5节）	String / Hash / List / Set / Sorted Set	掌握 5 大数据结构的 CRUD
典型场景（5节）	缓存设计 / Session / 限流 / 排行榜 / 分布式锁	能用 Redis 解决常见业务问题
线上问题（4节）	雪崩穿透击穿 / 热点 Key / 持久化 / 内存与过期	具备 Redis 生产排障能力
实战（4节）	缓存+MySQL / 验证码限流 / 排行榜实战 / 命令速查	完整落地项目经验

🔑 前端工程师学 Redis 的核心优势

已有优势：缓存思维

你已经在用 localStorage、memo、SWR/React Query 做前端缓存，Redis 只是把缓存搬到了服务端。

已有优势：JSON 数据结构

你每天和 Object、Array、Map、Set 打交道，Redis 的 Hash、List、Set 几乎是一一对应。

已有优势：键值对概念

localStorage.setItem(key, value) 和 Redis 的 SET key value 本质一样。

需要适应：分布式思维

前端缓存是单用户的，Redis 是共享的。并发、一致性、过期策略是新挑战。

💡 学习建议：每学一个 Redis 命令，先想"这在前端怎么做？"。localStorage.setItem → SET，Map.get → HGET，几乎都有对应。

返回总入口

🔄 前端存储 vs Redis 对比

对比项	前端存储	Redis
存储位置	浏览器本地	服务端内存
速度	快（本地磁盘/内存）	极快（纯内存，10万+ QPS）
数据结构	只能存字符串	String/Hash/List/Set/ZSet 等
过期策略	无内置（需手动实现）	原生 TTL 支持
共享范围	单浏览器单域名	所有服务端进程共享
容量	约 5-10 MB	数十 GB（受服务器内存限制）
调试工具	DevTools → Application	`redis-cli`

🚀 安装步骤

# macOS（推荐 Homebrew） brew install redis brew services start redis # 后台启动 # Linux（Ubuntu/Debian） sudo apt update && sudo apt install redis-server sudo systemctl start redis-server # Docker（跨平台推荐） docker run -d --name redis -p 6379:6379 redis:7-alpine # 验证安装 redis-cli PING # 返回 PONG 即成功

🖥️ redis-cli 基础操作

# 进入交互模式（类似浏览器 Console） redis-cli # 基础键值操作 —— 类比 localStorage SET name "Alice" # localStorage.setItem("name", "Alice") GET name # localStorage.getItem("name") → "Alice" DEL name # localStorage.removeItem("name") EXISTS name # name in localStorage（0 或 1） # 设置过期时间（前端没有的能力！） SET token "abc123" EX 3600 # 1小时后自动删除 TTL token # 查看剩余秒数 # 查看所有 Key（生产环境慎用！） KEYS * # 类比 Object.keys(localStorage) DBSIZE # 当前数据库 Key 总数

📊 redis-cli 实用技巧

# 不进入交互模式，直接执行命令 redis-cli SET greeting "Hello" redis-cli GET greeting # 查看 Key 的类型 TYPE name # 返回 string / hash / list / set / zset # 监控实时命令（调试利器） redis-cli MONITOR # 实时显示所有执行的命令 # 查看 Redis 服务信息 INFO server # 版本、端口、运行时间 INFO memory # 内存使用情况

⚠️ 生产安全提醒：① 永远不要在生产环境执行 KEYS *（会阻塞服务），用 SCAN 替代 ② FLUSHDB / FLUSHALL 会清空所有数据 ③ 默认 Redis 无密码，部署前必须配置 requirepass

📋 速查：CLI 常用命令

▼

操作	Redis 命令	前端类比
写入	`SET key value`	`localStorage.setItem`
读取	`GET key`	`localStorage.getItem`
删除	`DEL key`	`localStorage.removeItem`
判断存在	`EXISTS key`	`key in localStorage`
设置过期	`EXPIRE key seconds`	无原生支持
查看类型	`TYPE key`	`typeof value`

✏️ 填空：CLI 基础命令

写入键值对： name "Alice" 读取值： name 设置 60 秒过期：SET token "abc" 60

🧠 小测验：Redis 基础

以下哪个说法是正确的？

Redis 数据默认存在磁盘上 redis-cli PING 返回 OK Redis 原生支持 TTL 过期，前端 localStorage 不支持 KEYS * 是生产环境推荐的查询方式

🔄 前端存储 vs Redis String 对比

能力	localStorage (JS)	Redis String
存储类型	只能存字符串	字符串、数字、二进制、JSON
最大容量	约 5MB（整个域名）	单个 Key 最大 512MB
原子计数	需手动 get→parse→+1→set	`INCR` 一条命令搞定
过期时间	不支持	`EX / PX / EXAT`
条件写入	不支持	`SET key val NX`
批量操作	需循环	`MSET / MGET`

📌 核心命令

# ===== 基础读写 ===== SET user:1:name "Alice" # 写入 GET user:1:name # → "Alice" DEL user:1:name # 删除 # ===== 带过期的写入（缓存核心！） ===== SET cache:home "<html>..." EX 300 # 缓存 5 分钟 SETEX session:xyz 1800 "user:1" # 30 分钟 # ===== 条件写入（分布式锁基础） ===== SET lock:order "holder1" NX EX 10 # 不存在才写 # ===== 批量操作 ===== MSET k1 "v1" k2 "v2" k3 "v3" MGET k1 k2 k3 # → ["v1", "v2", "v3"]

🔢 数字操作（计数器场景）

SET page:views 0 INCR page:views # 1（原子 +1，并发安全！） INCRBY page:views 10 # 11 DECR page:views # 10 DECRBY page:views 5 # 5 # Redis INCR 是原子操作，1000 并发也不丢数 # 前端 localStorage 手动 +1 是并发不安全的 SET price 9.99 INCRBYFLOAT price 0.01 # "10.00"

💡 Key 命名规范：用冒号分隔命名空间：业务:对象:ID:字段，如 user:1:name、cache:api:/users。

📋 速查：String 命令

▼

命令	说明	复杂度
`SET / GET / DEL`	写/读/删	O(1)
`MSET / MGET`	批量读写	O(N)
`INCR / DECR`	原子 ±1	O(1)
`INCRBY / DECRBY`	原子 ±N	O(1)
`SETEX key sec val`	写入+过期	O(1)
`SETNX key val`	不存在才写	O(1)

✏️ 填空：String 命令

原子递增： page:views 批量读取： k1 k2 k3 不存在才写：SET lock

🧠 小测验：String 类型

关于 INCR 命令，哪个说法正确？

INCR 并发不安全 INCR 只能对整数操作，浮点数用 INCRBYFLOAT INCR 对不存在的 Key 会报错 INCR 和前端手动 +1 完全一样

🔄 JS Object vs Redis Hash

操作	JavaScript Object	Redis Hash
设置字段	`obj.name = "Alice"`	`HSET user:1 name "Alice"`
读取字段	`obj.name`	`HGET user:1 name`
读取全部	`Object.entries(obj)`	`HGETALL user:1`
删除字段	`delete obj.name`	`HDEL user:1 name`
判断存在	`"name" in obj`	`HEXISTS user:1 name`
字段递增	手动 +1	`HINCRBY user:1 age 1`

📌 核心命令

# ===== 写入（类比 JS Object） ===== HSET user:1 name "Alice" age "28" city "Beijing" # ===== 读取 ===== HGET user:1 name # → "Alice" HMGET user:1 name age # → ["Alice", "28"] HGETALL user:1 # → 全部字段和值 # ===== 修改 & 删除 ===== HSET user:1 city "Shanghai" # 更新 HINCRBY user:1 age 1 # 原子 +1 HDEL user:1 city # 删除字段 HEXISTS user:1 name # → 1 HLEN user:1 # → 2

💡 Hash vs String 存对象

# 方案 A：多个 String（3 个 Key，3 次请求） SET user:1:name "Alice" SET user:1:age "28" # 方案 B：Hash（1 个 Key，1 次请求）✅ 推荐 HSET user:1 name "Alice" age "28" city "Beijing" # 方案 C：String 存 JSON（更新单字段需全量读写） SET user:1 '{"name":"Alice","age":28}'

⚠️ 注意：① Hash 字段值只能是字符串 ② HGETALL 字段多时慢，优先 HMGET ③ 不能对单个字段设过期

📋 速查：Hash 命令

▼

命令	说明	JS 类比
`HSET key f v`	设置字段	`obj[f]=v`
`HGET key f`	读字段	`obj[f]`
`HGETALL key`	读全部	`Object.entries`
`HDEL key f`	删字段	`delete obj[f]`
`HINCRBY key f n`	字段 ±N	`obj[f]+=n`

✏️ 填空：Hash 命令

设置字段： user:1 name "Alice" 读取全部： user:1 字段加 1： user:1 age 1

🧠 小测验：Hash

存用户信息哪种方案最优？

每字段一个 String Key Hash 存储（HSET user:1 name "Alice"） JSON.stringify 存 String 三种完全等价

🔄 JS Array vs Redis List

操作	JS Array	Redis List
右端追加	`arr.push()`	`RPUSH key val`
左端追加	`arr.unshift()`	`LPUSH key val`
右端弹出	`arr.pop()`	`RPOP key`
左端弹出	`arr.shift()`	`LPOP key`
切片	`arr.slice(0,9)`	`LRANGE key 0 9`
长度	`arr.length`	`LLEN key`
阻塞弹出	不支持	`BLPOP key timeout`

📌 核心命令

# ===== 队列 FIFO：RPUSH + LPOP ===== RPUSH queue:tasks "task1" "task2" "task3" LPOP queue:tasks # → "task1" # ===== 栈 LIFO：LPUSH + LPOP ===== LPUSH stack:undo "a1" "a2" "a3" LPOP stack:undo # → "a3" # ===== 最新动态列表 ===== LPUSH feed:user1 "发布文章A" LPUSH feed:user1 "点赞文章B" LRANGE feed:user1 0 9 # 最新 10 条 LTRIM feed:user1 0 99 # 只保留 100 条

🔒 阻塞队列

# BLPOP：没有数据时阻塞等待（最多 30 秒） BLPOP queue:orders 30 # → 有数据立刻返回，超时返回 nil # 另一个客户端生产数据 RPUSH queue:orders '{"orderId":"1001"}'

💡 LTRIM 控长度：LPUSH 后接 LTRIM 实现"只保留最新 N 条"，适合浏览记录、通知列表。

⚠️ 性能：LINDEX 是 O(N)，只有两端操作是 O(1)。需要随机访问请用 Sorted Set。

📋 速查：List 命令

▼

命令	说明	复杂度
`LPUSH/RPUSH`	左/右入	O(1)
`LPOP/RPOP`	左/右出	O(1)
`LRANGE key s e`	区间读	O(N)
`LLEN key`	长度	O(1)
`LTRIM key s e`	裁剪	O(N)
`BLPOP key t`	阻塞出	O(1)

✏️ 填空：List 命令

右端入队： queue "task1" 左端弹出： queue 前 10 条： feed 0 9

🧠 小测验：List

实现 FIFO 队列应组合？

LPUSH + LPOP RPUSH + LPOP RPUSH + RPOP LPUSH + RPUSH

🔄 JS Set vs Redis Set

操作	JS Set	Redis Set
添加	`set.add(v)`	`SADD key v`
删除	`set.delete(v)`	`SREM key v`
包含	`set.has(v)`	`SISMEMBER key v`
全部	`[...set]`	`SMEMBERS key`
数量	`set.size`	`SCARD key`
交集	手动 filter	`SINTER k1 k2`
并集	手动 spread	`SUNION k1 k2`
差集	手动 filter	`SDIFF k1 k2`

📌 核心命令

# ===== 基础操作 ===== SADD tags:article:1 "redis" "cache" "backend" SISMEMBER tags:article:1 "redis" # → 1 SMEMBERS tags:article:1 # → 全部 SCARD tags:article:1 # → 3 SREM tags:article:1 "backend" # 删除 # ===== 集合运算（共同好友） ===== SADD friends:alice "bob" "charlie" "david" SADD friends:bob "alice" "charlie" "eve" SINTER friends:alice friends:bob # → ["charlie"] SUNION friends:alice friends:bob # → 全部合并 SDIFF friends:alice friends:bob # → ["bob","david"]

💡 实战：点赞 + 抽奖

# 点赞 SADD likes:post:100 "user:1" "user:2" "user:3" SREM likes:post:100 "user:2" # 取消点赞 SISMEMBER likes:post:100 "user:1" # 是否点赞 SCARD likes:post:100 # 点赞数 # 抽奖 SRANDMEMBER likes:post:100 1 # 随机 1 人（不移除） SPOP likes:post:100 # 随机弹出（移除）

💡 去重统计：SADD uv:2024-01-01 "user:1"，SCARD 即日 UV。

📋 速查：Set 命令

▼

命令	说明	复杂度
`SADD/SREM`	增/删	O(1)
`SISMEMBER`	判断	O(1)
`SCARD`	数量	O(1)
`SINTER/SUNION/SDIFF`	集合运算	O(N*M)
`SRANDMEMBER`	随机取	O(N)

✏️ 填空：Set 命令

添加元素： tags "redis" 判断存在： tags "redis" 求交集： s1 s2

🧠 小测验：Set

SINTER 返回什么？

合并所有元素两个集合的共同元素第一个有第二个没有的元素总数

🔄 前端排序 vs Redis ZSet

操作	前端实现	Redis Sorted Set
添加带分数	`arr.push({k,v}); arr.sort()`	`ZADD key score member`
查排名	`arr.findIndex()`	`ZRANK key member`
查分数	`map.get(k)`	`ZSCORE key member`
Top N	`arr.sort().slice(0,N)`	`ZREVRANGE key 0 N-1`
范围查询	`arr.filter()`	`ZRANGEBYSCORE key min max`
加分	find→update→sort	`ZINCRBY key delta member`

📌 核心命令

# ===== 添加成员（分数+成员） ===== ZADD leaderboard 100 "alice" 85 "bob" 92 "charlie" # ===== 查询 ===== ZSCORE leaderboard "alice" # → "100" ZRANK leaderboard "bob" # → 0（从低到高排名） ZREVRANK leaderboard "alice" # → 0（从高到低排名） # ===== 排行榜（从高到低） ===== ZREVRANGE leaderboard 0 2 WITHSCORES # → ["alice","100","charlie","92","bob","85"] # ===== 加分 ===== ZINCRBY leaderboard 20 "bob" # bob: 85→105 ZREVRANGE leaderboard 0 0 # → ["bob"]（bob 变第一） # ===== 按分数范围查 ===== ZRANGEBYSCORE leaderboard 80 100 # 分数在 80-100 的 ZCOUNT leaderboard 80 100 # 数量 # ===== 删除 ===== ZREM leaderboard "charlie" ZCARD leaderboard # 成员总数

💡 实战：游戏排行榜

# 玩家得分更新（每次加分自动重新排序） ZINCRBY game:rank 50 "player:1001" ZINCRBY game:rank 30 "player:1002" ZINCRBY game:rank 80 "player:1003" # Top 10 排行榜 ZREVRANGE game:rank 0 9 WITHSCORES # 查我的排名（从 0 开始，+1 得到名次） ZREVRANK game:rank "player:1001" # → 1（第 2 名） # 我周围的人（前后各 2 名） # 先查排名，再 ZREVRANGE rank-2 rank+2

⚠️ 注意：① ZRANK 从低到高，ZREVRANK 从高到低 ② 分数相同时按成员字典序排列 ③ 从 Redis 6.2 起，部分旧命令可用 ZRANGE ... REV 等新写法替代；不同版本请以官方文档为准

📋 速查：Sorted Set 命令

▼

命令	说明	复杂度
`ZADD key score m`	添加	O(logN)
`ZSCORE key m`	查分数	O(1)
`ZRANK/ZREVRANK`	查排名	O(logN)
`ZREVRANGE key s e`	Top N	O(logN+M)
`ZINCRBY key d m`	加分	O(logN)
`ZCARD key`	总数	O(1)

✏️ 填空：Sorted Set

添加： rank 100 "alice" Top 3（高→低）： rank 0 2 加分： rank 10 "alice"

🧠 小测验：Sorted Set

ZREVRANK 返回的排名方向是？

从低到高从高到低（第一名是 0）按插入顺序按字母序

🔄 前端缓存 vs Redis 缓存

维度	前端缓存	Redis 缓存
工具	React Query / SWR	Redis + 应用代码
位置	浏览器内存	服务端内存
过期	staleTime	TTL（EX / PX）
更新	invalidate	旁路更新 / 删除
共享	单用户	所有用户所有请求

📌 Cache-Aside 旁路缓存

# 读流程： # 1. 先查 Redis GET cache:user:1 # 命中 → 返回 | 未命中 ↓ # 2. 查数据库 → SELECT * FROM users WHERE id = 1 # 3. 回填 Redis SET cache:user:1 '{"name":"Alice"}' EX 3600 # 写流程： # 1. 更新 DB → 2. 删缓存（非更新！） DEL cache:user:1

🔑 缓存更新策略

# Cache-Aside ✅ 推荐：先 DB → 删缓存 # Write-Through：同步双写（一致性好但慢） # Write-Behind：先 Redis，异步 DB（快但可能丢） # Refresh-Ahead：快过期时刷新（类似 SWR）

💡 删缓存 vs 更新缓存？并发时更新缓存可能写入旧值，删除更安全。

⚠️ 删缓存失败？① 消息队列重试 ② 短 TTL 兜底 ③ Canal 订阅 binlog

📋 速查：缓存模式

▼

模式	读	写	适用
Cache-Aside	先缓存后DB	先DB后删缓存	通用
Write-Through	从缓存读	同步双写	强一致
Write-Behind	从缓存读	异步回写	高写入

✏️ 填空：缓存模式

读：先查，miss 查 DB，回填写：先更新，再缓存

🧠 小测验：缓存设计

Cache-Aside 数据更新时应该？

先删缓存再更新 DB 先更新 DB 再删缓存只更新缓存同时更新两者

🔄 前端登录态 vs Redis Session

维度	前端方案	Redis Session
存储	Cookie / sessionStorage	Redis 服务端
安全	客户端可篡改	服务端控制
容量	Cookie 4KB	无限制
多服务器	无关	共享
强制下线	需前端配合	DEL 即可

📌 Redis Session 实现

# 1. 登录 → 创建 Session HSET sess:abc123 userId "1001" username "alice" role "admin" EXPIRE sess:abc123 1800 # 30 分钟 # 2. 请求验证 HGETALL sess:abc123 EXPIRE sess:abc123 1800 # 续期 # 3. 登出 / 强制下线 DEL sess:abc123

💡 Hash vs String 存 Session

# String：需反序列化整个 JSON SET sess:abc '{"userId":"1001","role":"admin"}' # Hash（推荐）：可单独读写字段 HSET sess:abc userId "1001" role "admin" HGET sess:abc role # 只读 role

💡 续期：每次请求 EXPIRE 刷新 TTL，活跃用户不过期。

⚠️ 安全：① sessionId 用 UUID v4 ② HTTPS Only Cookie ③ 合理 TTL

📋 速查：Session 命令

▼

操作	命令
创建	`HSET sess:id f v + EXPIRE`
读取	`HGETALL sess:id`
续期	`EXPIRE sess:id 1800`
登出	`DEL sess:id`

✏️ 填空：Session

创建： sess:abc userId "1001" 过期： sess:abc 1800 登出： sess:abc

🧠 小测验：Session

Redis Session 最大优势？

速度更快多服务器共享，支持分布式不需要 Cookie 永不过期

🔄 前端节流 vs 服务端限流

维度	前端 throttle	Redis 限流
位置	浏览器	服务端
可靠性	用户可绕过	无法绕过
粒度	按函数调用	按用户/IP/接口
策略	固定间隔	固定窗口/滑动窗口/令牌桶
存储	闭包变量	Redis Key + TTL

📌 固定窗口限流

# 限制：每个 IP 每分钟最多 60 次请求 # Key 格式：rate:IP:当前分钟 INCR rate:192.168.1.1:202401011030 # 第一次调用自动创建 Key，值为 1 EXPIRE rate:192.168.1.1:202401011030 60 # 设置 60 秒过期 # 判断是否超限 GET rate:192.168.1.1:202401011030 # 值 > 60 → 返回 429 Too Many Requests

📌 滑动窗口限流（更精确）

# 用 Sorted Set 实现滑动窗口 # Key：rate:userId Score：时间戳 Member：请求ID # 1. 记录请求 ZADD rate:user:1001 1704067200 "req:uuid1" # 2. 移除窗口外的旧请求（60秒前） ZREMRANGEBYSCORE rate:user:1001 0 1704067140 # 3. 统计窗口内请求数 ZCARD rate:user:1001 # > 60 → 拒绝 # 4. 设置 Key 过期（兜底清理） EXPIRE rate:user:1001 61

💡 Lua 脚本保原子性：生产环境应将 INCR+EXPIRE 或 ZADD+ZREMRANGEBYSCORE+ZCARD 封装到 Lua 脚本中，确保原子执行。

⚠️ 固定窗口的问题：窗口边界时刻可能出现双倍流量（前一窗口末尾 + 后一窗口开头），滑动窗口可以解决。

📋 速查：限流方案

▼

方案	数据结构	精度	复杂度
固定窗口	String INCR	低	简单
滑动窗口	Sorted Set	高	中等
令牌桶	Lua 脚本	高	复杂

✏️ 填空：限流命令

固定窗口计数： rate:ip:key 设过期： rate:ip:key 60 滑动窗口删旧： rate:user 0 oldTs

🧠 小测验：限流

固定窗口限流的缺点是什么？

实现太复杂窗口边界可能出现双倍流量不支持 Redis 无法设置过期

🔄 前端排行榜 vs Redis 排行榜

需求	前端实现	Redis ZSet
更新分数	find→update→sort	`ZINCRBY rank 10 "user"`
Top 10	sort→slice(0,10)	`ZREVRANGE rank 0 9`
我的排名	findIndex	`ZREVRANK rank "user"`
总人数	arr.length	`ZCARD rank`
并发安全	不安全	原子操作

📌 完整排行榜实现

# ===== 1. 更新分数 ===== ZINCRBY game:rank 50 "player:1001" ZINCRBY game:rank 30 "player:1002" ZINCRBY game:rank 80 "player:1003" ZINCRBY game:rank 65 "player:1004" # ===== 2. 获取 Top 3 ===== ZREVRANGE game:rank 0 2 WITHSCORES # → ["player:1003","80","player:1004","65","player:1001","50"] # ===== 3. 查我的排名 ===== ZREVRANK game:rank "player:1001" # → 2（第 3 名，0 开始） ZSCORE game:rank "player:1001" # → "50" # ===== 4. 周排行榜（用 Key 区分） ===== ZINCRBY rank:week:2024-01 50 "player:1001" EXPIRE rank:week:2024-01 604800 # 7 天过期

💡 多维度排行榜

# 日榜 / 周榜 / 月榜 / 总榜 ZINCRBY rank:daily:20240101 10 "user:1" ZINCRBY rank:weekly:2024W01 10 "user:1" ZINCRBY rank:monthly:202401 10 "user:1" ZINCRBY rank:all 10 "user:1" # 合并多日榜为周榜 ZUNIONSTORE rank:weekly:2024W01 7 rank:daily:20240101 rank:daily:20240102 ... # 分数相同时如何排序？ # Redis 默认按字典序，可用复合分数：score = 主分数 * 10^10 + (MAX_TS - 时间戳)

💡 ZUNIONSTORE：可以将多个 ZSet 合并，非常适合"合并日榜为周榜"这类需求。

⚠️ 性能：百万级成员的 ZREVRANGE 0 9 仍然是 O(logN+M)，性能极好。但 ZRANGEBYSCORE 范围太大时要注意。

📋 速查：排行榜命令

▼

需求	命令
加分	`ZINCRBY rank delta member`
Top N	`ZREVRANGE rank 0 N-1 WITHSCORES`
我的排名	`ZREVRANK rank member`
我的分数	`ZSCORE rank member`
总人数	`ZCARD rank`
合并榜单	`ZUNIONSTORE dest N src1 src2`

✏️ 填空：排行榜

加 10 分： rank 10 "user:1" Top 5： rank 0 4 我的排名： rank "user:1"

🧠 小测验：排行榜

ZREVRANK 返回 0 表示什么？

不存在第一名（排名从 0 开始）最后一名分数为 0

🔄 前端互斥 vs 分布式锁

维度	前端	分布式锁
场景	按钮防重复点击	防止超卖、重复支付
实现	loading 状态 / disabled	Redis SET NX
范围	单用户单页面	所有服务器所有进程
释放	请求完成恢复按钮	DEL 或 TTL 自动释放

📌 基础分布式锁

# ===== 加锁 ===== # SET key value NX EX seconds # NX：不存在才写入（互斥） # EX：设过期（防死锁） SET lock:order:1001 "server-1-uuid" NX EX 30 # 返回 OK → 加锁成功 # 返回 nil → 已被其他人持有 # ===== 释放锁（必须验证持有者！） ===== # 错误做法：直接 DEL（可能删别人的锁） DEL lock:order:1001 # ← 危险！ # 正确做法：Lua 脚本原子判断+删除 # if redis.call("GET",KEYS[1]) == ARGV[1] then # return redis.call("DEL",KEYS[1]) # else return 0 end

⚠️ 分布式锁的陷阱

# 陷阱 1：锁过期但业务没完成 # → 解决：看门狗机制（Redisson 自动续期） # 陷阱 2：释放了别人的锁 # A 加锁 → A 处理超时 → 锁自动过期 → B 加锁 → A 完成 DEL → 删了 B 的锁！ # → 解决：value 存 UUID，删前比对 # 陷阱 3：Redis 主从切换丢锁 # A 在主节点加锁 → 主节点宕机 → 从节点提升（没有锁） → B 也加锁成功 # → 解决：Redlock 算法（多节点加锁） # 生产建议：优先使用成熟库，如 Redisson（Java）或 node-redlock（Node.js） # 是否需要 Redlock，要看你对主从切换/多节点容错的要求

💡 类比前端：分布式锁就像按钮的 loading 状态，只是作用范围从"单用户"扩展到"全系统所有进程"。

⚠️ 核心原则：① 加锁必须设过期（防死锁） ② 释放必须验证持有者（防误删） ③ 生产环境优先用成熟库，而不是手写锁逻辑

📋 速查：分布式锁

▼

操作	命令	注意
加锁	`SET key uuid NX EX 30`	NX 互斥 + EX 防死锁
释放	Lua: GET→比对→DEL	必须原子操作
续期	`EXPIRE key 30`	看门狗自动续

✏️ 填空：分布式锁

加锁：SET lock:order "uuid" 30 释放前必须验证是否是自己

🧠 小测验：分布式锁

为什么加锁时必须设置 EX 过期？

为了节省内存防止持有锁的进程崩溃导致死锁 Redis 要求必须设 EX 为了提高性能

🔄 三大问题对比

问题	场景	类比前端	核心解法
缓存雪崩	大量 Key 同时过期	CDN 节点全部失效	随机过期时间
缓存穿透	查询不存在的数据	请求不存在的 API	布隆过滤器 / 缓存空值
缓存击穿	热点 Key 过期	热门页面缓存失效	互斥锁 / 永不过期

❄️ 缓存雪崩

# 问题：大量 Key 设了相同过期时间，同时失效 → DB 被压垮 # 解法 1：随机过期时间 # 原来：SET cache:user:1 val EX 3600（都是 1 小时） # 改为：EX 3600 + random(0, 300)（加随机偏移） SET cache:user:1 "val" EX 3720 # 3600 + 120 SET cache:user:2 "val" EX 3850 # 3600 + 250 # 解法 2：多级缓存 # L1: 本地缓存（进程内，最快） # L2: Redis（共享缓存） # L3: 数据库 # 解法 3：热点数据预加载 + 永不过期

🕳️ 缓存穿透

# 问题：查 id=-1 的用户，Redis 没有，DB 也没有 # → 每次都穿透到 DB，恶意攻击可打垮 DB # 解法 1：缓存空值 GET cache:user:-1 # miss # 查 DB → 不存在 → 缓存空值 SET cache:user:-1 "NULL" EX 60 # 短过期 # 解法 2：布隆过滤器（推荐） # 把所有合法 ID 加入布隆过滤器 # 请求来时先查布隆过滤器 → 不存在则直接拒绝 # BF.ADD users_filter "1" # BF.EXISTS users_filter "-1" → 0（一定不存在） # 解法 3：参数校验 # ID 为负数直接返回空

🔥 缓存击穿

# 问题：某热点 Key 过期，大量并发同时查 DB # 解法 1：互斥锁（用分布式锁） GET cache:hot-product # miss → 加锁 SET lock:rebuild:hot-product "1" NX EX 10 # 加锁成功 → 查 DB → 回填缓存 → 释放锁 # 加锁失败 → 短暂等待 → 重试 GET # 解法 2：逻辑过期（永不过期 + 异步更新） # 缓存值：{"data":"...","expireAt":1704067200} # Key 本身不设 TTL，由应用逻辑判断是否过期 # 过期 → 开后台线程更新，当前返回旧数据

⚠️ 面试必问：三大问题的区别——雪崩是"大面积"失效，穿透是"查不存在的"，击穿是"单个热点"失效。

📋 速查：缓存问题与解法

▼

问题	解法
雪崩	随机 TTL / 多级缓存 / 预加载
穿透	布隆过滤器 / 缓存空值 / 参数校验
击穿	互斥锁 / 逻辑过期 / 永不过期

✏️ 填空：缓存问题

大量 Key 同时过期叫缓存查不存在的数据叫缓存热点 Key 过期叫缓存

🧠 小测验：缓存问题

防止缓存穿透的最佳方案是？

增加 Redis 内存布隆过滤器预先过滤非法请求加长 TTL 使用多级缓存

🔄 前端热点请求 vs Redis 热 Key

维度	前端	Redis 热 Key
场景	热门商品页疯狂刷新	明星微博、秒杀商品
问题	API 被打挂	单个 Redis 节点过载
解法	CDN / 本地缓存	本地缓存 / 读副本 / 拆 Key

📌 发现热点 Key

# 方法 1：redis-cli --hotkeys（Redis 4.0+） redis-cli --hotkeys # 方法 2：MONITOR 实时监控（短时间！） redis-cli MONITOR | head -1000 # 方法 3：业务层统计 # 在代码中对 Redis 请求计数，超阈值告警 # 方法 4：Redis 慢查询日志 SLOWLOG GET 10

📌 解决热点 Key

# 解法 1：本地缓存（L1 缓存） # 应用进程内存缓存热数据，不走 Redis # Node.js 示例： # const cache = new Map(); # if (cache.has(key)) return cache.get(key); # const val = await redis.get(key); # cache.set(key, val); setTimeout(() => cache.delete(key), 1000); # 解法 2：读副本（Redis Cluster 读写分离） # 读请求分散到多个从节点 # 解法 3：拆 Key（分片） # 原来：GET hot:product:1 # 拆成：GET hot:product:1:{random(0,9)} # 10 个 Key 分散压力，读时随机选一个

💡 类比 CDN：热点 Key 的本地缓存就像前端用 CDN 缓存静态资源，把压力分散到边缘节点。

⚠️ Big Key 也是问题：单个 Value 超过 10KB 就算 Big Key，会导致网络带宽和序列化瓶颈。用 MEMORY USAGE key 检查。

📋 速查：热 Key 处理

▼

方案	原理	适用
本地缓存	进程内 Map	读多写少
读副本	主从分离	集群环境
拆 Key	分散到多 Key	极端热点

✏️ 填空：热 Key

发现热 Key：redis-cli 拆 Key 分散压力：GET hot:product:1: 检查 Value 大小： key

🧠 小测验：热 Key

热点 Key 本地缓存类似前端的什么？

localStorage CDN 缓存 / 进程内 Map IndexedDB Service Worker

🔄 前端存储持久化 vs Redis 持久化

维度	前端	Redis
内存数据	JS 变量（刷新就丢）	Redis 数据（重启就丢）
持久化	localStorage / IndexedDB	RDB / AOF
快照	JSON.stringify 整体存	RDB（全量快照）
日志	记录每次 setState	AOF（记录每条写命令）

📸 RDB（快照）

# RDB：某个时间点的全量快照 → dump.rdb 文件 # 类比：每隔一段时间 JSON.stringify(state) 存到磁盘 # 触发方式 SAVE # 同步保存（阻塞！生产慎用） BGSAVE # 后台异步保存（推荐） # 自动触发配置（redis.conf） # save 900 1 # 900秒内至少1次写入 → 触发 BGSAVE # save 300 10 # 300秒内至少10次写入 # save 60 10000 # 60秒内至少10000次写入 # 优点：文件小、恢复快、适合备份 # 缺点：可能丢失最后一次快照后的数据

📝 AOF（追加日志）

# AOF：记录每条写命令 → appendonly.aof 文件 # 类比：记录每次 dispatch(action)，可以重放还原状态 # 开启 AOF（redis.conf） # appendonly yes # 同步策略 # appendfsync always # 每条命令都刷盘（最安全，最慢） # appendfsync everysec # 每秒刷盘（推荐，最多丢 1 秒） # appendfsync no # OS 决定（最快，可能丢数据） # AOF 重写（压缩日志） BGREWRITEAOF # 后台重写，合并冗余命令 # 优点：丢数据少（最多 1 秒） # 缺点：文件大、恢复慢

💡 推荐配置：生产环境同时开启 RDB + AOF。RDB 用于定期备份，AOF 用于数据恢复（丢失更少）。Redis 4.0+ 支持混合持久化。

⚠️ 注意：① 纯缓存场景可以不开持久化 ② SAVE 会阻塞所有请求，只用 BGSAVE ③ AOF 文件需要定期重写避免过大

📋 速查：持久化对比

▼

维度	RDB	AOF
原理	全量快照	追加写命令
文件	dump.rdb	appendonly.aof
丢数据	最后快照后的	最多 1 秒
恢复速度	快	慢
文件大小	小	大

✏️ 填空：持久化

后台保存快照：开启 AOF：appendonly 推荐同步策略：appendfsync

🧠 小测验：持久化

生产环境推荐的持久化策略？

只开 RDB 只开 AOF RDB + AOF 同时开启都不开

🔄 前端内存管理 vs Redis 内存管理

维度	前端 JS	Redis
内存回收	GC 自动回收	过期删除 + 淘汰策略
内存限制	浏览器 tab ~1-4GB	maxmemory 配置
内存泄漏	闭包/事件监听未清理	Key 无 TTL 不断累积
监控	DevTools → Memory	`INFO memory`

⏰ 过期删除策略

# Redis 不会在 Key 过期的瞬间立刻删除！ # 策略 1：惰性删除 # 访问 Key 时检查是否过期 → 过期则删除并返回 nil GET expired:key # 此时才真正删除 # 策略 2：定期删除 # Redis 每 100ms 随机抽样检查 20 个 Key # 如果超过 25% 已过期 → 继续抽样检查 # 保证不会阻塞太久 # 两种策略结合使用： # 定期删除 → 兜底清理 # 惰性删除 → 精准清理

📊 内存淘汰策略（maxmemory-policy）

# 当内存达到 maxmemory 上限时触发 # 查看当前配置 CONFIG GET maxmemory CONFIG GET maxmemory-policy # 设置内存上限 CONFIG SET maxmemory 2gb # 8 种淘汰策略： # noeviction → 不淘汰，写入报错（默认） # allkeys-lru → 所有 Key 中淘汰最近最少使用 ✅ 推荐 # allkeys-lfu → 所有 Key 中淘汰最不经常使用 # allkeys-random → 所有 Key 中随机淘汰 # volatile-lru → 有过期时间的 Key 中淘汰 LRU # volatile-lfu → 有过期时间的 Key 中淘汰 LFU # volatile-random → 有过期时间的 Key 中随机淘汰 # volatile-ttl → 有过期时间的 Key 中淘汰 TTL 最短的

🔍 内存诊断

# 查看内存使用概览 INFO memory # used_memory: 当前使用内存 # used_memory_peak: 历史最大内存 # maxmemory: 上限 # 查看单个 Key 的内存占用 MEMORY USAGE user:1 # 查看 Key 数量 DBSIZE # 查看各类型 Key 分布（抽样统计） redis-cli --bigkeys

💡 缓存场景推荐：allkeys-lru，让 Redis 自动淘汰冷数据。类比浏览器缓存满时自动清理最久没用的资源。

⚠️ 内存优化：① 大多数缓存 Key 都应设 TTL；少数永久缓存要配合明确失效策略 ② 用 Hash 代替多个 String（省内存） ③ 定期用 --bigkeys 排查大 Key

📋 速查：内存管理

▼

命令	说明
`INFO memory`	内存使用概览
`MEMORY USAGE key`	单 Key 内存
`DBSIZE`	Key 总数
`CONFIG SET maxmemory`	设内存上限
`CONFIG SET maxmemory-policy`	设淘汰策略

✏️ 填空：内存管理

查看内存：INFO 推荐淘汰策略：查 Key 内存占用： key

🧠 小测验：内存管理

缓存场景推荐哪种淘汰策略？

noeviction（不淘汰） allkeys-lru（最近最少使用） allkeys-random（随机） volatile-ttl

🔄 架构对比

层级	前端架构	后端 Redis+MySQL
L1 缓存	组件 state / useMemo	进程内 Map
L2 缓存	React Query cache	Redis
数据源	API Server	MySQL

📌 读流程（TypeScript 伪代码）

// Cache-Aside 读流程 async function getUser(userId: string) { const cacheKey = `cache:user:${userId}`; // 1. 先查 Redis const cached = await redis.get(cacheKey); if (cached) { return JSON.parse(cached); // 命中缓存 } // 2. 未命中 → 查 MySQL const user = await db.query('SELECT * FROM users WHERE id = ?', [userId]); if (!user) return null; // 3. 回填 Redis（设 TTL） await redis.set(cacheKey, JSON.stringify(user), 'EX', 3600); return user; }

📌 写流程

// Cache-Aside 写流程 async function updateUser(userId: string, data: Partial<User>) { // 1. 先更新 MySQL await db.query('UPDATE users SET ? WHERE id = ?', [data, userId]); // 2. 再删除缓存（而非更新！） await redis.del(`cache:user:${userId}`); // 下次读取时自动回填最新数据 } // 批量更新时删除相关缓存 async function updateUserBatch(userIds: string[]) { // ... 批量更新 DB const keys = userIds.map(id => `cache:user:${id}`); await redis.del(...keys); // 批量删除缓存 }

💡 Redis 命令对应：代码中的 redis.get/set/del 对应 CLI 的 GET/SET/DEL，参数一一对应。

⚠️ 注意：① 删缓存失败要有重试机制 ② JSON 序列化有性能开销，大对象考虑 Hash ③ 设合理 TTL 作为兜底

📋 速查：Cache-Aside 要点

▼

步骤	操作	Redis 命令
读-1	查缓存	`GET cache:user:id`
读-2	查 DB	SQL SELECT
读-3	回填	`SET cache:user:id val EX 3600`
写-1	更新 DB	SQL UPDATE
写-2	删缓存	`DEL cache:user:id`

✏️ 填空：Cache-Aside

读：先 cache:user:1 未命中查 DB 后： cache:user:1 data 3600

🧠 小测验：缓存+MySQL

写操作时为什么删缓存而不是更新缓存？

删除更快并发下更新缓存可能写入旧值 Redis 不支持更新节省内存

🔄 前端验证 vs 服务端验证

维度	前端验证	Redis 服务端验证
发送频率	按钮 disabled 60s	Redis INCR + TTL
存储验证码	不存（安全隐患）	Redis SET EX
验证次数	无法限制	Redis DECR
可靠性	用户可绕过	无法绕过

📌 完整实现（Redis 命令流）

# ===== 1. 发送验证码（频率限制） ===== # 检查 60 秒内是否已发送 EXISTS sms:lock:13800138000 # → 1 → 拒绝："请 60 秒后再试" # → 0 → 继续 # 发送锁（60 秒内不能重发） SET sms:lock:13800138000 "1" EX 60 # 每日发送上限 INCR sms:daily:13800138000 EXPIRE sms:daily:13800138000 86400 # 一天过期 # 值 > 10 → 拒绝："今日发送次数已达上限" # ===== 2. 存储验证码 ===== SET sms:code:13800138000 "826451" EX 300 # 5 分钟有效 SET sms:retry:13800138000 "3" EX 300 # 最多验证 3 次

📌 验证流程

# ===== 3. 用户提交验证码 ===== # 检查剩余次数 GET sms:retry:13800138000 # → "0" → 拒绝："验证次数已用完" # → > 0 → 继续 # 读取正确验证码 GET sms:code:13800138000 # → nil → "验证码已过期" # → "826451" → 比对用户输入 # 比对成功 → 清理 DEL sms:code:13800138000 DEL sms:retry:13800138000 # 比对失败 → 扣次数 DECR sms:retry:13800138000

💡 TypeScript 实现

async function sendSmsCode(phone: string) { // 频率限制 if (await redis.exists(`sms:lock:${phone}`)) { throw new Error('请 60 秒后再试'); } const daily = await redis.incr(`sms:daily:${phone}`); await redis.expire(`sms:daily:${phone}`, 86400); if (daily > 10) throw new Error('今日次数已达上限'); const code = Math.random().toString().slice(-6); await redis.set(`sms:code:${phone}`, code, 'EX', 300); await redis.set(`sms:retry:${phone}`, '3', 'EX', 300); await redis.set(`sms:lock:${phone}`, '1', 'EX', 60); // ... 调用短信 API 发送 code }

💡 Key 命名：sms:lock（发送锁）、sms:code（验证码）、sms:retry（重试次数）、sms:daily（日限额）——命名清晰是运维的第一步。

⚠️ 安全：① 验证码不要返回给前端 ② 用 Lua 脚本保证原子性 ③ 日限额防止短信轰炸

📋 速查：验证码相关 Key

▼

Key	用途	TTL
`sms:lock:phone`	发送频率锁	60s
`sms:code:phone`	验证码	300s
`sms:retry:phone`	剩余次数	300s
`sms:daily:phone`	日发送数	86400s

✏️ 填空：验证码限流

存验证码 5 分钟： sms:code:phone "826451" EX 验证失败扣次数： sms:retry:phone

🧠 小测验：验证码限流

sms:lock:phone 的作用是？

存储验证码限制 60 秒内不能重复发送限制验证次数统计日发送量

🔄 前端排序实现 vs Redis ZSet

功能	前端实现	Redis ZSet
性能	O(NlogN) 每次排序	O(logN) 插入自动有序
并发	不安全	ZINCRBY 原子操作
百万级	浏览器容易卡顿	通常仍能保持较低延迟（取决于命令范围和数据分布）
持久化	刷新就丢	服务端持久存储

📌 完整排行榜 API（Redis 命令）

# ===== 1. 更新积分 ===== ZINCRBY rank:game:2024 100 "player:alice" ZINCRBY rank:game:2024 85 "player:bob" ZINCRBY rank:game:2024 92 "player:charlie" # ===== 2. 获取 Top 10（带分数） ===== ZREVRANGE rank:game:2024 0 9 WITHSCORES # ===== 3. 我的排名和分数 ===== ZREVRANK rank:game:2024 "player:alice" # → 0（第 1 名） ZSCORE rank:game:2024 "player:alice" # → "100" # ===== 4. 排名附近的人（前后各 2 名） ===== # 先查排名 ZREVRANK rank:game:2024 "player:bob" # → 2 # 再取范围 [2-2, 2+2] = [0, 4] ZREVRANGE rank:game:2024 0 4 WITHSCORES # ===== 5. 总参与人数 ===== ZCARD rank:game:2024

📌 多维度排行榜

# 日榜 ZINCRBY rank:daily:20240101 100 "player:alice" EXPIRE rank:daily:20240101 172800 # 2 天后清理 # 周榜（合并 7 个日榜） ZUNIONSTORE rank:weekly:2024W01 7 \ rank:daily:20240101 rank:daily:20240102 \ rank:daily:20240103 rank:daily:20240104 \ rank:daily:20240105 rank:daily:20240106 \ rank:daily:20240107 EXPIRE rank:weekly:2024W01 604800 # 分数相同按时间排序（先达到的排前面） # 复合分数 = score * 10^13 + (MAX_TS - timestamp) # ZADD rank 100_9999999999999 "alice"

💡 TypeScript API 实现

class LeaderboardService { private key = 'rank:game:2024'; async addScore(player: string, score: number) { return redis.zincrby(this.key, score, player); } async getTopN(n: number) { return redis.zrevrange(this.key, 0, n - 1, 'WITHSCORES'); } async getMyRank(player: string) { const rank = await redis.zrevrank(this.key, player); const score = await redis.zscore(this.key, player); return { rank: rank !== null ? rank + 1 : null, score }; } async getNearby(player: string, range = 2) { const rank = await redis.zrevrank(this.key, player); if (rank === null) return []; const start = Math.max(0, rank - range); return redis.zrevrange(this.key, start, rank + range, 'WITHSCORES'); } }

💡 ZUNIONSTORE：可以将多个日榜合并成周榜/月榜，还支持 WEIGHTS 参数设置权重。

⚠️ 注意：① ZREVRANK 从 0 开始，展示给用户要 +1 ② 排行榜数据要设 EXPIRE 防止无限增长 ③ 百万级数据的 ZREVRANGE 0 9 性能仍然很好

📋 速查：排行榜 API

▼

功能	Redis 命令
加分	`ZINCRBY rank score player`
Top N	`ZREVRANGE rank 0 N-1 WITHSCORES`
我的排名	`ZREVRANK rank player`
我的分数	`ZSCORE rank player`
合并榜单	`ZUNIONSTORE dest N src1 src2`
总人数	`ZCARD rank`

✏️ 填空：排行榜实战

加分： rank 50 "alice" Top 10：ZREVRANGE rank WITHSCORES

🧠 小测验：排行榜实战

ZUNIONSTORE 的作用？

求两个集合的交集合并多个 ZSet，相同成员分数相加删除 ZSet 中的成员随机取 ZSet 成员

🔤 String 命令

命令	说明	示例	前端类比
`SET key val`	写入	`SET name "Alice"`	`localStorage.setItem`
`GET key`	读取	`GET name`	`localStorage.getItem`
`DEL key`	删除	`DEL name`	`localStorage.removeItem`
`SET k v EX s`	写入+过期	`SET token "x" EX 3600`	无原生支持
`INCR key`	原子 +1	`INCR views`	无原子操作
`MSET / MGET`	批量读写	`MSET k1 v1 k2 v2`	循环 setItem
`SET k v NX`	不存在才写	`SET lock "1" NX EX 30`	不支持

🗂️ Hash 命令

命令	说明	示例	前端类比
`HSET key f v`	设置字段	`HSET user:1 name "Alice"`	`obj.name = "Alice"`
`HGET key f`	读取字段	`HGET user:1 name`	`obj.name`
`HGETALL key`	全部字段	`HGETALL user:1`	`Object.entries(obj)`
`HDEL key f`	删除字段	`HDEL user:1 name`	`delete obj.name`
`HINCRBY key f n`	字段递增	`HINCRBY user:1 age 1`	`obj.age += 1`

📋 List 命令

命令	说明	示例	前端类比
`RPUSH key val`	右端入	`RPUSH queue "task"`	`arr.push()`
`LPUSH key val`	左端入	`LPUSH stack "item"`	`arr.unshift()`
`LPOP / RPOP`	弹出	`LPOP queue`	`arr.shift()`
`LRANGE key s e`	区间读	`LRANGE feed 0 9`	`arr.slice(0,10)`
`LLEN key`	长度	`LLEN queue`	`arr.length`

🔵 Set 命令

命令	说明	示例	前端类比
`SADD key val`	添加	`SADD tags "redis"`	`set.add()`
`SISMEMBER key v`	判断	`SISMEMBER tags "redis"`	`set.has()`
`SMEMBERS key`	全部	`SMEMBERS tags`	`[...set]`
`SINTER k1 k2`	交集	`SINTER friends:a friends:b`	手动 filter
`SCARD key`	数量	`SCARD tags`	`set.size`

🏆 Sorted Set 命令

命令	说明	示例
`ZADD key score m`	添加	`ZADD rank 100 "alice"`
`ZINCRBY key d m`	加分	`ZINCRBY rank 10 "alice"`
`ZREVRANGE key s e`	Top N	`ZREVRANGE rank 0 9 WITHSCORES`
`ZREVRANK key m`	排名	`ZREVRANK rank "alice"`
`ZSCORE key m`	分数	`ZSCORE rank "alice"`
`ZCARD key`	总数	`ZCARD rank`

⚙️ 通用命令

命令	说明	示例
`EXPIRE key s`	设过期	`EXPIRE sess:abc 1800`
`TTL key`	剩余秒数	`TTL sess:abc`
`EXISTS key`	是否存在	`EXISTS user:1`
`TYPE key`	类型	`TYPE user:1`
`SCAN cursor`	遍历 Key	`SCAN 0 MATCH user:*`
`INFO section`	服务器信息	`INFO memory`
`MEMORY USAGE key`	Key 内存	`MEMORY USAGE user:1`

🎯 场景速查

场景	数据结构	核心命令
缓存	String	`SET k v EX ttl / GET / DEL`
Session	Hash	`HSET / HGETALL / EXPIRE / DEL`
计数器	String	`INCR / INCRBY / DECR`
限流	String/ZSet	`INCR+EXPIRE / ZADD+ZCARD`
排行榜	Sorted Set	`ZINCRBY / ZREVRANGE / ZREVRANK`
分布式锁	String	`SET k v NX EX + Lua DEL`
消息队列	List	`RPUSH / BLPOP`
标签/去重	Set	`SADD / SISMEMBER / SINTER`
点赞	Set	`SADD / SREM / SCARD`
最近动态	List	`LPUSH / LRANGE / LTRIM`

💡 恭喜完成所有课程！你已经掌握了 Redis 的 5 大数据结构、5 大典型场景、4 大线上问题和 4 个完整实战项目。下一步建议：在真实项目中实践，遇到问题回来查这个速查表。

✏️ 终极填空：场景选型

排行榜用数据结构 Session 用数据结构分布式锁用 SET key val EX

🧠 终极测验：场景选型

实现"共同好友"功能应该用哪个数据结构？

String Hash Set（SINTER 求交集） List

📝 进入考试 → 返回总入口

从前端缓存思维到 Redis 高性能存储的完整路线图

🎯 课程目标

👥 适合谁

⏱️ 学习时长

📍 课程地图（20 节）

🔑 前端工程师学 Redis 的核心优势

已有优势：缓存思维

已有优势：JSON 数据结构

已有优势：键值对概念

需要适应：分布式思维

安装 Redis 并掌握 CLI：像浏览器 DevTools 一样调试缓存

🔄 前端存储 vs Redis 对比

🚀 安装步骤

🖥️ redis-cli 基础操作

📊 redis-cli 实用技巧

📋 速查：CLI 常用命令

String：Redis 最基础的类型，远比 localStorage 强大

🔄 前端存储 vs Redis String 对比

📌 核心命令

🔢 数字操作（计数器场景）

📋 速查：String 命令

Hash：Redis 版的 JavaScript Object，存对象数据的首选

🔄 JS Object vs Redis Hash

📌 核心命令

💡 Hash vs String 存对象

📋 速查：Hash 命令

List：Redis 版的数组，消息队列和时间线的利器

🔄 JS Array vs Redis List

📌 核心命令

🔒 阻塞队列

📋 速查：List 命令

Set：Redis 版的 JS Set，去重和集合运算首选

🔄 JS Set vs Redis Set

📌 核心命令

💡 实战：点赞 + 抽奖

📋 速查：Set 命令

Sorted Set：带分数的有序集合，排行榜的终极武器

🔄 前端排序 vs Redis ZSet

📌 核心命令

💡 实战：游戏排行榜

📋 速查：Sorted Set 命令

缓存设计：从前端 memo 到服务端 Redis 缓存的思维升级

🔄 前端缓存 vs Redis 缓存

📌 Cache-Aside 旁路缓存

🔑 缓存更新策略

📋 速查：缓存模式

Session 管理：用 Redis 替代内存 Session，支持分布式

🔄 前端登录态 vs Redis Session

📌 Redis Session 实现

💡 Hash vs String 存 Session

📋 速查：Session 命令

限流：用 Redis 实现 API 速率限制，防止恶意请求

🔄 前端节流 vs 服务端限流

📌 固定窗口限流

📌 滑动窗口限流（更精确）

📋 速查：限流方案

排行榜：Sorted Set 天生就是为排行榜设计的

🔄 前端排行榜 vs Redis 排行榜

📌 完整排行榜实现

💡 多维度排行榜

📋 速查：排行榜命令

分布式锁：用 Redis 防止多个服务同时操作同一资源

🔄 前端互斥 vs 分布式锁

📌 基础分布式锁

⚠️ 分布式锁的陷阱

📋 速查：分布式锁

缓存雪崩、穿透、击穿：三大经典缓存问题一网打尽

🔄 三大问题对比

❄️ 缓存雪崩

🕳️ 缓存穿透

🔥 缓存击穿

📋 速查：缓存问题与解法

热点 Key：当单个 Key 被疯狂访问时怎么办

🔄 前端热点请求 vs Redis 热 Key

📌 发现热点 Key

📌 解决热点 Key

📋 速查：热 Key 处理

持久化：Redis 重启后数据还在吗？RDB vs AOF

🔄 前端存储持久化 vs Redis 持久化

📸 RDB（快照）