Publisher

由于响应流的特点，我们不能再返回一个简单的POJO对象来表示结果了。必须返回一个类似Java中的Future的概念，在有结果可用时通知消费者进行消费响应。

Reactive Stream规范中这种被定义为Publisher<T> ，Publisher<T>是一个可以提供0-N个序列元素的提供者，并根据其订阅者Subscriber<? super T>的需求推送元素。一个Publisher<T>可以支持多个订阅者，并可以根据订阅者的逻辑进行推送序列元素。下面这个Excel计算就能说明一些Publisher<T>的特点。

Publisher<T>提供了subscribe方法，允许消费者在有结果可用时进行消费。如果没有消费者Publisher<T>不会做任何事情，他根据消费情况进行响应。 Publisher<T>可能返回零或者多个，甚至可能是无限的，为了更加清晰表示期待的结果就引入了两个实现模型Mono和Flux。

`Flux<T>`

Flux 是一个发出(emit)0-N个元素组成的异步序列的Publisher<T>,可以被onComplete信号或者onError信号所终止。在响应流规范中存在三种给下游消费者调用的方法 onNext, onComplete, 和onError。下面这张图表示了Flux的抽象模型：

以上的的讲解对于初次接触反应式编程的依然是难以理解的，所以这里有一个循序渐进的理解过程。

传统数据处理

我们在平常是这么写的：

public List<ClientUser> allUsers() {
    return Arrays.asList(new ClientUser("felord.cn", "reactive"),
            new ClientUser("Felordcn", "Reactor"));
}

我们通过迭代返回值List来get这些元素进行再处理（消费），这种方式有点类似厨师做了很多菜，吃不吃在于食客。需要食客主动去来吃就行了（pull的方式），至于喜欢吃什么不喜欢吃什么自己随意，怎么吃也自己随意。

流式数据处理

在Java 8中我们可以改写为流的表示：

public Stream<ClientUser> allUsers() {
    return  Stream.of(new ClientUser("felord.cn", "reactive"),
            new ClientUser("Felordcn", "Reactor"));
}

依然是厨师做了很多菜，但是这种就更加高级了一些，提供了菜品的搭配方式（不包含具体细节），食客可以按照说明根据自己的习惯搭配着去吃，一但开始概不退换，吃完为止，过期不候。

反应式数据处理

在Reactor中我们又可以改写为Flux表示：

public Flux<ClientUser> allUsers(){
    return Flux.just(new ClientUser("felord.cn", "reactive"),
            new ClientUser("Felordcn", "Reactor"));
}

这时候食客只需要订餐就行了，做好了自然就呈上来，而且可以随时根据食客的饭量进行调整。如果没有食客订餐那么厨师就什么都不用做。当然不止有这么点特性，不过对于方便我们理解来说这就够了

`Mono<T>`

Mono 是一个发出(emit)0-1个元素的Publisher<T>,可以被onComplete信号或者onError信号所终止。

整体和Flux差不多，只不过这里只会发出0-1个元素。也就是说不是有就是没有。象Flux一样，我们来看看Mono的演化过程以帮助理解。

传统数据处理

public ClientUser currentUser () {
    return isAuthenticated ? new ClientUser("felord.cn", "reactive") : null;
}

直接返回符合条件的对象或者null。

Optional的处理方式

public Optional<ClientUser> currentUser () {
    return isAuthenticated ? Optional.of(new ClientUser("felord.cn", "reactive"))
            : Optional.empty();
}

这个Optional我觉得就有反应式的那种味儿了，当然它并不是反应式。当我们不从返回值Optional取其中具体的对象时，我们不清楚里面到底有没有，但是Optional是一定客观存在的,不会出现NPE问题。

反应式数据处理

public Mono<ClientUser> currentUser () {
    return isAuthenticated ? Mono.just(new ClientUser("felord.cn", "reactive"))
            : Mono.empty();
}

和Optional有点类似的机制，当然Mono不是为了解决NPE问题的，它是为了处理响应流中单个值（也可能是Void）而存在的。

无论Mono还是Flux大部分都是单线程阻塞式执行的，只有部分如Flux.interval(Duration.ofMillis(1000));是新开线程处理的

defer

Reactor的来源要么是懒惰的，要么是渴望的。诸如HTTP请求之类的更高级的请求将被延迟评估。另一方面，最简单的人喜欢Mono.just或Flux.fromIterable渴望。

这样，我的意思是调用Mono.just(System.currentTimeMillis())将立即调用该currentTimeMillis()方法并捕获结果。所述结果仅在被订阅后才
发出Mono。多次订阅也不会更改该值：

Mono<Long> clock = Mono.just(System.currentTimeMillis());
//time == t0

Thread.sleep(10_000);
//time == t10
clock.block(); //we use block for demonstration purposes, returns t0

Thread.sleep(7_000);
//time == t17
clock.block(); //we re-subscribe to clock, still returns t0

该defer运营商有没有使这个源懒惰，重新评估拉姆达的含量每有一个新的用户时间：

Mono<Long> clock = Mono.defer(() -> Mono.just(System.currentTimeMillis()));
//time == t0

Thread.sleep(10_000);
//time == t10
clock.block(); //invoked currentTimeMillis() here and returns t10

Thread.sleep(7_000);
//time == t17
clock.block(); //invoke currentTimeMillis() once again here and returns t17