背压是让系统在过载时有序应对的机制，核心是消费者主动声明处理能力，通过缓冲、丢弃、合并、限速等策略适配业务需求，并依赖底层支持与监控闭环。

背压不是用来“消除”过载的，而是让系统在过载时有秩序地应对——它把“来不及处理”变成一种可观察、可控制、可决策的状态。

理解背压的本质：从被动堆积到主动协商

传统异步任务中，生产者（如事件源、API调用、传感器）持续发数据，消费者（如处理器、数据库写入、UI更新）一旦变慢，数据就在内存里排队，越积越多，最终OOM或卡死。背压扭转了这个逻辑：消费者不再被动接收，而是主动说“我现在只能处理N个”，上游据此调节发送节奏。

关键在于三点：

• 数据流必须基于支持背压的协议（如 Reactive Streams、Channel、YieldStream）
• 消费者要能声明处理能力（例如调用 request(n) 或配置 BoundedChannelOptions.Capacity）
• 系统需明确“处理不过来时怎么办”——这决定了策略选型

按业务需求选对背压策略

没有万能策略，只有适配场景的选择。核心看三个问题：能不能丢数据？是否允许延迟？内存是否敏感？

秘塔AI视频生成工具

一款支持文字及多种参考素材输入的在线AI视频生成工具。

下载

• 缓冲（Buffer）：适合突发但总量可控的场景（如批量导入）。用 .onBackpressureBuffer(1000) 或 buffers.fixed(50) 设上限，超限抛异常或阻塞写入
• 丢弃（Drop）：适合“最新才有效”的场景（如鼠标移动、实时行情）。用 .onBackpressureDrop() 或 buffers.dropping(3)，只留最近几条
• 合并（Conflate / Latest）：适合状态覆盖类操作（如搜索关键词、UI配置更新）。用 .conflate()（合并中间值）或 .collectLatest()（只处理最新一次）
• 限速（Limit Rate）：适合需稳定吞吐的后端服务。用 .limitRate(10) 或手动 request(1) 实现逐个拉取，彻底避免堆积

在不同技术栈中落地的关键点

背压能力依赖底层运行时和库的支持，不能只靠应用层代码“模拟”：

• Java/Reactor/RxJava：优先用 Flux 而非 Observable；订阅时用 BaseSubscriber 精确控制 request()，避免默认无限请求
• .NET Channel：创建时必须用 Channel.CreateBounded(new BoundedChannelOptions(100) { FullMode = BoundedChannelFullMode.Wait })，否则默认无界，等于没背压
• Redux-Saga：用 actionChannel(type, buffers.xxx()) 替代普通 take，通道本身承担缓冲与丢弃逻辑
• Fuel Core / Rust流：靠 YieldStream 主动让出控制权 + AsyncProcessor 信号量控并发，实现CPU和I/O双维度节流

别忘了监控和反馈闭环

背压本身是保护机制，但持续高背压说明系统瓶颈真实存在。仅靠策略不够，还需可观测性：

• 在Flink中看 Web UI 的 Back-Pressure 指标条（黄色/红色表示压力）
• 在Reactor中启用 Metrics 记录 reactor.flow.buffer.size 和 reactor.flow.drop.count
• 在Channel中监听 Writer.WaitCount 或自定义计数器，判断是否长期处于等待状态
• 把背压指标接入告警（如缓冲区使用率 > 90% 持续30秒），驱动扩容或优化消费者逻辑