做高并发系统的同学肯定都遇到过这个问题：设置了一个固定的限流阈值，结果流量高峰期把正常用户给限流了，导致用户投诉；或者阈值设得太高，遇到流量突增又挡不住，系统直接被打垮。

我之前就遇到过这样一个案例：我们为某个接口设置了每秒 1000 的限流阈值。结果某天下午 3 点突然来了一波流量，峰值达到 2000 QPS，系统瞬间被压垮。后来调整到 3000，结果平时大部分时间阈值都用不满，浪费了系统资源。

今天我们就来聊聊动态自适应限流的正确姿势，让限流策略能根据实际情况自动调整。

传统限流的致命缺陷

1. 固定阈值的问题

很多系统使用固定的限流阈值，比如：

// 固定限流：每秒最多 1000 个请求
@RateLimiter(maxRequests = 1000, timeWindow = 1)
public void processRequest() {
    // 业务逻辑
}

这种方式的问题很明显：

• 高峰期：阈值太低，误杀正常用户
• 低峰期：阈值太高，浪费系统资源
• 无法应对突发流量：固定阈值无法快速响应流量变化

2. 常见限流算法的局限性

┌───────────────────────────────────────────────────────────────┐
│ 限流算法对比                                                  │
├──────────┬────────────┬────────────┬───────────────────────┤
│ 算法     │ 优点       │ 缺点       │ 适用场景               │
├──────────┼────────────┼────────────┼───────────────────────┤
│ 固定窗口 │ 简单       │ 边界问题   │ 低并发、稳定流量       │
│ 滑动窗口 │ 平滑       │ 计算复杂   │ 中高并发               │
│ 令牌桶   │ 支持突发   │ 令牌堆积   │ 流量不均匀             │
│ 漏桶     │ 流量整形   │ 响应滞后   │ 流量控制               │
└──────────┴────────────┴────────────┴───────────────────────┘

3. 典型的误杀场景

场景：电商大促活动
时间线：
10:00 - 正常流量：500 QPS，阈值 1000（够用）
10:01 - 活动开始：突然涨到 2500 QPS
10:02 - 限流生效：大量用户被拒绝，页面显示"请求过于频繁"
10:03 - 用户投诉："我刚点进去就被限流了，这活动还让不让人参加？"

问题根源：固定阈值无法适应流量的快速变化。

解决方案：滑动窗口 + 机器学习调优

1. 核心设计思想

我们的方案核心是三个层次：

1. 滑动窗口计数：精确统计任意时间窗口内的请求量
2. 自适应阈值调整：根据历史数据动态调整限流阈值
3. 机器学习预测：预测未来流量，提前调整阈值

架构图如下：

┌─────────────────────────────────────────────────────────────┐
│                    动态自适应限流架构                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐  │
│  │  请求入口    │───→│  滑动窗口    │───→│  限流决策    │  │
│  │  (拦截器)    │    │  (计数器)    │    │  (判断是否放行)│  │
│  └──────────────┘    └──────────────┘    └──────┬───────┘  │
│                                                  │          │
│                                                  ↓          │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐  │
│  │  历史数据    │←───│  ML预测器   │←───│  阈值调整    │  │
│  │  (趋势分析)  │    │  (预测未来)  │    │  (动态调优)  │  │
│  └──────────────┘    └──────────────┘    └──────────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

2. 滑动窗口算法原理

滑动窗口解决了固定窗口的边界问题：

固定窗口 vs 滑动窗口：

固定窗口（1秒）：
┌─────────┬─────────┬─────────┐
│  0-1s   │  1-2s   │  2-3s   │
│  999    │  999    │  999    │  每个窗口都接近阈值
└─────────┴─────────┴─────────┘
在边界处可能瞬间通过 2000 个请求（两个窗口各 1000）

滑动窗口（1秒，每100ms滑动一次）：
┌──┬──┬──┬──┬──┬──┬──┬──┬──┬──┐
│  │  │  │  │  │  │  │  │  │  │  每个小格子100ms
└──┴──┴──┴──┴──┴──┴──┴──┴──┴──┘
滑动窗口总是包含最近1秒的10个小格子

滑动窗口的核心数据结构：

class SlidingWindowCounter {
    private Deque<Bucket> buckets;  // 双端队列存储时间桶
    private int windowSize;          // 窗口大小（毫秒）
    private int bucketSize;          // 每个桶的大小（毫秒）
    
    // 添加新的请求计数
    void addRequest() {
        removeExpiredBuckets();
        getCurrentBucket().incrementCount();
    }
    
    // 获取当前窗口内的总请求数
    long getRequestCount() {
        removeExpiredBuckets();
        return buckets.stream().mapToLong(Bucket::getCount).sum();
    }
}

3. 自适应阈值调整策略

自适应算法的核心是根据系统状态动态调整阈值：

伪代码：自适应阈值调整逻辑

function adjustThreshold(currentRate, currentThreshold):
    # 1. 获取系统状态
    cpuUsage = getCPUUsage()
    memoryUsage = getMemoryUsage()
    responseTime = getAverageResponseTime()
    
    # 2. 计算健康分数（0-100）
    healthScore = calculateHealthScore(cpuUsage, memoryUsage, responseTime)
    
    # 3. 根据健康分数调整阈值
    if healthScore > 90:
        # 系统健康，可以提高阈值
        return currentThreshold * 1.1
    elif healthScore < 60:
        # 系统压力大，降低阈值
        return currentThreshold * 0.9
    else:
        # 保持不变
        return currentThreshold

4. 机器学习预测模块

使用历史数据训练模型，预测未来流量：

机器学习预测流程：
1. 收集历史流量数据（时间、请求量、系统指标）
2. 训练时序预测模型（如 ARIMA、Prophet、LSTM）
3. 实时预测未来 N 秒的流量峰值
4. 根据预测结果提前调整限流阈值

伪代码：
function predictNextMinutePeak():
    # 获取最近 5 分钟的历史数据
    historyData = fetchHistoryData(minutes=5)
    
    # 使用预训练模型预测
    predictedPeak = mlModel.predict(historyData)
    
    # 返回预测的峰值
    return predictedPeak

动态自适应限流的完整实现

1. 限流决策流程

完整的限流决策流程：

用户请求 → 滑动窗口计数 → 是否超过当前阈值？
                              │
              ┌───────────────┴───────────────┐
              ↓                               ↓
            超过阈值                        未超过
              │                               │
              ↓                               ↓
         检查是否可以                        放行请求
         临时提高阈值？                        │
              │                               ↓
    ┌─────────┴─────────┐               处理业务逻辑
    ↓                   ↓
  系统健康？          系统繁忙
    │                   │
    ↓                   ↓
  临时提高            拒绝请求
  阈值放行            返回限流提示

2. 核心限流组件

class AdaptiveRateLimiter {
    private SlidingWindowCounter counter;
    private volatile double currentThreshold;
    private MLForecaster forecaster;
    private SystemMetrics metrics;
    
    boolean tryAcquire() {
        // 1. 更新计数器
        counter.addRequest();
        long currentCount = counter.getRequestCount();
        
        // 2. 获取预测值，提前调整阈值
        double predictedPeak = forecaster.predict();
        double adjustedThreshold = calculateAdjustedThreshold(predictedPeak);
        
        // 3. 判断是否放行
        if (currentCount < adjustedThreshold) {
            return true;
        }
        
        // 4. 检查系统状态，决定是否临时放行
        return canTemporarilyAllow();
    }
}

3. 阈值调整策略详解

阈值调整策略分为三个层次：

┌─────────────────────────────────────────────────────────────┐
│ 第一层：静态基准阈值                                         │
│   - 根据系统配置的基础阈值                                   │
│   - 如：默认 1000 QPS                                       │
├─────────────────────────────────────────────────────────────┤
│ 第二层：动态自适应调整                                       │
│   - 根据实时系统指标调整                                     │
│   - CPU/内存/响应时间                                        │
│   - 调整幅度：±10%                                          │
├─────────────────────────────────────────────────────────────┤
│ 第三层：机器学习预测调整                                     │
│   - 根据预测的未来流量调整                                   │
│   - 提前 30-60 秒调整                                       │
│   - 调整幅度：±20-50%                                       │
└─────────────────────────────────────────────────────────────┘

实战方案对比

方案一：纯滑动窗口限流

核心逻辑：
- 使用滑动窗口精确计数
- 固定阈值
- 简单有效，但不够灵活

适用场景：
- 流量相对稳定的系统
- 对限流精度要求高
- 不需要动态调整

方案二：基于系统指标的自适应限流

核心逻辑：
- 滑动窗口计数
- 根据 CPU、内存、响应时间动态调整阈值
- 不需要机器学习模型

适用场景：
- 中等复杂度系统
- 无法训练 ML 模型
- 需要快速响应系统状态变化

方案三：完整的 ML 驱动自适应限流

核心逻辑：
- 滑动窗口计数
- 实时系统指标监控
- 机器学习流量预测
- 多层阈值调整策略

适用场景：
- 高并发复杂系统
- 流量波动大
- 对用户体验要求高

最佳实践与注意事项

1. 阈值调整的平滑过渡

避免阈值突然大幅变化导致系统震荡：

// 平滑调整算法
double smoothAdjust(double current, double target, double factor) {
    // factor 为平滑因子，0-1之间
    // 越接近0，调整越慢越平滑
    return current + (target - current) * factor;
}

2. 熔断机制

当系统严重过载时，需要快速熔断：

熔断条件（满足任一）：
- CPU 使用率 > 90% 持续 30 秒
- 内存使用率 > 95%
- 平均响应时间 > 500ms 持续 1 分钟
- 错误率 > 50%

熔断动作：
- 立即降低阈值到基准值的 50%
- 拒绝非核心请求
- 记录日志并告警

3. 多维度限流

除了全局限流，还需要考虑：

多维度限流策略：
┌─────────────────────────────────────────────────────────────┐
│ 维度              │ 示例                                    │
├───────────────────┼─────────────────────────────────────────┤
│ 用户级别          │ 普通用户 100 QPS，VIP 用户 500 QPS      │
│ 接口级别          │ 登录接口 500 QPS，查询接口 2000 QPS     │
│ IP 级别           │ 单个 IP 最多 100 QPS                    │
│ 地区级别          │ 不同地区设置不同阈值                      │
└───────────────────┴─────────────────────────────────────────┘

4. 限流策略的动态配置

支持运行时动态调整限流策略：

// 动态配置示例
class RateLimitConfig {
    @Value("${rate.limit.default-threshold}")
    private int defaultThreshold;
    
    @Value("${rate.limit.adjust-enabled}")
    private boolean adjustEnabled;
    
    @Value("${rate.limit.ml-enabled}")
    private boolean mlEnabled;
    
    // 支持运行时更新
    @RefreshScope
    public void updateThreshold(int newThreshold) {
        this.defaultThreshold = newThreshold;
    }
}

效果对比

总结

动态自适应限流的核心原则：

1. 滑动窗口是基础：精确计数，避免边界问题
2. 系统状态是关键：根据 CPU、内存、响应时间实时调整
3. 机器学习是升级：预测未来流量，提前准备
4. 平滑调整是保障：避免阈值突变导致系统震荡
5. 多层策略是保险：全局、用户、接口多维度限流

记住：限流不是目的，而是手段。好的限流策略应该在保护系统的同时，尽可能减少对用户的影响。动态自适应限流就是在这两者之间找到最佳平衡点。

源码获取

文章已同步至小程序博客栏目，需要源码的请关注小程序博客。

公众号：服务端技术精选

小程序码：