高并发场景下API必须有自我保护机制。限流控制请求速率防止服务过载，熔断在依赖故障时快速失败防止故障扩散。本文详细讲解限流熔断的核心算法和工程实现方案。
限流算法对比
计数器算法：在时间窗口内计数，超过阈值则拒绝。实现简单但有临界问题，可能在窗口边界出现双倍流量。滑动窗口算法：将时间窗口细分为多个小格子，解决临界问题。令牌桶算法：匀速放入令牌，请求消耗令牌，允许突发流量，最常用。漏桶算法：请求以固定速率流出，强制平滑流量。选型建议：需要允许突发用令牌桶，需要严格限速用漏桶。
分布式限流方案
单机限流可以用Guava RateLimiter，分布式限流需要集中式计数器。Redis实现分布式限流：用INCR和EXPIRE命令实现滑动窗口，用Lua脚本实现令牌桶算法保证原子性。Sentinel和Redisson都提供了成熟的分布式限流实现。限流粒度可以是全局限量、用户级、IP级或API级。不同粒度的限流组合使用，粗粒度兜底，细粒度精确控制。
熔断器模式
熔断器有三种状态：关闭、打开和半开。关闭状态正常调用，错误率达到阈值时熔断器打开。打开状态直接快速失败，不发起真实调用。半开状态允许少量请求通过测试，成功则关闭熔断器，失败则继续保持打开。熔断器配置三个核心参数：错误率阈值（如50%）、最小请求数（如5个）、熔断时长（如10秒）。熔断后要提供降级逻辑返回默认值或缓存数据。
限流熔断实战配置
生产环境限流熔断配置需要根据业务特点调整。限流阈值参考API的TP99响应时间和服务器的处理能力。熔断阈值参考下游服务的可用性SLA。配置可以动态调整，不需要重启服务。监控限流熔断的触发次数，频繁触发说明系统容量不足需要扩容。限流熔断要配合降级逻辑一起使用，让用户体验尽可能好。合理的做法是限流时返回友好的提示信息和建议重试时间。