1. 限流算法概述
在分布式系统设计中，限流是保护服务稳定性的重要手段。想象一下节假日热门景区的检票口——如果没有人数限制，瞬间涌入的游客会让整个景区瘫痪。同样，我们的系统也需要这样的"检票机制"，这就是限流算法的价值所在。
目前主流的限流算法有四种：固定窗口、滑动窗口、漏桶和令牌桶。每种算法都有其独特的实现思路和适用场景。作为从业多年的系统架构师，我经常需要根据业务特点选择合适的限流方案。本文将深入剖析这四种算法的原理、实现细节和实战经验，包含完整的Redis+Lua和Java实现代码。
2. 四种限流算法详解
2.1 固定窗口算法
固定窗口算法是最直观的限流方式，就像地铁站的分钟客流统计：
java复制// Java实现核心逻辑
if (lock.lastTime == null || lock.lastTime < now) {
lock.lastTime = now + (timeWindowSecond * 1000);
lock.count = 0L;
}
if (lock.count < maxCount) {
lock.count++;
return true;
}
return false;
核心特点：
- 按固定时间单位（如1分钟）划分窗口
- 每个窗口独立计数，超限则拒绝请求
- 窗口切换时计数器清零
Redis实现关键点：
- 使用INCR命令计数
- 首次请求时设置过期时间
- 计数超过阈值返回false
典型问题：
假设限流100次/分钟，在59秒时涌入100请求，下一秒窗口重置后又来100请求，实际上2秒处理了200请求——这就是著名的"临界突发"问题。
提示：固定窗口适合对精度要求不高的场景，如防爬虫、短信频控等。
2.2 滑动窗口算法
滑动窗口像是一个移动的时间相框，实时统计最近一段时间内的请求：
lua复制-- Redis Lua脚本核心片段
local startWindowsTime = now - (timeWindowSecond * 1000)
redis.call('ZREMRANGEBYSCORE', key, 0, startWindowsTime)
local count = redis.call('ZCARD', key)
if count < maxCount then
redis.call('ZADD', key, now, uuid)
return true
end
return false
实现要点：
- 使用Redis的ZSET结构存储请求时间戳
- 每次请求删除窗口外的旧数据
- 统计当前窗口内请求数
内存优化技巧：
- 窗口时间不宜过长（建议≤5分钟）
- 高QPS场景慎用，可能引发内存暴涨
- 可考虑用HyperLogLog做近似计数
实战踩坑：
某次生产环境使用滑动窗口限流登录接口，由于未设置ZSET的最大长度，导致Redis内存溢出。后来我们增加了双重保护：1)限制ZSET最大元素数；2)添加监控告警。
2.3 漏桶算法
漏桶就像一个有破洞的水桶，无论流入多快，流出速度恒定：
java复制// Java实现核心逻辑
long interval = now - lock.lastTime;
double flowOutWater = rate / 1000.0 * interval;
lock.lastWater = Math.max(0D, lock.lastWater - flowOutWater);
if (lock.lastWater + 1 <= capacity) {
lock.lastWater += 1;
return true;
}
return false;
算法特性：
- 严格限制流出速率（如10次/秒）
- 突发流量会被缓冲或拒绝
- 保证下游服务不会被冲垮
适用场景：
- 支付接口调用第三方银行
- 数据库批量写入操作
- 老旧系统对接保护
参数设置经验：
桶容量(capacity)建议设置为速率(rate)的1-2倍。例如rate=10次/秒，capacity=15，既允许小幅波动，又避免过度堆积。
2.4 令牌桶算法
令牌桶像是定期发放通行证的保安：
lua复制-- Redis Lua实现片段
local interval = math.max(0, now - last_time)
local current_tokens = math.min(capacity, last_tokens + (interval * rate_per_ms))
if current_tokens >= reduce_token then
redis.call('SET', token_key, current_tokens - reduce_token)
return true
end
return false
核心优势：
- 允许突发流量（消耗积攒的令牌）
- 长期来看平均速率受限
- 用户体验更好
Java实现注意点：
- 使用double类型存储令牌数避免精度丢失
- 注意并发场景下的原子性操作
- 建议用锁保护关键代码段
性能对比测试：
在10万QPS压力下，各算法表现：
- 固定窗口：最低延迟，但有20%的临界突发
- 滑动窗口：精度最高，但内存占用多3倍
- 漏桶：最稳定，但99线延迟较高
- 令牌桶：突发场景表现最佳
3. Redis实现深度解析
3.1 Lua脚本原子性保障
Redis的原子执行特性使其成为限流实现的理想选择。我们所有核心逻辑都封装在Lua脚本中，例如令牌桶的完整实现：
lua复制local time_info = redis.call('TIME')
local now = tonumber(time_info[1]) * 1000 + math.floor(tonumber(time_info[2]) / 1000)
local interval = math.max(0, now - last_time)
local current_tokens = math.min(capacity, last_tokens + (interval * rate_per_ms))
关键技巧：
- 使用Redis TIME命令获取精确时间
- 所有计算在脚本内完成保证原子性
- 通过EXPIRE设置合理过期时间
3.2 内存优化方案
对于滑动窗口算法的高内存消耗问题，我们有多层优化方案：
- 数据采样：每N次请求记录1次
- 分片计数：将大窗口拆分为多个子窗口
- 近似算法：使用HyperLogLog统计基数
lua复制-- 分片计数示例
local slot = math.floor(now / windowSegment)
if slot ~= lastSlot then
redis.call('DEL', currentKey)
lastSlot = slot
end
3.3 集群环境处理
在Redis Cluster环境下需要注意：
- 所有限流key必须位于同一slot
- 可使用hash tag确保路由一致：
{user123}.rate.limit - 考虑跨节点同步延迟问题
4. Java实现最佳实践
4.1 并发控制方案
Java内存实现的限流器需要特别注意线程安全：
java复制// 双重检查锁实现
Lock lock = CACHE.get(ident);
if (lock == null) {
synchronized (CACHE) {
lock = CACHE.computeIfAbsent(ident, k -> new Lock());
// 清理过期条目
cleanExpiredEntries();
}
}
synchronized (lock) {
// 计数逻辑
}
性能优化点：
- 使用ConcurrentHashMap降低锁粒度
- 定期清理过期计数器
- 考虑使用LongAdder替代AtomicLong
4.2 时间窗口实现对比
固定窗口与滑动窗口的Java实现差异：
| 维度 | 固定窗口 | 滑动窗口 |
|---|---|---|
| 数据结构 | 单个计数器 | TreeSet时间序列 |
| 时间复杂度 | O(1) | O(logN) |
| 内存占用 | 恒定 | 随时间窗口增长 |
| 精度 | 低 | 高 |
4.3 生产环境建议
-
监控指标：
- 限流触发次数
- 请求处理延迟
- 内存/CPU使用率
-
动态配置：
java复制// 支持运行时调整参数 public void updateRate(long newRate) { this.rate = newRate; } -
降级策略：
- 令牌不足时返回排队位置
- 提供友好错误提示
- 考虑多级降级方案
5. 算法选型指南
5.1 决策矩阵
根据业务场景选择最合适的算法：
| 场景特征 | 推荐算法 | 理由 |
|---|---|---|
| 允许短期突发 | 令牌桶 | 用户体验好 |
| 严格保护下游 | 漏桶 | 绝对速率控制 |
| 简单计数场景 | 固定窗口 | 实现简单 |
| 需要精确控制 | 滑动窗口 | 无临界问题 |
5.2 参数配置参考
典型业务场景的配置建议：
-
API网关：
- 算法：令牌桶
- rate = 集群QPS的80%
- capacity = rate * 2
-
秒杀系统：
- 算法：漏桶
- rate = 数据库最大写入能力
- capacity = rate * 1.5
-
短信验证码：
- 算法：滑动窗口
- 窗口：60秒
- 最大次数：5次
5.3 混合策略实践
在实际项目中，我们经常组合多种算法：
java复制// 多级限流示例
RateLimiter[] limiters = {
new FixedWindowLimiter(1000, 100), // 每秒不超过100
new TokenBucketLimiter(50, 100) // 平均50，突发100
};
public boolean allowRequest() {
for (RateLimiter limiter : limiters) {
if (!limiter.tryAcquire()) {
return false;
}
}
return true;
}
这种分层限流方案既能防止短期突发，又能控制长期平均速率。
6. 性能优化与问题排查
6.1 Redis性能瓶颈
在高并发场景下，我们曾遇到Redis CPU跑满的情况。通过以下优化解决：
-
Pipeline批量操作：
java复制try (Pipeline p = jedis.pipelined()) { p.multi(); p.incr(counterKey); p.expire(counterKey, ttl); p.exec(); } -
Lua脚本优化：
- 减少Redis命令调用次数
- 使用局部变量
- 避免不必要的日志输出
-
Key设计原则：
- 使用hash tag确保分片均衡
- 设置合理的过期时间
- 避免大key产生
6.2 常见问题排查
问题1：限流不生效
- 检查时间同步（NTP服务）
- 验证Redis命令是否执行成功
- 确认阈值设置是否合理
问题2：内存泄漏
- 定期执行scan查找过期key
- 设置内存上限和淘汰策略
- 添加监控告警
问题3：限流不均匀
- 检查是否有热点key
- 考虑使用分布式锁协调
- 评估是否需要分片计数
6.3 压测建议
完整的限流系统需要经过严格压测：
-
基准测试：
- 单机最大QPS
- 不同算法资源消耗对比
- 集群扩展性测试
-
异常场景：
- Redis宕机时的降级方案
- 网络延迟的影响
- 时钟回拨的处理
-
监控指标：
bash复制# Redis关键指标 redis-cli info stats | grep instantaneous_ops redis-cli info memory | grep used_memory
7. 扩展与进阶
7.1 分布式限流方案
当单Redis实例成为瓶颈时，可以考虑：
-
分片计数：
java复制int shard = key.hashCode() % SHARD_COUNT; String shardKey = "rate_limit:" + shard + ":" + key; -
令牌分发：
- 中心节点定期分配令牌批次
- 边缘节点本地消费
-
一致性哈希：
- 避免扩容时的数据迁移
- 提高系统可扩展性
7.2 自适应限流
智能调整限流阈值的技术：
-
基于负载：
java复制double load = getSystemLoad(); double dynamicRate = baseRate * (1 - load); -
基于响应时间：
- 监控接口P99延迟
- 延迟升高时自动降级
-
机器学习：
- 预测流量波峰波谷
- 提前调整限流参数
7.3 与其他组件的集成
-
Spring Cloud Gateway：
yaml复制spring: cloud: gateway: routes: - id: user-service uri: lb://user-service filters: - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 100 redis-rate-limiter.burstCapacity: 200 -
Sentinel：
- 可视化配置规则
- 实时监控流控效果
- 支持熔断降级
-
自定义注解：
java复制@RateLimit(rate = 100, algorithm = "token") public ResponseEntity<?> getProduct() { // ... }
在实际项目中，我们通常会根据技术栈选择合适的集成方案。对于Spring生态，结合Spring Cloud Gateway的限流过滤器能快速落地；而对于需要精细控制的场景，自定义注解配合AOP实现更为灵活。