凌晨两点，商品中心的告警又响了。库存变更接口被前端轮询疯狂调用，数据库连接池直接被打满，MongoDB 主节点 CPU 飙到 90%。我是老李，一个在电商后端摸爬滚打十年的老兵。最近我在改造商品实时更新链路时，被一个问题卡了很久：为什么 Spring Data MongoDB 明明支持响应式，可我把返回值从 List 换成 Mono 之后，性能没提升，反而线上堆栈更难排查了？

这个问题不是个例。很多团队一听到响应式，就以为把同步方法改成返回 Mono 或 Flux 就是性能银弹，结果掉进坑里。今天我们就着 Spring Data MongoDB 这个话题，把响应式的适用场景、底层原理和真实落地说清楚。

现在为什么要讲？因为实时化需求越来越普遍：商品库存、价格、订单状态等都要秒级推送，Change Stream 已经从备选方案变成常见方案。如果还抱着传统的同步轮询，出问题是早晚的事。

## 01、痛点
先看两个典型场景。

第一个场景：商品实时更新。电商大促期间，库存变化要同步到详情页、搜索页、推荐位。传统做法是前端每 3 秒轮询一次商品接口，后端每次查询 MongoDB，返回最新库存。平时没问题，一旦并发上来，轮询请求会迅速占满 Tomcat 线程池。每个线程都在等数据库返回，数据库连接池也被占满，后续请求排队，雪球越滚越大。更要命的是，实时性其实很差：前端 3 秒一次，用户看到的库存永远慢半拍，超卖风险只能靠别的手段兜底。

第二个场景：普通 CRUD 管理后台。运营人员用的商品管理、分类管理、订单查询，一天没多少请求，逻辑简单，用同步 MongoTemplate 或 MongoRepository 写起来清晰好维护。如果把这些接口也全部改成响应式，代码里到处是 map、flatMap、subscribe，调试时堆栈信息一长串，团队新成员根本看不懂。更糟的是，如果底层还在用同步驱动，或者业务里混了阻塞调用，响应式不仅没收益，还会让性能更差。

所以痛点不是“该不该用响应式”，而是“在哪里用、怎么用”。盲目全量响应式，和死守同步轮询一样危险。

## 02、是什么
Spring Data MongoDB 同时提供两套编程模型：同步的 MongoTemplate 和 MongoRepository，以及响应式的 ReactiveMongoTemplate 和 ReactiveMongoRepository。响应式这套底层基于 MongoDB Reactive Streams Driver，而不是传统的阻塞驱动。

核心概念有三个。

第一，Mono。表示 0 到 1 个元素的异步序列。比如根据 id 查询单个商品，返回 Mono<Product>。

第二，Flux。表示 0 到 N 个元素的异步序列。比如查询库存大于 100 的商品列表，返回 Flux<Product>；或者监听 Change Stream，返回一个不会结束的 Flux<ChangeStreamEvent<Product>>。

第三，Backpressure，背压。这是响应式流的关键机制。订阅者可以根据自己的处理能力，告诉上游“我一次只能处理 5 条”，上游就按需发送，不会一下子把数据全推过来导致内存溢出。在 Change Stream 这种无限流里，背压尤其重要。

Reactive Repository 的写法很直接：

public interface ProductReactiveRepository extends ReactiveMongoRepository<Product, String> {
    Flux<Product> findByStockGreaterThan(int stock);
}

ReactiveMongoTemplate 则提供更底层的操作，比如 changeStream、bulk 操作等。两者并不是替代关系，日常查询用 Reactive Repository 更简洁，复杂变更场景用 ReactiveMongoTemplate 更灵活。

## 03、为什么
很多人以为响应式快，是因为把返回值从 List 换成了 Flux。这是最大的误解。

响应式的收益来自端到端非阻塞，而不是返回值类型本身。所谓端到端非阻塞，是指从 HTTP 接入、业务处理、到数据库驱动，整条链路都不阻塞线程。以 WebFlux + MongoDB Reactive Streams Driver 为例，请求进来后由 Netty 的事件循环线程处理，查询 MongoDB 时不会让线程傻等，而是注册回调，等数据返回后继续处理。这样少量线程就能支撑大量并发连接。

对比传统阻塞模型，Tomcat 一般只有 200 个线程，200 个用户同时查询商品，线程池就满了。如果数据库查询耗时 50ms，每个线程有 50ms 处于阻塞等待，CPU 利用率很低。响应式模型下，同样 200 个并发，可能只需要 4 个事件循环线程，因为线程不会阻塞，可以快速切换处理其他请求。

但如果只是把 Controller 返回值改成 Mono，而内部还在使用同步 MongoTemplate，或者调用阻塞的 JDBC，线程依然被占住，性能不会提升，甚至因为线程切换更频繁而下降。所以 Mono 不是性能银弹，端到端非阻塞才是。

再往深一层，响应式的收益主要体现在三类场景：高并发 I/O、流式推送、持续事件流。比如商品实时更新，前端用 SSE 长连接接收 Flux，服务端用 Change Stream 订阅 MongoDB 变更，数据有变化就推一条，不用前端轮询，也不需要后端开几百个线程去查库。这种场景下，响应式是天然匹配的。

## 04、架构
整体链路可以这样理解：

前端浏览器或客户端 -> HTTP/SSE -> WebFlux Controller -> Service 层（返回 Flux）-> ReactiveMongoRepository 或 ReactiveMongoTemplate -> MongoDB Reactive Streams Driver -> MongoDB Server

关键点在于每一环都必须非阻塞。如果 Service 层里写了一个 Thread.sleep 或者调用了一个阻塞的 HTTP 客户端，链路就被打断了。

事件循环模型：WebFlux 底层基于 Netty，用少量 event loop 线程监听连接、读写数据。当请求到达时，event loop 线程执行 Controller 和 Service 的逻辑，遇到数据库查询时，把操作交给 MongoDB Reactive Streams Driver，并注册回调，然后立刻返回去处理其他请求。数据返回后，event loop 线程再继续处理，把结果写回客户端。

背压在这个链路里怎么传？假设 Change Stream 每秒产生 1000 条商品变更，而客户端只处理得动 100 条，客户端会通过 SSE 连接向上游反馈“我处理不过来了”。Flux 的背压机制会把信号从 Controller 传到 Service，再传到 ReactiveMongoTemplate，最终到 MongoDB 驱动，驱动可以暂停从游标读取，数据不会在内存里堆积。

Change Stream 的本质是 MongoDB 复制集或分片集群的 oplog 订阅。它把数据变更事件变成一个可以持续读取的流，天然适合用 Flux 表达。这也是为什么商品实时更新接口用 Change Stream + Flux 会比轮询优雅得多。

## 05、实战
下面我们做一个商品实时更新接口的最小实现。

第一步，引入依赖：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-mongodb-reactive</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>

第二步，配置 MongoDB 连接。application.yml 里写：

spring:
  data:
    mongodb:
      uri: mongodb://localhost:27017/shop

第三步，定义商品文档：

@Document
public class Product {
    @Id
    private String id;
    private String name;
    private BigDecimal price;
    private Integer stock;
    // 省略 getter 和 setter
}

第四步，声明响应式 Repository：

public interface ProductReactiveRepository extends ReactiveMongoRepository<Product, String> {
    Flux<Product> findByStockGreaterThan(int stock);
}

第五步，写一个 SSE 实时流接口，用 ReactiveMongoTemplate 监听 Change Stream：

@RestController
public class ProductStreamController {

    private final ReactiveMongoTemplate reactiveMongoTemplate;

    public ProductStreamController(ReactiveMongoTemplate reactiveMongoTemplate) {
        this.reactiveMongoTemplate = reactiveMongoTemplate;
    }

    @GetMapping(value = "/products/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public Flux<ServerSentEvent<Product>> stream() {
        ChangeStreamOptions options = ChangeStreamOptions.builder()
                .returnFullDocumentOnUpdate()
                .build();
        return reactiveMongoTemplate.changeStream("products", options, Product.class)
                .map(event -> ServerSentEvent.builder(event.getBody()).build());
    }
}

前端只需要使用 EventSource 订阅 /products/stream，库存、价格或商品信息有变化，就会实时收到推送。相比轮询，连接数从每 3 秒一次变成一条长连接，数据库不再被轮询查询打爆，实时性也提升到秒级甚至更低。

有同学可能会问：Change Stream 需要 MongoDB 复制集，开发环境只有单节点怎么办？可以用单节点复制集的方式启动 MongoDB，比如 mongod --replSet rs0，然后执行 rs.initiate()。生产环境至少使用 3 节点复制集，才有高可用保障。

## 06、洞见
回到开头的问题：普通 CRUD 管理后台有没有必要全部 Reactive？

我的判断很明确：没有必要。

管理后台的特点是：用户量小、请求频率低、单次查询为主，同步代码的直白和可维护性远胜于响应式的异步链。用 Reactive 去写一个运营人员偶尔打开的分类管理接口，收益几乎为零，成本却很高。

响应式更适合高并发 I/O、Streaming 和持续事件流，而不是新的默认语法。它不是把 List 换成 Flux 就完事，而是一种架构选择。如果你决定用响应式，就要保证整条链路都是非阻塞的；如果做不到，比如还要调用老系统的阻塞 RPC，或者使用阻塞的 JDBC，那不如老老实实用同步。

另一个常见误区是：只要返回 Mono 就能提高吞吐。实际上，如果底层的 MongoDB 驱动还是同步的，或者查询本身很慢，Mono 只会让你多一层包装，问题照旧。响应式优化的是资源利用率和并发量，不是单次请求的响应时间。

所以选型时要问自己：这个接口是面对大量并发用户，还是少数内部用户？是需要持续推送，还是查一次就结束？答案不一样，技术选型就不一样。

## 07、行动
如果你想尝试，建议采用“保留同步 CRUD，只把 Change Stream/Streaming 场景改成 Reactive 做对比”的渐进式策略。

第一步，盘点系统中的接口。列出所有对外接口，标注请求量、实时性要求和数据访问方式。重点找出高并发查询、长连接推送、持续事件流这三类。

第二步，挑选一个 Change Stream 或流式场景做 POC。最好选痛点最明显的，比如商品库存变更推送、订单状态实时更新。用 ReactiveMongoTemplate 监听 Change Stream，前端改成 SSE 订阅。

第三步，做对比压测。在同样的业务场景下，分别用同步轮询和响应式推送跑压测，记录线程数、CPU 使用率、内存占用、GC 频率、平均延迟和数据库连接数。如果数据量不大，甚至可以只对比线程数和连接数。

第四步，根据压测结果决定是否推广。如果响应式方案在资源利用率和实时性上有明显优势，再逐步把其他流式场景迁过来。普通管理后台的同步 CRUD 保持不动。

第五步，团队内部定一个简单约定：Reactive 只用于端到端非阻塞链路，不要在响应式方法里混入阻塞调用。否则代码审查时很容易发现，但运行时排查起来非常痛苦。

## 08、小结
Spring Data MongoDB 的响应式栈给了我们一个强大工具，但它有自己的适用边界。Mono 和 Flux 不是性能银弹，Backpressure 不是摆设，端到端非阻塞才是收益来源。商品实时更新、Change Stream 这类流式场景，用 Flux 是顺理成章；而普通 CRUD 管理后台，保留同步代码反而更明智。

技术选型的成熟，不在于追新，而在于知道什么场景用什么工具。Reactive 应该在它擅长的地方发光，而不是成为团队的新负担。

## 09、链接与概念说明
概念说明：

Reactive Streams：一套异步流处理规范，定义了 Publisher、Subscriber、Subscription 和 Processor，核心是背压机制，解决异步数据处理时生产者速度超过消费者导致的内存溢出问题。

Project Reactor：Reactive Streams 的 Java 实现之一，提供 Mono 和 Flux 两个核心类型，是 Spring WebFlux 和 Spring Data Reactive 的默认响应式库。

MongoDB Reactive Streams Driver：MongoDB 官方的响应式驱动，基于 Reactive Streams 规范，底层使用非阻塞 I/O，是 Spring Data MongoDB 响应式栈的根基。

Change Stream：MongoDB 复制集和分片集群上提供的变更事件流，可以监听集合的插入、更新、删除等操作，基于 oplog，适合实时推送和同步。

推荐阅读：

Spring Data MongoDB 官方文档：https://docs.spring.io/spring-data/mongodb/docs/current/reference/html/

Project Reactor 参考文档：https://projectreactor.io/docs/core/release/reference/

Reactive Streams 规范：https://www.reactive-streams.org/

MongoDB Change Streams 文档：https://www.mongodb.com/docs/manual/changeStreams/

凌晨两点，商品中心的告警又响了。库存变更接口被前端轮询疯狂调用，数据库连接池直接被打满，MongoDB 主节点 CPU 飙到 90%。我是老李，一个在电商后端摸爬滚打十年的老兵。最近我在改造商品实时更新链路时，被一个问题卡了很久：为什么 Spring Data MongoDB 明明支持响应式，可我把返回值从 List 换成 Mono 之后，性能没提升，反而线上堆栈更难排查了？

《Spring Mongo实战》第16招 Reactive什么时候用

从商品实时更新场景切入，讲清 Spring Data MongoDB 响应式栈的适用边界：端到端非阻塞才有收益，管理后台同步 CRUD 不必全部改造。

架构师

数据库

后端

编程语言

SpringDataMongoDB响应式改造需端到端非阻塞，非仅改返回类型。高并发流式场景如ChangeStream推送适合Flux，普通CRUD宜保留同步。渐进式选型、压测验证，避免阻塞混用，才能发挥资源利用率优势。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring Mongo实战》第16招 Reactive什么时候用-腾讯云开发者社区-腾讯云

《Spring Mongo实战》第16招 Reactive什么时候用

《Spring Mongo实战》第16招 Reactive什么时候用

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐