---
tags: [redis, rate-limiting, multi-layer, architecture]
create time: 2026-06-01 10:30
---

# 多级限流架构实战

## 概述

单个限流算法通常不够用。生产环境中的限流像洋葱一样**层层叠加**——每层保护不同的目标，使用不同的算法和维度。这种设计既防御了大规模攻击，又为正常用户提供了良好的配额管理。

对应薄弱点 F5：多级限流架构各层的设计选择。

## 一、为什么需要多级？

```mermaid
flowchart LR
    subgraph "单一维度的局限"
        L1["仅 IP 限流"] --> PROBLEM1["问题：无法区分同一 IP 下的不同用户"]
        L2["仅用户限流"] --> PROBLEM2["问题：恶意攻击者可注册大量账号绕过"]
        L3["仅接口限流"] --> PROBLEM3["问题：不防刷单/暴力扫描"]
    end
    
    PROBLEM1 --> MULTI["→ 需要多级组合"]
    PROBLEM2 --> MULTI
    PROBLEM3 --> MULTI

    style PROBLEM1 fill:#ffebee
    style PROBLEM2 fill:#ffebee
    style PROBLEM3 fill:#ffebee
    style MULTI fill:#e8f5e9
```

单层限流的盲区：
- 只看 IP → 一个用户的多个账号共享配额（或反之，一个 IP 下多个用户被误伤）
- 只看用户 → 恶意用户可以创建无数个账号突破限制
- 只看接口 → 对暴力破解、爬虫扫描无能为力

## 二、经典三级限流架构

```mermaid
flowchart TD
    Client["👤 客户端请求"] --> GW["🌐 API Gateway"]
    GW --> L1
    
    subgraph L1Layer["🔴 L1: IP 维度 - 第一道防线"]
        direction LR
        L1Action["防暴力扫描<br/>防恶意攻击"]
        L1Algorithm["短窗口固定计数<br/>例如: 100 req/s/IP"]
    end
    
    L1 -- pass --> L2
    
    subgraph L2Layer["🟡 L2: 用户维度 - 配额管理"]
        direction LR
        L2Action["控制每日/每月配额<br/>区分免费/付费等级"]
        L2Algorithm["天级滑动窗口日志<br/>例如: 1000 req/day"]
    end
    
    L2 -- pass --> L3
    
    subgraph L3Layer["🟢 L3: 接口维度 - 保护后端"]
        direction LR
        L3Action["保护实例不被打满<br/>QPS/内存保护"]
        L3Algorithm["令牌桶/漏桶<br/>例如: 5000 req/s/endpoint"]
    end
    
    L3 -- pass --> Biz["💼 执行业务逻辑"]
    
    L1 -- fail --> R429["HTTP 429 Too Many Requests"]
    L2 -- fail --> R429
    L3 -- fail --> R429

    style L1Layer fill:#ffebee,color:#000
    style L2Layer fill:#fff3e0,color:#000
    style L3Layer fill:#e8f5e9,color:#000
    style R429 fill:#b71c1c,color:#fff
```

### 层级详解

| 层级 | 限流维度 | 核心目标 | 推荐算法 | 典型参数 | Key 示例 |
|------|---------|---------|---------|---------|---------|
| **L1** | IP / CIDR | 防刷、防攻击、防爬虫 | 短窗口固定计数 | 100 req/s/IP | `rate:ip:{IP}:short` |
| **L2** | 用户 ID / Account | 配额管理（免费/付费） | 天级滑动窗口日志 | 1000 req/day | `rate:user:{UID}:daily` |
| **L3** | Endpoint / Interface | 保护下游资源 | 令牌桶 / 漏桶 | 5000 req/s/path | `rate:api:{path}` |

### L1：IP 层 - 最短视的窗口

```
时间窗口：1 ~ 5 秒
算法：固定窗口计数器
目的：快速拦截自动化攻击

为什么用短窗口？
- 恶意流量的特点是短时间内密集发起
- 短窗口可以及时响应，不留攻击窗口
- 不会因为窗口太长导致误伤正常用户的突发流量
```

```go
// L1: IP 限流 - 短窗口固定计数
const shortWindowLua = `
local key      = KEYS[1]
local maxCount = tonumber(ARGV[1])
local window   = tonumber(ARGV[2])

local count = redis.call('INCR', key)
if count == 1 then
    redis.call('EXPIRE', key, window)
end
return count
`

func IPLimitAllow(ctx context.Context, rdb *redis.Client, ip string) (bool, error) {
    // 5 秒窗口，最多 100 次请求
    const windowSec = 5
    const maxReq = 100
    
    key := fmt.Sprintf("rate:ip:{%s}", ip)
    result, err := rdb.Eval(ctx, shortWindowLua, []string{key}, maxReq, windowSec).Int()
    if err != nil {
        return false, err
    }
    return result <= maxReq, nil
}
```

### L2：用户层 - 精确的日配额

```
时间窗口：24 小时（按天重置）
算法：Sorted Set 滑动窗口（逐条精确统计）
目的：区分免费用户和付费用户的配额

为什么用 Sorted Set？
- 日配额 QPS 不高（1000/day ≈ 0.01 QPS）
- 需要精确统计，不能有近似误差
- 免费/付费分级，每个用户独立配额
```

### L3：接口层 - 保护后端资源

```
时间窗口：持续监控（令牌桶模型）
算法：令牌桶
目的：防止某个接口被打爆，保护数据库/下游服务

为什么用令牌桶？
- O(1) 空间，不随时间增长
- 允许合理突发（用户批量操作）
- 输出速率可控，保护后端稳定
```

## 三、多级限流的调用链路

```mermaid
sequenceDiagram
    participant C as 客户端
    participant G as Go Service
    participant R as Redis
    
    C->>G: HTTP Request
    G->>R: L1: IP Check (100/s/5s)
    alt Blocked by L1
        R-->>G: count > 100
        G-->>C: 429 (L1 blocked)
    else
        G->>R: L2: User Check (1000/day)
        alt Blocked by L2
            R-->>G: count >= 1000
            G-->>C: 429 (L2 blocked)
        else
            G->>R: L3: Token Bucket (5000/s)
            alt Blocked by L3
                R-->>G: no tokens
                G-->>C: 429 (L3 blocked)
            else
                R-->>G: allowed
                G->>G: Execute Business Logic
                G-->>C: 200 OK
            end
        end
    end
```

> [!note]- 性能考量
>
> 多级限流意味着每次请求要发 **3 次 Redis 调用**。优化方向：
> - **本地缓存 + 远程校验**：L1 可以在本地做短期计数（如 sync.Map），定期同步到 Redis
> - **Pipeline 合并**：L1/L2/L3 的三个 Lua 调用可以用 Pipeline 打包
> - **短路策略**：如果 L1 就拒绝了，不需要继续查 L2/L3

## 四、降级与熔断联动

```mermaid
flowchart TD
    Normal["✅ 正常限流状态"] --> Check{"Redis 可用?"}
    
    Check -- "是" --> RL["正常走多级限流"]
    Check -- "否" --> Degradation{"降级策略"}
    
    Degradation -- "短暂断开" --> Local["本地内存限流<br/>降级模式"]
    Degradation -- "长时间不可用" --> PermitAll["放行所有请求<br/>宁可超限不可停机"]
    
    Local --> Recovery{"Redis 恢复?"}
    Recovery -- "是" --> Normal
    Recovery -- "否" --> PermitAll
    
    style Normal fill:#c8e6c9
    style PermitAll fill:#fff3e0
    style Local fill:#e3f2fd
```

| Redis 状态 | L1 IP 层 | L2 用户层 | L3 接口层 |
|-----------|---------|----------|----------|
| **正常** | Redis Lua | Redis Lua | Redis Lua |
| **短暂故障** | 本地 sync.Map 缓存计数 | 跳过（默认放行） | 本地令牌桶 |
| **长时间故障** | 全部放行 | 全部放行 | 全部放行 |

> [!warning]- 降级不是无限制的
>
> 如果 L1（IP 层）也降级放行了，意味着任何 IP 都没有限制——这时应该配合 CDN/WAF 等外部防御层做兜底。

## 五、各层的超时与重试配置

```
多层限流系统的超时设置：

┌─────────┬──────────────┬──────────────────────────┐
│ 层级     │ Redis 超时    │ 客户端超时               │
├─────────┼──────────────┼──────────────────────────┤
│ L1       │ 1ms          │ 50ms（快速判断）         │
│ L2       │ 5ms          │ 200ms（配额查询）        │
│ L3       │ 3ms          │ 100ms（令牌检查）        │
│ 合计     │ 9ms          │ —                        │
└─────────┴──────────────┴──────────────────────────┘
```

各层超时应该远小于整体业务超时，否则限流模块本身会成为瓶颈。

## 关联笔记

- [[分布式限流]] — 限流的基础算法介绍
- [[Jitter抖动与重试策略]] — 各层的客户端重试策略设计
- [[02-服务治理/06-容错模式]] — 限流在容错体系中的位置