Spring WebFlux(reactor) zipWith+interval限流时溢出异常的解决咨询

嘿，这个问题我之前也碰到过！你遇到的OverflowException本质是Flux.interval的特性导致的——它是个热发布者，不管下游能不能跟上处理节奏，都会自顾自按固定速率生成tick。当下游调用第三方API的速度赶不上tick生成速度时，就会因为请求堆积炸锅。给你几个实用的解决办法：

方案1：给interval加背压丢弃（适配你原来的写法） #

如果你想保留原来用interval限流的思路，只需要给interval加上onBackpressureDrop()，让它自动丢弃下游处理不过来的tick，就不会抛出异常了：

Flux<Calls> callsIntervalFlux = Flux.interval(Duration.ofMillis(100))
    .onBackpressureDrop() // 下游忙不过来就直接丢弃多余的tick
    .zipWith(callsFlux, (i, call) -> call);

不过要注意：这种方式会让部分callsFlux里的元素因为对应的tick被丢弃而得不到处理。如果你必须保证1000个请求都要发出去，那这个方案可能不适合你。

方案2：用concatMap+延迟实现可靠限流（我最推荐这个） #

其实更稳妥的思路是直接给每个API请求加间隔，而不是靠interval来配对。用concatMap配合delayElement，可以让每个元素都按顺序处理，前一个请求发完等100ms再发下一个，完全不会有背压问题：

Flux<Calls> callsIntervalFlux = callsFlux
    .concatMap(call -> 
        Mono.just(call)
            .delayElement(Duration.ofMillis(100)) // 每个请求间隔100ms
            .flatMap(c -> {
                // 这里写你调用第三方API的逻辑
                return callThirdPartyRestApi(c);
            })
    );

这个方法的优势很明显：

• 严格控制请求间隔，第三方API绝对不会过载
• 天然支持背压，下游处理慢的话会自动暂停发射元素，不会堆积请求
• 保证你那1000个对象每个都会被调用到，一个都不落下

方案3：用缓冲暂存tick（偶尔过载可用） #

如果只是偶尔出现下游处理慢的情况，不想丢任何请求，可以用onBackpressureBuffer来暂存多余的tick，设置个合理的缓冲大小就行：

Flux<Calls> callsIntervalFlux = Flux.interval(Duration.ofMillis(100))
    .onBackpressureBuffer(20, overflowTick -> {
        // 缓冲满了可以打个日志，方便排查过载情况
        System.out.println("请求缓冲已满，丢弃tick: " + overflowTick);
    })
    .zipWith(callsFlux, (i, call) -> call);

这个方案会把暂时处理不了的tick存在缓冲里，等下游有空了再处理，但如果持续过载，缓冲满了还是会丢弃元素，所以最好加个回调日志，方便你知道什么时候出现了过载。

内容的提问来源于stack exchange，提问作者Aleksey Kozel