限流方案对比之优缺点与适用场景

限流方案对比：优缺点与适用场景

概述

限流是保障系统稳定性的重要手段，通过对请求进行流量控制，防止系统因突发流量而崩溃。本文将对比四种常见的限流方案，分析其优缺点及适用场景。

方案 1：Sentinel 热点参数限流

原理

Sentinel 热点参数限流是一种基于参数维度的限流方式，它可以针对请求中的某个参数（如用户ID、商品ID等）进行精细化限流。当某个参数值被频繁访问时，可以对该参数值单独设置限流阈值。

实现机制

• 使用 LRU 统计滑动窗口，统计每个参数值的热度
• 支持精确限流和普通限流两种模式
• 可以针对不同参数值设置不同的限流阈值
• 支持参数索引配置，支持基本类型和复杂对象

优点

缺点

适用场景

代码示例

@SentinelResource(value = "hotspotResource", blockHandler = "handleHotspot")
public String queryProduct(@HotParam(name = "productId") String productId) {
// 业务逻辑
return productService.query(productId);
}

// 配置热点参数限流规则
ParamFlowRule rule = new ParamFlowRule("hotspotResource")
.setParamIdx(0) // 第一个参数
.setGrade(RuleConstant.FLOW_GRADE_QPS)
.setCount(100) // 默认阈值
.setParamFlowItemList(Arrays.asList(
new ParamFlowItem("hot_product_001", 10), // 特定参数值阈值
new ParamFlowItem("hot_product_002", 20)
));
ParamFlowRuleManager.loadRules(Collections.singletonList(rule));

方案 2：Sentinel 普通流控 + 集群模式

原理

Sentinel 普通流控是基于资源维度的限流，可以针对 API、方法等资源设置 QPS 或并发线程数阈值。集群模式通过 Token Server 和 Token Client 的架构，实现分布式环境下的统一限流。

实现机制

• Token Server：负责管理限流规则和发放 Token，可以是独立部署或内嵌模式
• Token Client：向 Token Server 申请 Token，本地缓存部分 Token 减少网络开销
• 支持两种集群流控模式：
  • Standalone 模式：独立的 Token Server 进程
  • Embedded 模式：Token Server 内嵌在某个应用实例中

优点

缺点

适用场景

代码示例

// 配置集群流控规则
FlowRule rule = new FlowRule("resourceName")
.setGrade(RuleConstant.FLOW_GRADE_QPS)
.setCount(1000)
.setClusterMode(true) // 启用集群模式
.setClusterConfig(new ClusterFlowConfig()
.setFlowId(1001)
.setThresholdType(ClusterFlowConfig.FLOW_THRESHOLD_AVG_LOCAL) // 或 GLOBAL
.setStrategy(ClusterFlowConfig.STRATEGY_CLIENT_NEGOTIATE));

// Token Server 配置
ClusterServerConfig serverConfig = new ClusterServerConfig()
.setPort(18730)
.setIdleSeconds(600);

// Token Client 配置
ClusterClientConfig clientConfig = new ClusterClientConfig()
.setServerHost("token-server-host")
.setServerPort(18730);

方案 3：Redis ZSet + Lua 脚本

原理

利用 Redis 的有序集合（ZSet）存储请求的时间戳，通过 Lua 脚本保证原子性操作。每个请求的时间戳作为 ZSet 的 member，时间戳本身作为 score。通过 ZREMRANGEBYSCORE 移除时间窗口外的记录，并检查剩余记录数量是否超过阈值。

实现机制

1. 将当前时间戳作为 member 和 score 添加到 ZSet
2. 移除时间窗口外的旧记录（score < 当前时间 – 窗口大小）
3. 统计 ZSet 中剩余的记录数量
4. 如果数量 <= 阈值，允许请求；否则拒绝

所有操作封装在 Lua 脚本中，保证原子性，避免并发问题。

优点

缺点

适用场景

代码示例

— Lua 脚本：滑动窗口限流
local key = KEYS[1] — 限流 key
local window = tonumber(ARGV[1]) — 时间窗口（秒）
local limit = tonumber(ARGV[2]) — 限流阈值
local now = tonumber(ARGV[3]) — 当前时间戳（秒）

— 移除窗口外的记录
redis.call('ZREMRANGEBYSCORE', key, 0, now – window)

— 添加当前请求
redis.call('ZADD', key, now, now)

— 获取窗口内的请求数
local count = redis.call('ZCARD', key)

— 设置过期时间（防止 key 永久存在）
redis.call('EXPIRE', key, window)

— 判断是否超限
if count > limit then
return 0 — 拒绝
else
return 1 — 允许
end

// Java 调用示例
public boolean isAllowed(String key, int window, int limit) {
String luaScript = "local key = KEYS[1]\\n" +
"local window = tonumber(ARGV[1])\\n" +
"local limit = tonumber(ARGV[2])\\n" +
"local now = tonumber(ARGV[3])\\n" +
"redis.call('ZREMRANGEBYSCORE', key, 0, now – window)\\n" +
"redis.call('ZADD', key, now, now)\\n" +
"local count = redis.call('ZCARD', key)\\n" +
"redis.call('EXPIRE', key, window)\\n" +
"if count > limit then\\n" +
" return 0\\n" +
"else\\n" +
" return 1\\n" +
"end";

DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>(luaScript, Long.class);
Long result = redisTemplate.execute(
redisScript,
Collections.singletonList(key),
String.valueOf(window),
String.valueOf(limit),
String.valueOf(System.currentTimeMillis() / 1000)
);
return result != null && result == 1;
}

方案 4：Guava RateLimiter（本地限流）

原理

Guava RateLimiter 是 Google Guava 库提供的令牌桶算法实现。它以固定的速率向桶中放入令牌，请求到来时从桶中获取令牌，如果桶中没有足够的令牌，则拒绝请求或等待。

实现机制

• 使用令牌桶算法（Token Bucket Algorithm）
• 支持平滑突发（SmoothBursty）和平滑预热（SmoothWarmingUp）两种模式
• 基于内存实现，无需外部依赖
• 线程安全，支持并发访问

优点

缺点

适用场景

代码示例

// 创建 RateLimiter
// SmoothBursty 模式：允许突发流量
RateLimiter rateLimiter = RateLimiter.create(100.0); // 每秒 100 个请求

// SmoothWarmingUp 模式：平滑预热，冷启动时逐步增加速率
RateLimiter warmingUpLimiter = RateLimiter.create(100.0, 3, TimeUnit.SECONDS);

// 使用限流
public void processRequest() {
// tryAcquire：非阻塞，立即返回
if (rateLimiter.tryAcquire()) {
// 获取到令牌，处理请求
doProcess();
} else {
// 未获取到令牌，拒绝请求
throw new RateLimitExceededException();
}
}

// acquire：阻塞，直到获取到令牌
public void processRequestBlocking() {
rateLimiter.acquire(); // 阻塞直到获取到令牌
doProcess();
}

// 获取多个令牌
public void processBatchRequest(int permits) {
if (rateLimiter.tryAcquire(permits)) {
processBatch(permits);
}
}

// 动态调整速率
public void updateRate(double newRate) {
rateLimiter.setRate(newRate);
}

方案对比总结

对比表格

选型决策树

是否需要分布式限流？
├─ 否 → 使用 Guava RateLimiter（最简单、最高性能）
└─ 是 → 是否需要针对特定参数限流？
├─ 是 → 使用 Sentinel 热点参数限流 + 集群模式
└─ 否 → 是否需要长窗口限流（小时/天级别）？
├─ 是 → 使用 Redis ZSet + Lua（最优解）
└─ 否 → 使用 Sentinel 集群模式

组合使用建议

在实际项目中，多种限流方案可以组合使用，形成多层次的限流体系：

┌─────────────────────────────────────────────────────────────┐
│ 请求入口 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 网关层：Sentinel 集群限流（全局 QPS 控制） │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 服务层：Sentinel 热点参数限流（接口级、参数级限流） │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 业务层：Redis ZSet + Lua（用户级、长窗口限流） │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 本地层：Guava RateLimiter（本地资源保护） │
└─────────────────────────────────────────────────────────────┘

最佳实践建议

1. 限流阈值设置

• 压测确定基准：通过压测确定系统的最大承载能力
• 留有余量：限流阈值设置为系统承载能力的 70%-80%
• 分级限流：设置多级阈值，逐步降级

2. 限流策略选择

• 拒绝策略：直接拒绝，返回 429 状态码
• 等待策略：让请求排队等待（适合低延迟场景）
• 降级策略：限流时返回降级数据或默认值

3. 监控与告警

• 实时监控：监控限流触发次数、拒绝率
• 告警机制：限流触发时及时告警
• 日志记录：记录被限流的请求，便于分析

4. 限流规则管理

• 版本控制：限流规则纳入版本管理
• 灰度发布：新规则先在部分实例生效
• 回滚机制：规则异常时快速回滚

总结

选择限流方案时，需要综合考虑以下因素：

没有万能的限流方案，只有最适合的方案。根据实际场景选择合适的方案，或组合使用多种方案，才能构建稳定可靠的限流体系。