典型应用场景:缓存 / 分布式锁 / 限流 / 消息队列

总览: 数据结构 → 场景映射

前四篇积累了"有哪些武器"(String, List, Hash, Set, ZSet, Bitmap, HLL, GEO, Stream), 这一篇聚焦"怎么用它们打赢一场仗". 对于每个场景, 关注三个问题:

1. 为什么需要 -- 不用 Redis 会怎样?
2. 怎么实现 -- 用哪些数据结构, 哪些命令?
3. 有什么坑 -- 边界条件, 故障场景怎么处理?

1. 缓存策略(Cache Strategy)

缓存是 Redis 最广泛的应用. 核心问题不是"怎么存", 而是**"缓存和数据库之间怎么保持一致性"**--读写顺序, 失效策略, 异常兜底, 每一步选错了都可能导致数据错乱.

1.1 Cache Aside(旁路缓存)-- 最常用的模式

Cache Aside 的核心思想: 缓存是"附属品", 数据库是唯一真相源. 应用层自己管理缓存逻辑, Redis 和 DB 之间没有自动同步机制.

读流程

1. 先查缓存 → 命中直接返回
2. 缓存 miss → 查数据库
3. 将数据库结果写入缓存 + 设过期时间
4. 返回结果

def get_user(user_id):
    # 1. 查缓存
    data = redis.get(f"user:{user_id}")
    if data:
        return data

    # 2. 缓存 miss, 查 DB
    user = db.query("SELECT * FROM users WHERE id = ?", user_id)
    if not user:
        return None

    # 3. 回填缓存 + 设置过期时间
    redis.setex(f"user:{user_id}", 3600, user)

    return user

写流程 -- 为什么是"先DB后删缓存"?

更新数据时, 有两种顺序可选:

为什么是"删"而不是"更新"缓存?

更新缓存看似直接, 但存在两个问题:

1. 如果缓存是计算结果(如聚合数据), 更新代价高
2. 并发写操作可能导致缓存与 DB 不一致

删除缓存让下次读操作触发一次重新计算和回填, 反而更安全--这就是 Lazy 加载思想.

延迟双删(极端一致性场景)

在"先更新 DB 再删缓存"的基础上, 再加一次延迟删除来兜底:

1. 删缓存
2. 更新 DB
3. 等一小段时间(如 500ms)
4. 再次删缓存   ← 兜底: 防止第 1-2 步之间其他请求回填了旧数据

这个方案降低了不一致的时间窗口但无法彻底消除, 且增加了写操作的延迟. 绝大多数业务场景先更新 DB 再删缓存就足够了.

1.2 Read/Write Through(代理模式)

应用不直接操作 DB 和缓存, 而是通过一个缓存抽象层来读写. 缓存层负责同步逻辑, 应用侧代码简化.

1.3 Write Behind(异步写回)

应用只写缓存(Redis), 缓存层异步批量刷入数据库. 写入延迟极低, 但有数据丢失风险.

1.4 缓存三大问题(概要)

这三个问题在实际生产中极其常见, 这里先建立概念框架, 第 12 篇会深入展开具体解决方案.

2. 分布式锁(Distributed Lock)

单机环境下, synchronized 或 ReentrantLock 能保证线程安全. 但在多实例部署时, 每个实例有自己的 JVM/进程, 单机锁失效--需要一把所有实例都能看到的分布式锁.

2.1 SET NX PX: 最基础的方案

核心思想: 利用 Redis 单线程模型的原子性, 谁先 SET 成功谁就拿到锁.

# 获取锁: NX = 不存在才设置, PX = 毫秒级过期
SET lock:order:1001 unique_token NX PX 30000
→ OK          ← 拿到锁
→ (nil)       ← 别人已经持有

为什么是 SET ... NX PX 而不是 SETNX + EXPIRE 分两步?

2.2 安全释放与锁续期

为什么不能直接 DEL?

假设 A 拿到锁, 业务执行超时, 锁自动过期释放. B 拿到锁开始执行. 此时 A 恢复, 执行 DEL 把 B 的锁删了--A 释放了别人的锁.

A: SET lock:order NX PX 30000 → OK   ← A 拿锁
A: 业务执行中...超过了 30s...
   锁自动过期!                         ← A 的锁没了
B: SET lock:order NX PX 30000 → OK   ← B 拿到锁
A: DEL lock:order                     ← A 把 B 的锁删了!❌

解法: 释放时校验 value. SET 的时候放一个唯一 token, 释放时用 Lua 脚本比对 token, 一致才删:

-- 安全释放锁: 先比对 token, 一致才删
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

这个 Lua 脚本也是原子的--GET + DEL 之间不会被其他命令插入.

锁续期(Watch Dog)

如果业务执行时间不确定, 设置一个固定过期时间可能不够. 常见方案是启动一个后台续期线程:

拿到锁(过期 30s)
  ↓
启动后台线程: 每 10s 检查一次
  ├─ 锁还存在 + 业务还在跑 → EXPIRE 续期到 30s
  └─ 业务结束 → 停止续期 + 释放锁

Redisson 等 Java 客户端内置了此机制(叫 "watch dog"), 无需手动实现.

2.3 Redlock: 多节点分布式锁算法

单实例 Redis 做主从时存在风险: A 在主节点拿到锁, 主节点挂了但锁数据还没同步到从节点. 从节点提升为新主, B 又在新主上拿到同一把锁--两个实例同时认为自己持有锁.

Redlock 算法(Redis 作者 antirez 提出)通过在 N 个独立 Redis 节点上分别加锁来解决:

1. 客户端获取当前时间戳 t1
2. 依次向 N 个 Redis 节点请求加锁(SET NX PX, 超时时间远小于锁过期时间)
3. 如果 ≥ N/2+1 个节点加锁成功(且总耗时 < 锁有效期)
   → 锁获取成功, 有效时间 = 锁过期时间 - 总耗时
4. 否则向所有节点释放锁, 重试

2.4 常见陷阱

3. 限流(Rate Limiting)

限流的本质是控制单位时间内的请求次数. 保护下游服务不被突发流量打垮, 防止单个用户滥用资源. Redis 天然适合做限流计数器--内存操作够快, 过期机制自动清理.

3.1 固定窗口(Fixed Window)

最简单的方案: 以自然时间窗口(如 1 分钟)为界, 窗口内计数.

# key = rate:{user_id}:{window_timestamp}
# 每个时间窗口内最多 10 次请求

INCR rate:user_1001:1717200000     # window = 当前分钟的时间戳
EXPIRE rate:user_1001:1717200000 120   # 过期 = 窗口的 2 倍保证清理

if value > 10:
    reject request

也可以一步完成(利用 SET NX 初始化 + INCR):

-- Lua 原子化: 初始化 + 递增 + 判断
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])

local current = redis.call("INCR", key)
if current == 1 then
    redis.call("EXPIRE", key, window)
end
if current > limit then
    return 0   -- 限流
end
return 1       -- 放行

假设限制每分钟 10 次. 用户在 12:00:59 发了 10 个请求, 12:01:00 又发了 10 个请求. 两个请求在时间上只差 1 秒, 但因为跨了窗口边界, 全部放行了--实际 2 秒内通过了 20 个请求. 这是固定窗口最大的缺陷.

3.2 滑动窗口(Sliding Window)-- ZSet 方案

不再按整点分界, 而是以当前时间为终点, 回看过去 N 秒的请求数.

-- ZSet 滑动窗口限流(原子 Lua)
-- KEYS[1]: rate zset key
-- ARGV[1]: limit (窗口内最大请求数)
-- ARGV[2]: window (窗口时长, 秒)
-- ARGV[3]: now (当前毫秒时间戳, 保证唯一)
-- ARGV[4]: member (now + 随机数, 作为 member 保证不重复)

redis.call("ZREMRANGEBYSCORE", KEYS[1], 0, ARGV[3] - ARGV[2] * 1000)
local count = redis.call("ZCARD", KEYS[1])
if count >= tonumber(ARGV[1]) then
    return 0   -- 限流
end
redis.call("ZADD", KEYS[1], ARGV[3], ARGV[4])
redis.call("EXPIRE", KEYS[1], ARGV[2] + 1)
return 1

3.3 令牌桶(Token Bucket)

令牌桶与滑动窗口的思路不同: 不是统计"过去发了多少", 而是控制**"当前有没有令牌可用"**. 令牌以固定速率生成存入桶中, 请求来时必须拿到一枚令牌才能放行.

-- 令牌桶限流(原子 Lua)
-- KEYS[1]: 令牌桶 key
-- ARGV[1]: rate(令牌生成速率, 个/秒)
-- ARGV[2]: capacity(桶最大容量)
-- ARGV[3]: now(当前时间戳, 秒)
-- ARGV[4]: requested(本次请求需要的令牌数, 默认 1)

local rate = tonumber(ARGV[1])
local capacity = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local requested = tonumber(ARGV[4])

local last_time = tonumber(redis.call("HGET", KEYS[1], "last_time")) or now
local tokens = tonumber(redis.call("HGET", KEYS[1], "tokens")) or capacity

local elapsed = math.max(0, now - last_time)
local new_tokens = elapsed * rate
tokens = math.min(capacity, tokens + new_tokens)
local last_time = now

if tokens >= requested then
    tokens = tokens - requested
    redis.call("HSET", KEYS[1], "tokens", tokens, "last_time", last_time)
    redis.call("EXPIRE", KEYS[1], math.ceil(capacity / rate) * 2 + 10)
    return 1   -- 放行
else
    redis.call("HSET", KEYS[1], "tokens", tokens, "last_time", last_time)
    return 0   -- 限流
end

令牌桶的优势: 允许一定的突发流量(桶里积攒的令牌可一次性消耗), 但长期速率被严格控制. API 网关(如 Nginx 的 ngx_http_limit_req_module)和云服务商的限流大多基于令牌桶或其变体.

3.4 三种方案对比

4. 消息队列(Redis as Message Queue)

第 04 篇已经详细讲过 Stream 的命令和消费者组机制. 这里从方案演进和选型决策两个维度来梳理 Redis 做消息队列的全貌.

4.1 三种方案的演进

Pub/Sub 的特殊之处 -- 它是唯一支持"一发多收"广播的模式, 但也最不可靠:

# 终端1: 订阅频道
SUBSCRIBE order:notify
Reading messages... (press Ctrl-C to quit)

# 终端2: 发布消息
PUBLISH order:notify "New order: 1001"
→ (integer) 1   ← 有 1 个订阅者收到

# 如果订阅者离线后再上线 → 离线期间的消息永远丢失

Pub/Sub 的正确用法: 不依赖消息持久化的场景, 如 WebSocket 服务内跨节点广播, 配置热更新通知, 实时聊天消息分发.

4.2 选型边界: 什么时候该用 Kafka/RabbitMQ?

Stream 让 Redis 具备了"像 MQ 一样可靠"的能力, 但它仍然受限于 Redis 的定位--内存数据库, 不是专用消息中间件.

快速回顾