reactor框架使用时，数据流请求流程

1. 我们在Flux打开时，可以看到

public abstract class Flux<T> implements CorePublisher<T> {

public interface CorePublisher<T> extends Publisher<T> {
    void subscribe(CoreSubscriber<? super T> subscriber);
}

Publisher的关键时有个subscribe方法。这个方法就是在reactor的subscribe的时候会调用到这里。

3. 这里subscribe的参数有个CoreSubscriber。其实这个方法基本上最终其实会调用到CoreSubscriber的onSubscribe方法。

随便看对void subscribe(CoreSubscriber<? super T> subscriber);的方法的实现

选择Flux举例。看到最终调用结果：

4. 那么onSubscribe怎么调用下游呢？

注意，void onSubscribe(Subscription s);里面又传入了Subscription。

public interface Subscription {
        public void request(long n);
    public void cancel();
}

以Flux.just(1),为例，其实所有的onSubscribe方法会调用到Subscription的request方法。

5. request方法，最后调用到了onnext方法

所以数据流程如下：

subscribe()->subscribe(CoreSubscriber<? super T> subscriber)->CoreSubscriber.onSubscribe->Subscription.request(n)->CoreSubscriber.onNext()

6. 因此，onNext的调用前，数据的准备可以在Subscription.request的方法逻辑中内部进行准备，当准备好了再调用onNext方法。如果是分批request的，也就是说CoreSubscriber.onSubscribe逻辑中是分批次调用Subscription.request(n)，则每个批次的Subscription.request(n)中都可以等待数据好了再调用onNext方法。

7. 也就是说，数据调用onNext之前，都可以准备好再调用。但是一旦onNext调用以后，就尽量不能阻塞住后续流程了。如果后续流程中有阻塞的情况，就要用publishon和subscribeon了，让阻塞的内容在单独的线程池中执行。

8. 对zipWith方法的理解。摘自chatgpt。不清楚是否正确

如果某个 Flux 中的数据项尚未准备好，zipWith 会挂起合并操作，直到另一个 Flux 中的数据也准备好为止。只要 zipWith 中的两个流的每一对数据项都准备好了，它才会触发 onNext()。

因此这里其实Reactor框架其实netty线程还是在做其他的事情，当都准备好了，才会利用netty线程，进行onNext的处理