---
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