1. 前言
最近写关于响应式编程的东西有点多，很多同学反映对flux和mono这两个reactor中的概念有点懵逼。但是目前java响应式编程中我们对这两个对象的接触又最多，诸如spring webflux、rsocket、r2dbc。我开始也对这两个对象头疼，所以今天我们就简单来探讨一下它们。
2. 响应流的特点
要搞清楚这两个概念，必须说一下响应流规范。它是响应式编程的基石。他具有以下特点：
响应流必须是无阻塞的。响应流必须是一个数据流。它必须可以异步执行。并且它也应该能够处理背压。
背压是反应流中的一个重要概念，可以理解为，生产者可以感受到消费者反馈的消费压力，并根据压力进行动态调整生产速率。形象点可以按照下面理解：
3. publisher
由于响应流的特点，我们不能再返回一个简单的pojo对象来表示结果了。必须返回一个类似java中的future的概念，在有结果可用时通知消费者进行消费响应。
reactive stream规范中这种被定义为publisher<t> ，publisher<t>是一个可以提供0-n个序列元素的提供者，并根据其订阅者subscriber<? super t>的需求推送元素。一个publisher<t>可以支持多个订阅者，并可以根据订阅者的逻辑进行推送序列元素。下面这个excel计算就能说明一些publisher<t>的特点。
a1-a9就可以看做publisher<t>及其提供的元素序列。a10-a13分别是求和函数sum(a1:a9)、平均函数average(a1:a9)、最大值函数max(a1:a9)、最小值函数min(a1:a9)，可以看作订阅者subscriber。假如说我们没有a10-a13，那么a1-a9就没有实际意义，它们并不产生计算。这也是响应式的一个重要特点：当没有订阅时发布者什么也不做。
而flux和mono都是publisher<t>在reactor 3实现。publisher<t>提供了subscribe方法，允许消费者在有结果可用时进行消费。如果没有消费者publisher<t>不会做任何事情，他根据消费情况进行响应。 publisher<t>可能返回零或者多个，甚至可能是无限的，为了更加清晰表示期待的结果就引入了两个实现模型mono和flux。
4. flux
flux 是一个发出(emit)0-n个元素组成的异步序列的publisher<t>,可以被oncomplete信号或者onerror信号所终止。在响应流规范中存在三种给下游消费者调用的方法 onnext, oncomplete, 和onerror。下面这张图表示了flux的抽象模型：
以上的的讲解对于初次接触反应式编程的依然是难以理解的，所以这里有一个循序渐进的理解过程。
有些类比并不是很妥当，但是对于你循序渐进的理解这些新概念还是有帮助的。
传统数据处理
我们在平常是这么写的：
|
1
2
3
4
|
public list<clientuser> allusers() { return arrays.aslist(new clientuser("felord.cn", "reactive"), new clientuser("felordcn", "reactor"));} |
我们通过迭代返回值list来get这些元素进行再处理（消费），这种方式有点类似厨师做了很多菜，吃不吃在于食客。需要食客主动去来吃就行了（pull的方式），至于喜欢吃什么不喜欢吃什么自己随意，怎么吃也自己随意。
流式数据处理
在java 8中我们可以改写为流的表示：
|
1
2
3
4
|
public stream<clientuser> allusers() { return stream.of(new clientuser("felord.cn", "reactive"), new clientuser("felordcn", "reactor"));} |
依然是厨师做了很多菜，但是这种就更加高级了一些，提供了菜品的搭配方式（不包含具体细节），食客可以按照说明根据自己的习惯搭配着去吃，一但开始概不退换，吃完为止，过期不候。
反应式数据处理
在reactor中我们又可以改写为flux表示：
|
1
2
3
4
|
public flux<clientuser> allusers(){ return flux.just(new clientuser("felord.cn", "reactive"), new clientuser("felordcn", "reactor"));} |
这时候食客只需要订餐就行了，做好了自然就呈上来，而且可以随时根据食客的饭量进行调整。如果没有食客订餐那么厨师就什么都不用做。当然不止有这么点特性，不过对于方便我们理解来说这就够了。
5. mono
mono 是一个发出(emit)0-1个元素的publisher<t>,可以被oncomplete信号或者onerror信号所终止。
这里就不翻译了，整体和flux差不多，只不过这里只会发出0-1个元素。也就是说不是有就是没有。象flux一样，我们来看看mono的演化过程以帮助理解。
传统数据处理
|
1
2
3
|
public clientuser currentuser () { return isauthenticated ? new clientuser("felord.cn", "reactive") : null;} |
直接返回符合条件的对象或者null。
optional的处理方式
|
1
2
3
4
|
public optional<clientuser> currentuser () { return isauthenticated ? optional.of(new clientuser("felord.cn", "reactive")) : optional.empty();} |
这个optional我觉得就有反应式的那种味儿了，当然它并不是反应式。当我们不从返回值optional取其中具体的对象时，我们不清楚里面到底有没有，但是optional是一定客观存在的,不会出现npe问题。
反应式数据处理
|
1
2
3
4
|
public mono<clientuser> currentuser () { return isauthenticated ? mono.just(new clientuser("felord.cn", "reactive")) : mono.empty();} |
和optional有点类似的机制，当然mono不是为了解决npe问题的，它是为了处理响应流中单个值（也可能是void）而存在的。
6. 总结
flux和mono是java反应式中的重要概念，但是很多同学包括我在开始都难以理解它们。这其实是规定了两种流式范式，这种范式让数据具有一些新的特性，比如基于发布订阅的事件驱动，异步流、背压等等。另外数据是推送（push）给消费者的以区别于平时我们的拉（pull）模式。同时我们可以像stream api一样使用类似map、flatmap等操作符（operator）来操作它们。对flux和mono这两个概念需要花一些时间去理解它们，不能操之过急。
到此这篇关于java反应式框架reactor中的mono和flux的文章就介绍到这了,更多相关java框架 reactor中的mono和flux内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！
原文链接：https://www.cnblogs.com/felordcn/p/13747262.html
