178 lines
6.3 KiB
Markdown
178 lines
6.3 KiB
Markdown
---
|
||
tags: [redis, memory, ttl, expiration, best-practices]
|
||
create time: 2026-06-01 10:30
|
||
---
|
||
|
||
# 僵尸 Key 防护
|
||
|
||
## 概述
|
||
|
||
**僵尸 Key** 是指不再有新请求但仍长期占用 Redis 内存的 Key。它们通常是因为 `EXPIRE` 设置失败或遗漏导致的——虽然单个 Key 不大，但随着时间积累会消耗越来越多的内存，最终引发 OOM。
|
||
|
||
对应薄弱点 F13：令牌桶中 `EXPIRE` 的保护机制及其计算方法。
|
||
|
||
## 一、什么是僵尸 Key？
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
Day1["📅 第 1 天<br/>用户 user123 访问了 API"] --> Create["创建 Key<br/>rate:limit:user123:daily"]
|
||
Create --> EXPIRE["设置 EXPIRE<br/>TTL = 86400s (1天)"]
|
||
|
||
Day2["📅 第 2 天"] --> Active{"user123 还访问吗?"}
|
||
Active -- "是" --> Renew["正常续期 ✓"]
|
||
Active -- "否" --> Expire["✅ Key 自动过期删除 ✓"]
|
||
|
||
Day3["📅 第 3 天"] --> NoExpire{"如果 EXPIRE 没生效?"}
|
||
NoExpire --> Zombie["❌ Key 仍然占用 ~500B<br/>但已无实际用途"]
|
||
|
||
zombieCount["Zombie Count 增长"] --> Accumulate["1000 users × 500B = 500KB<br/>10000 users → 5MB<br/>..."]
|
||
|
||
style Expire fill:#c8e6c9
|
||
style Zombie fill:#ffebee
|
||
style Accumulate fill:#ffcdd2
|
||
```
|
||
|
||
### 典型场景
|
||
|
||
| 场景 | 原因 | 结果 |
|
||
|------|------|------|
|
||
| EXPIRE 在 Lua 脚本外面 | 原子性被破坏，EXPIRE 可能不执行 | Key 永久存在 |
|
||
| Lua 脚本中的 EXPIRE 报错 | 条件判断导致跳过 | Key 不过期 |
|
||
| 代码忘记写 EXPIRE | 开发疏忽 | Key 永不消失 |
|
||
| Redis 内存满导致无法写入 | OOM 后部分操作失败 | 新增 Key 没设置 TTL |
|
||
|
||
## 二、F13 考点详解：令牌桶的 EXPIRE 保护机制
|
||
|
||
这是你最薄弱的地方之一。令牌桶的 Lua 脚本中有一行关键的 EXPIRE：
|
||
|
||
```lua
|
||
-- 令牌桶 Lua 脚本（节选）
|
||
redis.call('HMSET', tokensKey, 'tokens', remaining, 'last_refill', now)
|
||
redis.call('EXPIRE', tokensKey, math.ceil(capacity / rate) * 2)
|
||
return {allowed, math.floor(remaining * 1000 / rate)}
|
||
```
|
||
|
||
### 2.1 为什么是 `math.ceil(capacity / rate) * 2`？
|
||
|
||
这行公式的含义是：**填满整个桶所需的时间 × 2**
|
||
|
||
| 参数 | 含义 | 示例值 |
|
||
|------|------|--------|
|
||
| `capacity` | 桶的最大容量（最大令牌数） | 100 |
|
||
| `rate` | 每秒补充的令牌数 | 10/s |
|
||
| `capacity / rate` | **从空到满需要的时间** | 100 / 10 = 10 秒 |
|
||
| `* 2` | **留一倍余量** | 20 秒 |
|
||
| `math.ceil(...)` | **向上取整**（Redis EXPIRE 需要整数秒） | 20 |
|
||
|
||
**逻辑推导：**
|
||
|
||
```
|
||
如果一个用户在 t=0 时创建了限流 Key，之后再也不来了：
|
||
- 最晚的可能活动时间：t = capacity/rate（桶从空逐渐加满的时间）
|
||
- 但如果用户在 t=0 就用完了所有令牌，然后不再来...
|
||
- Key 实际上从最后一次活动就开始倒计时了
|
||
|
||
所以 EXPIRE 应该从"最后一次有活动的时刻"开始算。
|
||
我们已经通过 HMSET 更新时间戳保证了这一点。
|
||
但为什么要乘 2？因为：
|
||
1. 用户可能在某个时间点刚好用完令牌
|
||
2. 然后又过了一段时间才再来
|
||
3. 这段时间内，桶已经在慢慢补充令牌了
|
||
4. ×2 给了足够的缓冲，确保即使是最长的空闲间隔也能覆盖
|
||
```
|
||
|
||
### 2.2 数值演示
|
||
|
||
| capacity | rate | capacity/rate | ×2 后的 TTL | 说明 |
|
||
|----------|------|-------------|-----------|------|
|
||
| 100 | 10/s | 10s | 20s | 一般 API 限流 |
|
||
| 1000 | 100/s | 10s | 20s | 高频接口 |
|
||
| 10000 | 100/s | 100s | 200s | 高配额用户 |
|
||
| 100 | 1/s | 100s | 200s | 低频长周期 |
|
||
|
||
> [!tip]- 这个公式的直觉理解
|
||
>
|
||
> "一个桶要多久才能从空变成满？"— 答：capacity/rate。
|
||
>
|
||
> 在这个时间内肯定能看到用户的活动迹象。如果没有活动，2 倍时间就足以让它安全过期。既不会太短（刚设完就过期），也不会太长（僵尸太久）。
|
||
|
||
## 三、排查与清理
|
||
|
||
### 3.1 查找僵尸 Key
|
||
|
||
```bash
|
||
# 方法1: 检查特定前缀的 Key 是否没有 TTL
|
||
redis-cli --scan --pattern "rate:*" | while read key; do
|
||
ttl=$(redis-cli TTL "$key")
|
||
if [ "$ttl" = "-1" ]; then
|
||
echo "ZOMBIE: $key"
|
||
fi
|
||
done
|
||
|
||
# 方法2: Go 程序批量扫描（见 SCAN 文档）
|
||
```
|
||
|
||
### 3.2 手动清理
|
||
|
||
```bash
|
||
# DEL 同步删除（小 Key）
|
||
DEL rate:limit:zombie_user_001
|
||
|
||
# UNLINK 异步删除（大 Key，不阻塞）
|
||
UNLINK rate:sliding:large_zombie_key
|
||
```
|
||
|
||
### 3.3 预防 Checklist
|
||
|
||
```yaml
|
||
prevention_checklist:
|
||
lua_scripts:
|
||
- "所有涉及数据写入的 Lua 脚本，必须包含 EXPIRE"
|
||
- "EXPIRE 应该在 Lua 内部（保证原子性），不能放在外面"
|
||
- "使用合理的 TTL 计算公式: ceil(max_lifetime / rate) × safety_factor"
|
||
|
||
code_review:
|
||
- "新加的 Key 必须有对应的 EXPIRE"
|
||
- "INCR + EXPIRE 组合必须是原子的（Lua 或管道内的 MULTI/EXEC）"
|
||
- "禁止用 INCR 后立即 EXPIRE 的两个独立命令（非原子，中间可能被其他操作打断）"
|
||
|
||
monitoring:
|
||
- "监控 DBSIZE 趋势（keys 总数）"
|
||
- "定期检查未设置 TTL 的 Key 数量"
|
||
- "告警阈值: 未过期 Key 占比 > 5% 触发告警"
|
||
```
|
||
|
||
## 四、INCR + EXPIRE 的原子性问题
|
||
|
||
```go
|
||
// ❌ 错误：非原子操作
|
||
count := rdb.Incr(ctx, key) // Step 1: 自增
|
||
rdb.Expire(ctx, key, windowSeconds) // Step 2: 设置过期
|
||
// 如果 Step 2 失败（网络抖动、超时），Key 就永远不会过期！
|
||
|
||
// ✅ 正确：Lua 脚本内原子化
|
||
const luaScript = `
|
||
local count = redis.call('INCR', KEYS[1])
|
||
if count == 1 then
|
||
redis.call('EXPIRE', KEYS[1], ARGV[1])
|
||
end
|
||
return count
|
||
`
|
||
result := rdb.Eval(ctx, luaScript, []string{key}, windowSeconds).Int()
|
||
```
|
||
|
||
## 五、常见误解
|
||
|
||
| 误解 | 真相 |
|
||
|------|------|
|
||
| "Redis 会自动删除过期的 Key" | 是的，但前提是设置了 TTL。没设置 TTL 的 Key 永远不会自动删除 |
|
||
| "LRU 淘汰会帮我清理僵尸 Key" | LRU 基于访问频率，僵尸 Key 可能因为曾经活跃过而暂时"免死" |
|
||
| "重启 Redis 就能清空" | 生产环境不能随便重启，且 AOF 持久化会在重启后恢复这些 Key |
|
||
| "TTL 很短没关系，反正很快会过期" | 10000 个 Key × 1 秒 TTL = 瞬时内存峰值，仍可能造成压力 |
|
||
|
||
## 关联笔记
|
||
|
||
- [[分布式限流]] — 排错指南中的内存持续增长章节
|
||
- [[内存持续增长排查]] — 系统性的内存问题排查流程
|
||
- [[SCAN命令]] — 用 SCAN 批量扫描僵尸 Key
|