1. 项目背景与核心挑战
外卖平台的"霸王餐"活动一直是吸引用户参与的热门营销手段。这类活动通常采用限量抢购模式，比如每天放出100个免费试吃名额，用户需要在指定时间内完成抢购。我们团队负责的API服务最初基于传统的Servlet模型开发，但在实际运营中遇到了严重的性能瓶颈。
最典型的场景出现在"实时试吃名额监控"功能上。当剩余名额低于10%时，系统需要实时推送通知给所有在线用户。在传统Servlet架构下，每当名额变化时，服务器需要为每个在线用户创建一个独立线程处理推送请求。在高峰期，这会导致线程池迅速耗尽，甚至引发OOM（内存不足）错误。我们曾记录到，在5万并发用户场景下，系统响应时间从正常的200ms飙升到8秒以上，严重影响了用户体验。
2. 技术选型：WebFlux的响应式优势
2.1 传统Servlet模型的局限性
Servlet模型基于"一个请求一个线程"的阻塞式I/O模型。在我们的案例中，每个推送通知都需要：
- 从数据库查询剩余名额（I/O阻塞）
- 生成推送内容（CPU计算）
- 通过HTTP长连接推送给客户端（I/O阻塞）
这种模式下，线程大部分时间都在等待I/O操作完成。我们使用VisualVM监控发现，在高并发时，线程池中80%的线程处于WAITING状态，造成了严重的资源浪费。
2.2 WebFlux的响应式特性
Spring WebFlux基于Project Reactor实现，采用事件驱动和非阻塞I/O模型。其核心优势在于：
- 少量线程（通常等于CPU核心数）即可处理大量并发
- 基于Reactive Streams规范实现背压（Backpressure）机制
- 全栈响应式，从Web层到数据库访问（如R2DBC）
在我们的压力测试中，使用相同的4核8G服务器配置，WebFlux版本能稳定处理10万并发连接，而Servlet版本在2万并发时就出现明显性能下降。
3. 关键实现：背压处理机制对比
3.1 Servlet模型的背压困境
在传统实现中，当客户端处理速度跟不上服务端推送速度时，会导致：
- 服务端线程阻塞，无法释放
- 内存中积压未送达的消息
- 最终触发线程池拒绝策略或OOM
我们曾尝试以下优化方案：
java复制// 伪代码：Servlet版限流实现
ExecutorService executor = Executors.newFixedThreadPool(200);
BlockingQueue<Message> queue = new ArrayBlockingQueue<>(1000);
public void doGet(HttpServletRequest req, HttpServletResponse resp) {
if(queue.size() > 800) {
resp.setStatus(503);
return;
}
executor.submit(() -> {
Message msg = generateMessage();
queue.put(msg);
pushToClient(msg); // 阻塞式IO
queue.remove(msg);
});
}
这种方案虽然避免了OOM，但无法真正解决背压问题，只是将压力转移到了队列管理上。
3.2 WebFlux的背压解决方案
WebFlux通过Reactive Streams规范实现了真正的背压传播。我们的重构后核心逻辑：
java复制@GetMapping("/freeMeal/remaining")
public Flux<RemainingUpdate> streamRemainingUpdates() {
return mealEventPublisher
.publishOn(Schedulers.boundedElastic())
.map(event -> {
int remaining = event.getRemaining();
return new RemainingUpdate(remaining, remaining < 10);
})
.onBackpressureBuffer(1000, BufferOverflowStrategy.DROP_OLDEST);
}
关键设计点：
publishOn将计算密集型操作切换到弹性线程池onBackpressureBuffer设置合理的缓冲区策略- 背压信号会通过Subscription.request(n)机制自动传播
4. 性能对比与调优实践
4.1 基准测试数据
我们在相同硬件环境下进行了对比测试（模拟5万并发用户）：
| 指标 | Servlet模型 | WebFlux模型 |
|---|---|---|
| 平均响应时间(ms) | 8200 | 210 |
| 最大内存占用(GB) | 6.2 | 1.8 |
| 90%线(ms) | 12000 | 350 |
| 错误率(%) | 23.4 | 0.7 |
4.2 关键调优参数
在WebFlux实现中，我们特别优化了以下配置：
yaml复制# application.yml
spring:
webflux:
max-in-memory-size: 10MB
buffer-size: 512
server:
reactive:
request-timeout: 30s
io-workers: 8
重要提示：不要盲目增大buffer-size，这会导致延迟增加。我们通过实验发现512是最佳平衡点。
5. 生产环境迁移经验
5.1 渐进式迁移策略
我们采用双运行模式逐步迁移：
- 新功能用WebFlux开发
- 旧API保持Servlet实现
- 通过Nginx路由区分流量
- 最终全量切换
5.2 常见问题排查
- 内存泄漏：忘记关闭Flux流会导致内存积累。解决方法：
java复制// 正确做法
return mealEventPublisher
.doOnCancel(() -> log.info("Client disconnected"))
.doFinally(s -> log.info("Stream completed"));
- 阻塞调用：误用阻塞库会导致事件循环卡死。必须使用：
java复制Mono.fromCallable(() -> blockingOperation())
.subscribeOn(Schedulers.boundedElastic())
- 背压失效：某些客户端（如旧版浏览器）不支持背压。我们的解决方案是：
java复制.flatMap(msg -> WebClient.post()
.uri(clientCallbackUrl)
.bodyValue(msg)
.retrieve()
.toBodilessEntity()
.timeout(Duration.ofSeconds(3))
.onErrorResume(e -> Mono.empty()),
5) // 最大并发数限制
6. 监控与运维实践
6.1 关键监控指标
我们使用Micrometer暴露以下核心指标：
http.server.requests：请求处理统计reactor.scheduler.used：线程池使用情况reactor.buffer.size：背压缓冲区状态reactive.stream.subscribed：活跃订阅数
6.2 容量规划建议
根据我们的经验，WebFlux应用的资源需求主要取决于：
- 活跃连接数（而非并发请求数）
- 消息吞吐速率
- 业务逻辑复杂度
一个实用的容量计算公式：
code复制所需CPU核心数 = 最大并发连接数 / 5000
内存需求(GB) = 活跃连接数 * 20KB / 1024/1024 + JVM基础开销
例如支持5万并发需要：
- 10个CPU核心
- 约2GB内存（仅网络缓冲区）
7. 开发者经验分享
在实际开发中，我们总结了这些宝贵经验：
- 调试技巧：在开发阶段启用reactor调试模式：
java复制Hooks.onOperatorDebug(); // 仅在开发环境使用
- 测试策略：使用StepVerifier进行响应式流测试：
java复制StepVerifier.create(myFlux)
.expectNextMatches(v -> v > 0)
.expectComplete()
.verify(Duration.ofSeconds(5));
- 性能陷阱：
- 避免在事件循环中执行阻塞操作
- 慎用flatMap，注意并发控制
- 合理配置Schedulers
- 客户端适配：对于不支持响应式的客户端，我们开发了适配层：
java复制@GetMapping("/legacy/remaining")
public DeferredResult<List<RemainingUpdate>> getLegacyUpdates() {
DeferredResult<List<RemainingUpdate>> result = new DeferredResult<>();
mealEventPublisher.take(10).collectList().subscribe(result::setResult);
return result;
}