cs-note/hzh/REDIS/Sorted Set 滑动窗口.md

---
tags: [redis, sorted-set, sliding-window, lua-script]
create time: 2026-06-01 10:30
---

# Sorted Set 实现滑动窗口详解

## 一句话概括

**把每个请求的时间戳当成"分数"存进有序集合，每次来新请求时：**

> ① 清除窗口外的旧记录 → ② 数一数还剩多少 → ③ 没超就放行，超了就拒绝

就这么三步。下面是逐步拆解。

---

## 第一步：直观理解——为什么用 Sorted Set？

### 朴素想法的问题

假设我们要限制 **每分钟最多 100 个请求**，一种想法是：把每个请求的到达时间都记下来，随时数一下"最近一分钟内来了几个"。

```
时间轴：t-60s ━━━━━┳━━━━━┳━━━━━► t(现在)
                   ❌     ✅
                 过期区  保留区
```

问题在于：**你怎么快速找出"哪些记录落在最近 60 秒内"？**

如果用普通 String 或 Hash，只能遍历所有键做比较。而 Sorted Set **天然按 score 排序**，直接就能做范围操作。

### Sorted Set 里的角色

| 字段 | 放什么 | 作用 |
|------|--------|------|
| **score**（分数） | 毫秒级时间戳 | 决定顺序，也是判断是否在窗口的依据 |
| **member**（成员） | UUID / RequestID | 保证全局唯一，避免同毫秒的请求被覆盖 |

Sorted Set 的内部样子（注意看并发场景）：

```
score (时间戳)         member (UUID)        说明
─────────────────────────────────────────────────────────────
1748700000000  │────► abc123def456...
1748700000000  │────► 999xyz012abc...      ← ⚠️ 分布式并发同一毫秒，member 不同就并存！
1748700001500  │────► 789xyz012abc...
1748700003200  │────► def456ghi789...
1748700005000  │────► ghi789jkl012...
1748700005000  │────► mmm012nnn345...      ← ⚠️ 同上，score 重复完全没问题
```

有了有序性，两个操作一步到位：

1. **删过期**：所有 score < `now - 60s` 的记录一次性批量删除
2. **统计**：剩下的数量 = 窗口内的请求数

---

## 第二步：四条核心命令

整个算法只用了 4 条 Redis 命令。一条一条拆。

### 1. ZREMRANGEBYSCORE — 清理过期记录

```lua
ZREMRANGEBYSCORE key -inf (now - window * 1000)
```

**原理：** 从负无穷到窗口左边界，把所有过期元素删干净。

```
时间轴：  ← 过期区          → 保留区
          ┃───────┼─────────────────►
                  ▲
             now - window×1000

ZREMRANGEBYSCORE 做的事：
━━━━━━━━━━━━━━━━━━━┓
删除这里面的每一条               ┗━━ 保留这里的
───────────────────┛
```

**Q：为什么下界用 `-inf`？**  
历史记录可能跨越多个窗口周期，用 `-inf` 确保一次性全部清理干净，不会漏掉更早的数据。

### 2. ZCARD — 统计当前数量

```lua
ZCARD key
```

返回集合中的元素个数，即窗口内的请求总数。**O(1)**，Redis 内部维护了计数。

### 3. ZADD + EXPIRE — 插入 & 兜底

没超限就放行，同时给 key 设一个过期时间：

```lua
ZADD key now member      -- 以当前时间戳为 score 插入
EXPIRE key window        -- window 秒后 Redis 自动删 key，兜底清理
```

`EXPIRE` 的真正作用——为什么要设过期？

这里有个容易困惑的地方：**不是说 Lua 脚本没执行到 EXPIRE**（Lua 是原子的，要么全做完要么全不做），也不是说 ZREMRANGEBYSCORE 清不干净（它每次都从 `-inf` 开始删）。

`EXPIRE` 防御的是以下几种边界场景：

| 场景 | 会发生什么 | EXPIRE 救了什么 |
|------|-----------|----------------|
| 正常限流后不再访问 | key 永远存在，内存不被释放（里面可能没几条活跃数据） | ✅ 自动清理空闲 key，否则 key 永久占用内存 |
| 客户端 ZADD 成功但断连，EXPIRE 没发到 Redis | ZADD 插入了一条记录 | ✅ Redis 内部 TTL 兜底，到点自动删除 |
| 绕过 Lua，用 redis-cli 或其他客户端直接操作 | 手动 ZADD 了元素 | ✅ 还是会过期，不会被永久污染 |
| 主从切换极端情况 | 主节点 ZADD + EXPIRE 还没同步就挂掉 | ⚠️ 部分情况下 EXPIRE 在从库上丢失（极端场景） |

**类比理解：** `ZREMRANGEBYSCORE` 是每天大扫除，把过期的东西扔了；`EXPIRE` 是给房间定个租期，到期直接搬空，不用等你想起来打扫。

### 4. 判断逻辑

```
count >= maxLen ?  → 拒绝（返回 429）
count < maxLen    → 放行，插入新记录
```

---

## 第三步：完整流程 & Lua 原子化

### 流程图

```mermaid
flowchart LR
    A[请求到达] --> B[ZREMRANGEBYSCORE<br/>删过期]
    B --> C[ZCARD<br/>数一数]
    C --> D{超过max?}
    D -- 否 --> E[ZADD 插入<br/>EXPIRE 设过期]
    D -- 是 --> F[返回 429 拒绝]

    style B fill:#fff3e0
    style C fill:#fff3e0
    style E fill:#e8f5e9
    style F fill:#ffebee
```

### 为什么要用 Lua 脚本？

因为这 4 步必须是 **原子操作**——不允许其他请求插进来干扰：

```
❌ 非原子会怎样：

线程A: 清理过期 → 数数（得到 99）
       ↑ 此时线程B也来了，也得到 99
线程B: 清理过期 → 数数（得到 99）
       
线程A: 插入！count = 100
线程B: 插入！count = 101 ← 限流失效了
```

Lua 脚本在 Redis 里是单线程串行执行的，不会被中间打断。

### 精简 Lua 脚本

```lua
local key    = KEYS[1]
local window = tonumber(ARGV[1])  -- 窗口大小，秒
local maxLen = tonumber(ARGV[2])  -- 最大请求数
local now    = tonumber(ARGV[3])  -- 毫秒时间戳
local member = ARGV[4]            -- 唯一标识

-- 1. 清理过期（⚠️ 注意单位换算：window 是秒 ×1000 → 毫秒）
redis.call('ZREMRANGEBYSCORE', key, '-inf', now - window * 1000)

-- 2. 统计当前数量
local count = redis.call('ZCARD', key)

-- 3. 判断 & 插入
if count >= maxLen then
    return count              -- 超限
end

redis.call('ZADD', key, now, member)
redis.call('EXPIRE', key, window)
return count + 1              -- 放行
```

---

## 第四步：关键细节汇总

### 参数一览

| 参数 | 含义 | 示例值 | 单位 |
|------|------|--------|------|
| `window` | 滑动窗口大小 | `60` | 秒 |
| `maxLen` | 窗口内最大请求数 | `100` | 个 |
| `now` | 当前时间 | `1748700008100` | **毫秒** |
| `member` | 唯一标识 | `"abc123..."` | 字符串 |
| `key` | 滑动窗口的容器（Redis Key） | `"rate:sliding:user:1001"` | 字符串 |

### key —— 按什么限流？

这是最容易混淆的概念：**Lua 脚本里的 `key` 是 Redis 的 Key，不是 Sorted Set 内部的 score 或 member。**

它回答了**"对这个维度做限流"**这个问题：

```go
// 按用户 ID 限流
key := fmt.Sprintf("rate:sliding:user:%s", userID)

// 按 IP 限流
key := fmt.Sprintf("rate:sliding:ip:%s", clientIP)

// 按接口路径限流
key := fmt.Sprintf("rate:sliding:api:%s", apiPath)
```

三层关系：

```
Redis Key (key)                →  限流的维度（哪个用户 / 哪台 IP）
    └── Sorted Set           →  该 key 下的所有请求记录
            ├── member       →  每条请求的唯一 ID（去重用）
            └── score        →  每条请求的时间戳（排序用）
```

类比记忆：

| 类比 | Redis 对应物 | 作用 |
|------|-------------|------|
| **班级** | `key` | 划分限流范围 |
| **学生名单** | Sorted Set | 班级里的人 |
| **学号** | `member` | 区分每个学生（不能重复） |
| **身高** | `score` | 按高低排队（可以相同） |

不同业务场景下 `key` 的设计直接影响限流效果：

- **按用户 ID**：每个用户独立配额，公平但可能被恶意用户批量注册绕过
- **按 IP**：简单粗暴，共享宽带/NAT 下的用户会被连坐
- **按接口路径**：保护后端资源，防止某个接口被打挂
- **组合 key**：`rate:sliding:user:1001:api:/pay` = 单个用户对支付接口的独立配额

### 单位换算要点

```lua
now                = 毫秒 （由服务端生成）
window             = 秒   （业务配置）
window * 1000      = 毫秒 （用于减法对齐）
```

清理时用 `now - window * 1000`，本质是：**毫秒 − 秒×1000 = 毫秒 − 毫秒**，两边单位必须一致。

### member 必须唯一的原因

Sorted Set 中，如果 member 相同，无论 score 是什么，新值都会**覆盖**旧值。而 score 重复是完全没问题的：

```
场景                          结果
──────────────────────────────────────────────
同 score + 同 member          ❌ 被覆盖（两条请求丢了一条！）
同 score + 不同 member        ✅ 两条并存（正常）
不同 score + 不同 member      ✅ 两条并存（正常）
```

你的疑问很关键：**分布式下，不同节点在同一毫秒产生的时间戳相同怎么办？** 答案是无所谓，因为 member（UUID / ULID）已经保证了全局唯一。

```go
// 推荐 ULID（单调递增 + 全局唯一）
member := ulid.Now().String()

// 或者 UUIDv4（纯随机但足够碰撞安全）
// member := uuid.New().String()
```

**Q：为什么不用自增序号？**  
分布式多实例并发时，同一毫秒内不同节点的自增 ID 可能重复。ULID / UUID / RequestID 能保证全局唯一。

### Go 调用代码

```go
func SlidingWindowAllow(ctx context.Context, c *redis.Client, id string, windowSec int, maxRequests int) (int, error) {
    key := fmt.Sprintf("rate:sliding:%s", id)
    now := time.Now().UnixMilli()
    member := generateMember() // ULID / UUID

    result, err := c.Eval(ctx, slidingWindowLua, []string{key}, windowSec, maxRequests, now, member).Int()
    if err != nil {
        return 0, err
    }
    return result, nil
}
```

---

## 第五步：代价分析 & 方案选择

### 内存估算

每条记录的开销约 **~100 字节**（score 8字节 + member ~26字节 + 跳表节点 ~64字节）。

```
总内存 ≈ 记录数 × 100 字节

记录数 = QPS × window
```

| 场景 | QPS | 窗口(s) | 记录数 | 约需内存 |
|------|-----|---------|--------|----------|
| 低频 API | 10 | 86400 | 864,000 | ~86 MB |
| 普通接口 | 100 | 60 | 6,000 | ~600 KB |
| 高频网关 | 1000 | 60 | 60,000 | ~6 MB |
| 超高并发 | 10000 | 60 | 600,000 | ~60 MB |

### ⚠️ 阈值预警

当 **QPS > 1000 且窗口 > 10s** 时，Sorted Set 已经不太合适了：

- 单 key 存储数万 ~ 数十万条记录，内存压力大
- 每次请求要做 O(log N) 的 ZADD + ZREMRANGEBYSCORE，N 很大时 CPU 和延迟明显上升

### 替代方案对比

```mermaid
flowchart TD
    Start["需要限流"] --> Q1{"要精确统计还是近似即可?"}

    Q1 -- 精确 --> SS["Sorted Set<br/>精确到每条请求<br/>空间 O(QPS×window)"]
    Q1 -- 近似即可 --> TC{"QPS 高不高?"}

    TC -- 低 --> SWC["滑动窗口计数器<br/>分成 N 个子窗口<br/>空间 O(N)，N 远小于记录数"]
    TC -- 高 --> TB["令牌桶/漏桶<br/>O(1) 空间<br/>不精确但够用"]

    style SS fill:#fff3e0
    style SWC fill:#e3f2fd
    style TB fill:#c8e6c9
```

| 维度 | Sorted Set | 滑动窗口计数器 | 令牌桶/漏桶 |
|------|-----------|-------------|-----------|
| **精度** | 精确到每条请求 | 近似（子窗口粒度） | 不精确（速率平滑） |
| **空间** | O(QPS × window) | O(子窗口数 N) | O(1) |
| **时间** | O(log N) / 次 | O(1) / 次 | O(1) / 次 |
| **适用** | QPS ≤ 1000、小窗口 | QPS ≤ 10000 | 无上限 |

---

## 关联笔记

- [[分布式限流]] — 完整的限流算法演进路线
- [[Lua脚本]] — Lua 脚本中的 Sorted Set 操作
- [[滑动窗口计数器]] — 空间效率更高的替代方案