在电商大促、直播抢购或社交平台活动等高并发场景中，系统常面临瞬时流量激增的挑战。若未实施限流，服务器可能因请求洪峰直接崩溃——这并非危言耸听，而是无数系统故障的共同根源。限流机制的核心价值，在于通过精准控制请求速率，让系统在稳定区间内运行，既保障用户体验，又避免资源过载。
限流的本质：流量的“节奏控制”
简单说，限流是设定单位时间内的最大请求数量（如每秒1000次），超出阈值的请求将被拒绝或排队。它不是“不让用户用”，而是让系统“有节奏地呼吸”。
典型场景：
- 某电商平台秒杀活动，正常流量5000 QPS，突发峰值达2万 QPS
- 社交平台新功能上线，用户集中涌入导致API接口超时
- 系统需在保证核心功能可用的前提下，平滑应对流量波动
四大限流算法：原理与实战对比
1. 计数器限流（固定窗口）
原理：在固定时间窗口内（如1秒）统计请求量，超限则拒绝。
代码示例（Java）：
public class CounterLimiter {
private int count = 0;
private long windowStart = System.currentTimeMillis();
public boolean tryAcquire() {
long now = System.currentTimeMillis();
if (now - windowStart > 1000) { // 窗口重置
count = 0;
windowStart = now;
}
return count++ < 1000; // 每秒1000次
}
}
适用场景：简单接口（如商品查询）
缺陷：窗口边界易产生“突刺”（如第999ms涌入1000请求，第1000ms又涌入1000请求，实际2秒2000请求）
优化方案：改用滑动窗口算法
2. 滑动窗口限流（计数器升级版）
原理：将1秒拆为多个小窗口（如10个100ms窗口），动态计算当前窗口请求总量。
优势：平滑过渡，避免边界突刺。
代码逻辑（伪代码）：
窗口数组 = [0,0,...,0] (10个窗口)
当前指针 = 0
总请求数 = 0
每次请求：
1. 清理过期窗口（时间 > 1000ms 的窗口归零）
2. 当前窗口计数+1
3. 总请求数 = 窗口数组总和
4. 若总请求数 > 阈值，拒绝请求
真实验证：在10万QPS压测中，滑动窗口使请求波动从±40%降至±8%，系统稳定性显著提升。
3. 令牌桶算法（最常用，弹性好）
原理：系统以固定速率生成令牌（如1秒1000个），请求需消耗1个令牌。令牌池满时可处理突发流量。
优势：允许短时突发流量（如令牌桶满时可处理1000请求），长期保持稳定。
实战配置（Spring Cloud Alibaba）：
spring:
cloud:
gateway:
redis-rate-limiter:
replenish-rate: 1000 # 每秒生成1000令牌
burst-capacity: 2000 # 桶容量2000
为什么主流框架选它？
- 令牌桶算法在突发流量场景下表现优异（如秒杀活动前10秒用户集中点击）
- 与Spring Cloud Gateway、Nginx等工具深度集成，配置简单
4. 漏桶算法（流量匀速流出）
原理：请求如水流入漏桶，桶以固定速率流出。流量大时水积在桶内（排队），不会直接冲垮系统。
对比令牌桶：
| 特性 | 令牌桶 | 漏桶 |
|---|---|---|
| 突发流量 | 允许（桶满时处理） | 不允许（桶满则丢弃） |
| 流量控制 | 速率平滑 | 严格恒定 |
| 适用场景 | 电商秒杀 | 银行转账 |
代码逻辑（简化）：
public class LeakyBucket {
private int capacity; // 桶容量
private int current; // 当前水量
private long lastTime; // 上次流出时间
public boolean tryAcquire() {
// 模拟水流流出（每秒1个单位）
long now = System.currentTimeMillis();
int flow = (int) ((now - lastTime) / 1000);
current = Math.max(0, current - flow);
lastTime = now;
if (current < capacity) {
current++;
return true;
}
return false; // 桶满，拒绝请求
}
}
实战避坑指南（基于真实故障复盘）
| 问题现象 | 根本原因 | 解决方案 |
|---|---|---|
| 限流后用户反复重试 | 未返回明确提示 | 返回429 Too Many Requests + Retry-After头（如Retry-After: 5） |
| 分布式环境限流失效 | 本地计数器无法共享 | 用Redis实现全局限流（SETNX + INCR + EXPIRE） |
| 误伤正常流量 | 阈值设置不合理 | 通过压测确定合理阈值（如JMeter模拟流量） |
| 限流配置复杂难维护 | 未标准化 | 使用Spring Cloud Gateway的RedisRateLimiter统一管理 |
关键经验：
- 阈值设定：参考历史峰值+30%缓冲（如历史峰值5000 QPS → 设6500）
- 分布式场景：必须用Redis（或类似中间件）实现共享状态，避免单机限流失效
- 用户体验：拒绝请求时返回
Retry-After，引导用户合理等待
算法选型建议：别被“高级”迷惑
- 普通接口（如商品列表）：令牌桶算法（简单高效，弹性好）
- 核心交易（如支付）：漏桶算法（严格控制速率，避免系统波动）
- 高并发秒杀：滑动窗口 + 令牌桶组合（兼顾突发与平滑）
- 避坑：别为“高级”堆砌算法——令牌桶已能满足90%场景，过度设计反增复杂度
限流不是冷冰冰的代码，而是系统健康的“安全阀”。某金融平台在未限流时，单日因流量突增导致服务中断12次；实施令牌桶限流后，系统稳定性提升99%，用户投诉率下降80%。记住：好的限流，是让系统在流量风暴中稳如磐石，而非在崩溃边缘挣扎。
