企业级 Java 后端接口限流与熔断实战：从令牌桶、滑动窗口到 Sentinel 降级的完整防线

一、为什么限流与熔断必须成对出现

只有限流、没有熔断的系统，扛得住突发流量，却扛不住下游变慢：线程池被慢请求占满，正常请求也被拖垮。只熔断、不限流的系统，下游一恢复又会被瞬间打满。企业级后端最稳妥的做法是“限流在前挡流量、熔断在后保核心”，两者分层配置、互不替代。

以一个示例场景说明（以下均为示例数据，非真实生产指标）：某订单查询接口平时峰值 QPS 约 800（示例数据），大促 10 分钟内冲到 5200（示例数据），下游库存服务 P99 从 60ms 恶化到 900ms（示例数据）。没有防护时，应用线程池在 2 分钟内打满，健康检查开始超时；加上令牌桶限流与慢调用熔断后，超额请求快速失败，核心下单链路始终可用。

二、三种限流算法怎么选

结论：对外暴露的读接口优先选令牌桶或滑动窗口；向下游写库、发消息的环节优先选漏桶。

三、单机限流：Guava RateLimiter 示例

单机部署或开发联调阶段，Guava 的 RateLimiter 足够用。以下为示例配置（阈值请按容量评估结果填写）：

// 示例配置：单机每秒放行 200 个许可，预热 3 秒
RateLimiter limiter = RateLimiter.create(200.0, 3, TimeUnit.SECONDS);

public Response queryOrder(String orderId) {
    if (!limiter.tryAcquire(1, 100, TimeUnit.MILLISECONDS)) {
        return Response.rateLimited("系统繁忙，请稍后重试");
    }
    return orderService.query(orderId);
}

注意两点：第一，tryAcquire 一定要带超时，避免请求在排队中耗尽等待时间；第二，RateLimiter 是单机内存状态，多副本部署时总放行量等于副本数乘以单机阈值，网关层必须再做一次全局限流。

四、分布式限流：Redis + Lua 令牌桶

多副本部署是企业级后端的常态，全局限流必须放在共享存储上。Redis + Lua 脚本可以把“取令牌、扣减、返回剩余量”做成一次原子操作，避免并发下的超发。

-- 示例 Lua 脚本：每秒补充 1000 个令牌，桶容量 2000（示例值）
local key = KEYS[1]
local now = tonumber(ARGV[1])
local rate = 1000
local capacity = 2000
local last = tonumber(redis.call('hget', key, 'last') or now)
local tokens = tonumber(redis.call('hget', key, 'tokens') or capacity)
tokens = math.min(capacity, tokens + (now - last) * rate / 1000)
if tokens < 1 then return 0 end
redis.call('hset', key, 'tokens', tokens - 1, 'last', now)
redis.call('pexpire', key, 10000)
return 1

Java 侧用 StringRedisTemplate 执行脚本，返回 0 即触发限流。这套方案在示例压测中表现稳定（压测数据为示例数据）：4 核 8G 的示例网关节点（示例配置）可支撑约 2 万 QPS 的限流判断（示例数据），单次 Lua 执行耗时在 1ms 以内（示例数据）。

五、熔断降级：Sentinel 规则这样配

以阿里 Sentinel 为例，推荐从“慢调用比例”熔断起步，而不是错误数熔断——慢调用是后端雪崩更常见的导火索。以下为示例规则（阈值请按接口基线填写）：

// 示例规则：统计窗口 10 秒，最小请求数 20，慢调用比例超 50% 则熔断 30 秒
DegradeRule rule = new DegradeRule("queryOrder")
        .setGrade(RuleConstant.DEGRADE_GRADE_RT)
        .setCount(200)              // 慢调用阈值 200ms（示例值）
        .setSlowRatioThreshold(0.5)
        .setMinRequestAmount(20)
        .setStatIntervalMs(10000)
        .setTimeWindow(30);
DegradeRuleManager.loadRules(Collections.singletonList(rule));

熔断打开期间接口直接走降级逻辑：读接口返回缓存兜底数据或友好提示，写接口返回“稍后重试”并记录补偿任务。熔断不是终点，半开探测恢复后要逐步放量，Sentinel 的半开探测请求数默认 1 个，可按接口重要性调整。

六、示例压测数据（以下均为示例数据，非真实生产指标）

以上数字来自示例环境（示例配置：2 台 4 核 8G 示例节点、示例流量模型），仅用于说明防护组合的效果量级；实际容量请以自身压测为准。

七、上线前的检查清单

1. 限流阈值按单接口容量评估填写，禁止全站共用一个阈值。
2. 被限流与被熔断的请求返回统一错误码（如 429 / 503），并在响应头中给出建议重试时间。
3. 限流、熔断事件接入监控与告警：触发次数、熔断时长、降级成功率三项指标缺一不可。
4. 降级分支必须有自动化测试覆盖，禁止“降级代码上线后从未跑通过”。
5. 大促前做一次真实的限流演练：逐步加压，确认阈值生效、监控告警、降级链路三者同时工作。

结语

限流决定系统能接多少流量，熔断决定系统在出问题时能保住多少核心能力。把令牌桶放在网关、把慢调用熔断放在核心接口、把降级写进自动化测试，这三件事做完，企业级 Java 后端才算真正有了流量防线。