背压与限流

下游处理不过来时，系统不能无限堆积请求。背压（Backpressure） 让慢的消费者反过来告诉生产者「慢一点」；限流（Throttling） 在入口拒绝超额流量。二者是 building-for-scale 的「刹车系统」，与 reliability-essentials 的稳定性实践一脉相承。

学习目标

• 区分背压、限流、熔断、降级的触发点与协作关系
• 实现令牌桶/漏桶限流，并选择合适的拒绝策略
• 为线程池、连接池、消息队列配置有界队列

核心概念

机制	作用位置	行为
限流	网关 / API 入口	超配额返回 429
背压	管道中间	阻塞或 drop 上游发送
熔断	调用下游	快速失败，防雪崩
降级	业务层	返回兜底数据

突发 10k QPS → 网关限流 1k → 服务线程池 200 → DB 连接池 50
                ↓ 429           ↓ 排队/拒绝      ↓ 等待超时

常见限流算法：

• 令牌桶：允许一定突发，平滑平均速率（Guava RateLimiter）
• 漏桶：输出恒定，削平峰值
• 滑动窗口：按秒/分钟计数，适合 API 配额

// 伪代码：有界队列 + CallerRunsPolicy 形成背压
new ThreadPoolExecutor(core, max, queue=new ArrayBlockingQueue<>(100),
    new ThreadPoolExecutor.CallerRunsPolicy());

拒绝策略要可观测：返回 429 + Retry-After 头，记录 metric rate_limit_rejected_total。与 nginx-essentials 的 limit_req 配合做边缘限流。

练习

• 为一个公开 API 设计 100 QPS 全局限流 + 每用户 10 QPS
• 检查项目线程池是否无界队列——若有，改为有界并压测
• 阅读 reliability-essentials，画出熔断与限流在调用链上的位置

小结

扩展的上限由最慢环节决定——限流与背压让系统在过载时可控失败，而不是静默崩溃。