在构建高并发、高可用的后端系统时，流量控制与容错机制变得尤为重要。限流（Rate Limiting）和熔断（Circuit Breaking）作为常见的防护机制，能有效避免系统因负载过高而崩溃。虽然这两个概念被广泛讨论，但其实现细节和应用场景却不为所有开发者熟知。本文将带你深入了解限流与熔断的工作原理及应用场景。
限流：控制请求频率
限流的目的是通过限制单位时间内某个资源的访问频率，防止资源被过度占用。常见的限流策略有：
- 令牌桶算法（Token Bucket）
令牌桶算法控制请求的速率，允许突发流量，但总的请求量有限制。每次请求需要获得一个令牌，令牌以固定速率生成。 - 漏桶算法（Leaky Bucket）
漏桶算法则通过持续以固定速率处理请求，确保请求量平稳输出。 - 计数器限流（Fixed Window）
每个时间窗口内允许一定数量的请求，超出则拒绝。 - 滑动窗口限流（Sliding Window）
对请求进行时间窗口滑动，灵活调整频率，适应不同的流量模式。
熔断：避免雪崩效应
熔断机制用于防止服务由于连续失败而陷入恶性循环，导致系统整体崩溃。其工作原理类似于电路中的熔断器：当服务连续出现故障，熔断器触发，切断请求的传递，直到服务恢复正常。
常见的熔断策略：
- 失败计数法
在规定的时间窗口内，如果请求失败的比例超过某个阈值，则开启熔断。 - 超时和重试
设置请求超时阈值，超时的请求直接进入熔断状态，避免重复提交请求。 - 半开状态
熔断器触发后，系统会以半开状态接收请求，尝试检测系统是否恢复，逐步放开流量。
限流与熔断的结合应用
限流与熔断机制通常联合使用，保证系统在高并发下的稳定性：
- 限流：确保每个用户或每个服务实例的请求不会超过服务承载能力。
- 熔断：在流量突然剧增时，保护系统免受过多失败的请求。
应用场景
- API网关：控制外部API请求的速率，避免因恶意攻击或流量激增导致后端服务崩溃。
- 微服务架构：各个微服务之间的流量控制，防止单个服务的失败引发级联故障。
- 第三方服务调用：当依赖外部服务时，通过熔断避免由于外部服务不可用引发的故障。
挑战与注意事项
- 配置优化：限流和熔断的阈值需要根据实际流量和服务能力进行精细调整，过于严格会导致服务可用性下降，过于宽松则无法有效保护系统。
- 监控与报警：熔断器触发或限流超标时需要及时报警，方便开发者快速响应。
- 集成与兼容性：在现有的后端架构中引入这些机制可能需要较大的改动，尤其是高并发系统中需要避免额外的性能损失。
