背压是让系统在过载时有序应对的机制，核心是消费者主动声明处理能力，通过缓冲、丢弃、合并、限速等策略适配业务需求，并依赖底层支持与监控闭环。
背压不是用来“消除”过载的，而是让系统在过载时有秩序地应对——它把“来不及处理”变成一种可观察、可控制、可决策的状态。
理解背压的本质：从被动堆积到主动协商
传统异步任务中，生产者（如事件源、API调用、传感器）持续发数据，消费者（如处理器、数据库写入、UI更新）一旦变慢，数据就在内存里排队，越积越多，最终OOM或卡死。背压扭转了这个逻辑：消费者不再被动接收，而是主动说“我现在只能处理N个”，上游据此调节发送节奏。
关键在于三点：
- 数据流必须基于支持背压的协议（如 Reactive Streams、Channel、YieldStream）
- 消费者要能声明处理能力（例如调用 request(n) 或配置 BoundedChannelOptions.Capacity）
- 系统需明确“处理不过来时怎么办”——这决定了策略选型
按业务需求选对背压策略
没有万能策略，只有适配场景的选择。核心看三个问题：能不能丢数据？是否允许延迟？内存是否敏感？
-
缓冲（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<t>(new BoundedChannelOptions(100) { FullMode = BoundedChannelFullMode.Wait })</t>，否则默认无界，等于没背压 -
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秒），驱动扩容或优化消费者逻辑
