Spring Boot 3响应式编程实战：WebFlux背压与线程模型解析

响应式编程是Spring Boot 3高并发设计的重要方向。WebFlux基于Reactor实现了非阻塞IO与背压（Backpressure）机制，在IO密集、连接数多的场景下能以远低于传统Servlet线程池的资源消耗支撑高并发。本文从线程模型差异、WebFlux入门实现、背压控制三个层面，说明Spring Boot 3中WebFlux的实际应用。

Servlet线程模型与WebFlux的对比

传统Spring MVC基于Servlet规范，每个请求占用一个线程，线程池耗尽时请求排队或直接拒绝。Tomcat默认200线程，支撑的并发连接数受限于线程数。WebFlux基于Reactive Streams与Netty，少量事件循环线程处理海量连接，请求处理不阻塞线程，等待IO时线程可以处理其他请求。

线程模型对比如下：

Servlet (Tomcat):
  1 请求 -- 占用 1 线程，直到响应完成
  200 线程 = 最多 200 个并发请求（阻塞型）

WebFlux (Netty):
  事件循环线程处理连接与分发（默认 CPU核数×2）
  业务逻辑通过异步回调/Reactor算子执行，不占用独立线程
  数万并发连接也可由少量线程支撑

选型原则：业务逻辑是CPU密集或强同步（JDBC直连、本地事务），MVC更合适；逻辑是IO密集（网关聚合、RPC转发、SSE推送）、需要高连接数，WebFlux更有优势。

Spring Boot 3 WebFlux响应式接口开发

WebFlux用Mono（0或1个元素）与Flux（0到N个元素）表达异步结果。Controller层直接返回响应式类型，配合ReactiveRepository与ReactiveMongoTemplate可把链路全部非阻塞化：

@RestController
@RequestMapping("/api/orders")
public class OrderController {
    private final OrderReactiveRepository repo;
    private final UserClient userClient;

    @GetMapping("/{id}")
    public Mono<OrderDetailVO> getOrder(@PathVariable String id) {
        return repo.findById(id)
            .switchIfEmpty(Mono.error(new OrderNotFoundException(id)))
            .flatMap(order ->
                userClient.getUser(order.getUserId())
                    .map(user -> OrderDetailVO.of(order, user))
            );
    }

    @GetMapping("/stream")
    public Flux<OrderVO> streamOrders() {
        return repo.findTop100ByStatus("PAID");
    }
}

flatMap把异步依赖串联，避免回调嵌套；switchIfEmpty处理查无数据。注意不要在响应式链中调用阻塞方法，包括Thread.sleep、synchronized、JDBC、HttpClient同步调用，这些会让事件循环线程被卡死，把整个应用的吞吐拖垮。

背压机制与限流策略

背压是响应式编程的核心：消费者处理速度跟不上生产者时，通过信号反向控制数据流速。WebFlux的默认背压实现是Reactor的request(n)机制，下游每消费n个元素，上游才继续推送n个。用Flowable风格的边界也能在业务层做显式限流：

// Flux 的背压处理：只订阅前100个元素
flux.publishOn(Schedulers.boundedElastic(), 8)
    .take(100)
    .doOnNext(item -> log.info("process: {}", item))
    .doOnComplete(() -> log.info("done"))
    .subscribe();

// 模拟慢消费者：每处理一条暂停50ms，验证背压
flux.doOnNext(item -> {
        process(item);
        sleep(50);
    })
    .onBackpressureBuffer(1024)       // 缓冲策略
    .subscribe();

onBackpressureBuffer/onBackpressureDrop/onBackpressureLatest是三个常用策略：缓冲适合可延迟处理的数据，丢弃适合实时指标，Latest只保留最新值适合状态快照。与外部系统（消息队列、下游HTTP服务）对接时，把R2DBC/Kafka/WebClient的并发度与连接池大小对齐，避免背压信号无法到达。

响应式数据库访问与事务边界

JDBC是阻塞IO，必须改用R2DBC才能保持全链路非阻塞。Spring Data R2DBC与JDBC API类似：

@Repository
public interface OrderReactiveRepository extends ReactiveCrudRepository<Order, String> {
    @Query("SELECT * FROM orders WHERE user_id = :userId AND status = :status")
    Flux<Order> findByUserIdAndStatus(@Param("userId") String userId,
                                      @Param("status") String status);
}

R2DBC的事务与WebFlux集成：推荐用ReactiveTransactionManager + TransactionalOperator，事务内链式方法会在事务上下文提交/回滚。需要留意：默认传播行为与JDBC事务一致，但参与事务的数据库连接来自R2DBC连接池，连接池大小要按并发连接估算，配置太小时会出现连接获取等待。

WebFlux与阻塞组件的共存策略

存量系统里WebFlux与Servlet阻塞代码不可避免共存。三种做法：

• WebFlux中调用阻塞客户端：用block()必须搭配boundedElastic调度器，避免阻塞事件循环线程
• 整链路替换：网关、缓存、DB客户端全部换成非阻塞版本，适合新建项目
• 两者并存：SpringBoot同时配MVC与WebFlux时，默认MVC生效，需明确以WebFlux启动

典型混合写法：

Mono.fromCallable(() -> legacyJdbcService.query(userId))
    .subscribeOn(Schedulers.boundedElastic())
    .map(convert)
    .flatMap(reactiveRepo::save);

WebFlux的适用边界是IO密集与高连接数场景，引入前先评估业务里阻塞调用的比例，把阻塞点全部转移到boundedElastic线程池再谈全链路非阻塞。架构上把MVC与WebFlux共存作为过渡，逐步替换，比一次性推倒重来更稳妥。