高并发保护实战：限流、熔断、降级如何配合落地

高并发系统的稳定性，不取决于单个组件多强，而取决于"保护策略是否成体系"。

很多团队有了限流，却没有熔断；有了熔断，却没有降级；最后线上仍然出现级联故障。

本文聚焦三件事：什么时候限流、什么时候熔断、什么时候降级。

【场景：下游抖动引发全链路超时】

常见故障链路：

下游服务 RT 变高。
上游线程池被阻塞。
重试放大流量，连接池耗尽。
核心接口被拖垮。

这类问题的本质是"没有在边界处阻断故障传播"。

【策略1：限流（控制入口流量）】

限流用于"系统还活着，但流量超出处理能力"。

常见算法：

固定窗口：实现简单，但边界抖动明显
滑动窗口：更平滑
令牌桶：支持突发流量，工程上最常见

java 复制代码

if (!tokenBucket.tryAcquire()) {
    return ApiResponse.fail("请求过多，请稍后重试");
}

实践建议：

按接口分级限流（核心接口优先）
按租户/用户限流，避免单点挤占
为限流拒绝打独立指标

【策略2：熔断（隔离不稳定依赖）】

熔断用于"下游已经不稳定，继续调用只会扩大损失"。

状态机：

Closed：正常放行
Open：快速失败
Half-Open：小流量探测恢复

java 复制代码

if (breaker.isOpen("payment-service")) {
    return fallback("支付服务繁忙，请稍后重试");
}

try {
    return paymentClient.pay(req);
} catch (Exception ex) {
    breaker.recordFailure("payment-service");
    throw ex;
}

实践建议：

熔断粒度按"依赖服务 + 接口"划分
熔断阈值按错误率和慢调用率双维度设置
半开探测流量要严格受控

【策略3：降级（保证核心功能可用）】

降级用于"资源不足时优先保核心路径"。

示例：

推荐/评论可降级
下单/支付不可降级

java 复制代码

if (systemLoad.high()) {
   return ApiResponse.ok("降级返回", cachedSummaryData);
}

实践建议：

先定义业务优先级（核心、重要、可延后）
每个服务要有明确降级开关
降级结果要可观测，不可"静默失败"

【组合策略：先限流，再熔断，最后降级】

可复用链路：

java 复制代码

public Result handle(Request req) {
  if (!rateLimiter.allow(req.api(), req.userId())) return rejected();
  if (breaker.isOpen(req.dependency())) return degraded();
  try {
    return invokeDownstream(req);
  } catch (Exception e) {
    breaker.recordFailure(req.dependency());
    return degraded();
  }
}

这套顺序的目标是：

限流挡住外部压力
熔断隔离内部故障
降级保证核心可用

【稳定性治理检查清单】

入口是否有分级限流？
关键依赖是否配置熔断与半开探测？
是否定义了业务降级优先级？
降级是否有明确返回策略？
是否有拒绝率、熔断率、降级率监控？
是否做过压测和故障演练？

下期预告：

《Kafka vs RabbitMQ：消息队列选型的决策框架》