在高并发场景中，API服务面临着流量突增和依赖故障的双重压力。限流和熔断机制作为服务保护的两大核心策略，能够有效防止系统过载和级联故障，是保障API服务稳定性的关键手段。本文将从算法选型到工程落地，系统讲解限流熔断的实践方案。
限流算法对比与选择
常见的限流算法有四种，各有适用场景。固定窗口算法实现简单，在时间窗口边界处可能出现双倍流量问题。滑动窗口算法通过将窗口细分为多个小格子，平滑了边界效应，精度更高。令牌桶算法以固定速率向桶中放入令牌，请求消耗令牌，支持突发流量但总体速率可控，适合大多数API限流场景。漏桶算法则以固定速率处理请求，多余的请求排队或丢弃，适合需要严格匀速的场景。在工程实现中，限流通常基于Redis实现分布式计数，保证多节点一致性。限流粒度可以按用户、按接口、按服务维度设置，建议采用多级限流策略，全局限流兜底，细粒度限流精确控制。限流触发后应返回标准化的错误响应，携带重试建议时间，帮助客户端优雅处理。除了固定阈值限流外，还可以结合系统负载指标实现自适应限流，当CPU或内存使用率超过阈值时动态调低限流上限，系统空闲时适当调高，实现资源利用率与稳定性的平衡。对于不同的接口等级，应设置差异化的限流策略，核心接口给予更高的流量配额，非核心接口在压力较大时优先限流。
熔断器设计原理
熔断器借鉴了电路中保险丝的概念，当下游服务故障率达到阈值时自动切断请求，防止级联故障蔓延。熔断器有三个状态：关闭、打开和半开。关闭状态下请求正常通过，同时统计失败率。当失败率超过设定阈值时，熔断器进入打开状态，所有请求快速失败，不再调用下游服务。经过一段冷却时间后，熔断器进入半开状态，允许少量请求通过以探测下游恢复情况。若探测成功则回到关闭状态，否则重新打开。阈值设置需要根据业务特性调整，常见的配置是十秒内失败率超过百分之五十即熔断，冷却时间三十秒。熔断器应针对不同的下游服务独立配置，避免一个服务故障导致全局熔断。在微服务架构中，建议在服务调用客户端中集成熔断器，实现细粒度的故障隔离。熔断器的状态变更应当广播到监控系统，运维人员需要实时感知熔断事件，以及时排查下游故障根因。半开状态的探测请求数量需要严格控制，过少则不准确，过多则可能对未恢复的服务造成二次压力。
降级策略与服务恢复
当限流或熔断触发时，需要有配套的降级策略来保障用户体验。降级方式包括返回缓存数据、返回默认值、返回简化结果和异步处理等。对于核心功能，降级应当保持基本可用性，而非直接报错。服务恢复阶段，需要逐步放开流量，避免恢复瞬间流量涌入造成二次故障。完善的监控告警体系是限流熔断有效运行的基础，需实时监控请求量、失败率和熔断状态等指标。