响应式编程Reactor的背压机制解析

从一次“雪崩”说起

用过WebFlux或RSocket的同学，大概率都遇到过这样的场景：下游消费者处理得慢吞吞，上游生产者却像永动机一样拼命发射数据。内存被塞满，GC频繁报警，最后应用直接宕机——这就是典型的背压缺失引发的“响应式雪崩”。本质上，背压不是某种“优化技巧”，而是响应式编程区别于传统异步回调的核心契约：它让数据流动的速度由最慢的一环说了算。

Reactor作为响应式流的JVM实现，将背压建模为一个显式的、可协商的“需求信号”。生产者不会盲目推送，而是等待下游请求（request(n)），然后仅发射n个元素。这个机制看似简单，但真要落地到代码里，很多坑都藏在“操作符如何传递背压”和“缓冲/丢弃策略如何选择”这两层。

背压的协议与线程模型

先理清最底层的东西：Publisher和Subscriber之间的交互，完全依赖于Subscription接口。当Subscriber调用subscription.request(1)，上游才知道“哦，你消化得动一个”，于是发送一个。如果下游不请求，上游就停在原地。这种拉模式的优雅之处在于，它把“流速控制权”归还给了消费者。

但Reactor是个异步引擎，它内部大量使用队列和调度器。背压信号不是直接穿透的，而是经过操作符的“再翻译”。比如map很简单，上游发多少它转多少；但flatMap就复杂了——它内部会为每个来源创建独立的Subscriber，并通过一个合并队列把结果回传给下游。上游的背压信号到达flatMap时，会被“预取”优化掉一部分：默认flatMap会从每个内层流请求QueueSize.SMALL_BUFFER_SIZE（256个）数据，这就形成了一种“批次拉取”，而非严格的逐个请求。

所以，别被“背压能防止OOM”这类话术欺骗。背压只能在上游尊重request(n)、且操作符不做无限缓冲时才能真正控制内存。如果写代码时不加限制地使用flatMap且不配置maxConcurrency，或者用了limitRate却把吞吐量调得过高，背压照样会被“战略性忽略”。

操作符的背压语义：缓冲、丢弃、或让线程等待

Reactor里，处理溢出有三种典型策略，对应完全不同的使用场景：

缓冲（Buffered）：默认策略。当下游跟不上时，元素会堆进一个无界或固定大小的队列。例如onBackpressureBuffer(1000)之后虽然限制了容量，但队列扔满后抛异常，这其实只解决了“无限增长”问题，没解决“下游瘫痪”问题。现实中，配合bufferTimeout可以做到“积攒一批再发”，但如果生产速率远超消费速率，容量迟早被击穿。

丢弃（Drop）：onBackpressureDrop 直接扔掉来不及处理的元素。这在物联网传感器读数或高频行情数据里很常见——“丢掉最新一个，反正下一个马上到”。注意，丢的是“处理策略发生时的那个元素”，消费者依然能保持自己的节奏。

错误或“熔断”：onBackpressureError会抛出一个Exceptions.failWithOverflow，相当于告诉上游“我不行了，别再发了”。适合那些数据不可丢、不可重试，但必须快速fail-fast的场景。

还有一个容易被忽略的操作符：limitRate。它其实是背压的“动态阀门”，把下游的request(n)拆成小批量请求，并允许在每批内部预取一部分以保证吞吐。比如limitRate(100)会让下游首轮请求100个，之后每次都等当前批消耗到75%时才请求下一批的100个，避免拉取太频繁带来的线程唤醒开销。

混用不同背压策略的实践陷阱

很多人是在写“混合响应式链路”时踩到背压坑的。典型场景：外层是Spring WebFlux的Flux，内层调用了外部的阻塞REST服务。如果直接把阻塞调用包进flatMap，那么背压只能控制“请求的发起速率”，却控制不了线程池里堆积的任务数。线程池队列无限，照样OOM。

正确姿势是给阻塞调用套上隔离的Scheduler，并用flatMap的maxConcurrency来限制同时进行的阻塞调用数。这本质上是人为把背压从“数据层面”转换成了“并发窗口层面”。再看merge和zip的区别：merge的背压取决于下游请求量，但每个内层流都可能独立预取；zip则必须等待最慢的那个流，它天然会把背压传导到所有上游。

让我贴一个简单的对比，帮助理解缓冲和丢弃的代价差异：

// 缓冲策略：最多缓冲100，超出抛异常
Flux.range(1, 1_000_000)
    .onBackpressureBuffer(100, BufferOverflowStrategy.ERROR)
    .subscribe(slowConsumer);

// 丢弃策略：只跟得上10%，丢掉其余90%
Flux.interval(Duration.ofMillis(1))
    .onBackpressureDrop()
    .subscribe(slowConsumer);

第一个例子中消费者如果只请求1个却缓冲100，那剩下的99个要么一直占内存，要么在缓冲满时直接报错。第二个例子则完全不用内存，但代价是数据的“不可恢复”。选哪种，本质上是在问：你的业务能接受“延迟交付”还是“部分丢失”？

背压不是银弹，但它是元能力

笔者在维护一套基于Reactor的消息处理管道时，曾经天真地以为所有操作符都自动支持背压。直到某天上游从Kafka拉取50万条消息，经过三个flatMap和一个delayElements后把数据库连接池打崩了。事后分析发现，delayElements用的是parallel()调度器，内部使用了一个溢出缓冲为FluxSink.OverflowStrategy.BUFFER的队列——它完全绕过了下游的背压。这提醒我们：**背压的传播链条中，只要有一个操作符（或自定义的Sink）没有正确传递request(n)，整个机制就会失效**。

所以，真正的背压工程实践，应该是先明确下游的真实消费能力，再沿着链路逐个操作符检查其“对待需求信号的翻译方式”，必要时手动调用onBackpressureXxx补充策略。Reactor给了我们可视化的stepVerifier和log()，但工具终究是辅助，理解“谁在向谁请求”才是解开背压谜题的钥匙。

后记：从“防御”到“设计”

如果单纯把背压当成防止崩溃的保护伞，你就只能写出“满则报错”的粗放代码。当你意识到背压其实是一种通信协议，它让生产者和消费者可以协商节奏，你就能设计出更加平滑的系统：缓慢的消费者通知上游减少批次，空闲的消费者请求下一轮数据，甚至可以根据下游的实时负荷动态调整limitRate的系数。响应式编程的优雅从来不是没有等待和排队，而是让每一次等待都变得有意义，让每一次推送都有据可依。这才是背压机制真正值得深挖的魅力所在。