关于响应式编程:响应式流的核心机制背压机制

一、响应式流是什么？

Reactive Streams 是 2013 年底由 Netflix、Lightbend 和 Pivotal（Spring 背地的公司）的工程师发动的一项打算，响应式流旨在为无阻塞异步流解决提供一个规范。它旨在解决解决元素流的问题——如何将元素流从发布者传递到订阅者，而不须要发布者阻塞，或订阅者有无限度的缓冲区或抛弃。

响应式流模型存在两种根本的实现机制。一种就是传统开发模式下的“拉”模式，即消费者被动从生产者拉取元素；而另一种就是“推”模式，在这种模式下，生产者将元素推送给消费者。相较于“拉”模式，“推”模式下的数据处理的资源利用率更好，下图所示的就是一种典型的推模式解决流程。

上图中，数据流的生产者会继续地生成数据并推送给消费者。这里就引出了流量管制问题，即如果数据的生产者和消费者解决数据的速度是不统一的，咱们应该如何确保零碎的稳定性呢？

二、流量管制

2.1 生产者生产数据的速率小于消费者的场景

这种场景对于消费者来说没啥压力，失常生产就好了，这里也就不须要所谓的流量管制了。

2.2 生产者生产数据的速率大于消费者的场景

生产者生产数据的速率大于消费者的场景，应该是咱们业务中常常遇到的场景了，这种场景因为消费者解决不过去导致解体，业界通常的做法是在生产者与消费者之间加一个队列做缓冲。咱们晓得队列具备存储与转发的性能，所以能够用它来进行肯定的流量管制。

如何对于流量进行很好的管制？这就转变到了如何设计好一个队列了，目前 Java 业界支流的队列有以下三种：

2.2.1 无界队列

见名知意，无界队列在原则上是领有无线大小容量的队列，能够寄存生产者产生的所有音讯。

• 劣势：确保消费者生产到所有的数据
• 劣势：零碎的回弹性升高，任何一个零碎不可能领有有限的资源，一旦内存等资源耗尽，零碎就可能会有解体的危险。

2.2.2 有界抛弃队列

为了防止下面无界队列的弊病，有界抛弃队列采纳的是如果队列满了，就会采纳抛弃前面传入的值，这里能够设置一些抛弃策略，比如说依照优先级或先进先出等。

• 劣势：思考到资源的限度，适宜容许丢音讯的业务场景。
• 劣势：音讯重要性很高的场景不倡议采取这种队列

2.2.3 有界阻塞队列

像一些领取金融级别的场景，是不容许丢数据的，所以咱们引出有界阻塞队列，咱们会在队列音讯数量达到下限后阻塞生产者，而不是间接抛弃音讯。

• 劣势：解决了不容许丢数据的业务场景
• 劣势：当队列满了的时候，会阻塞生产者进行生产数据，这种场景不可能实现异步操作的。

所以，无论从回弹性、弹性还是即时响应性登程，上述的队列都不是响应式流的上佳解决办法。

三、背压机制

下面说的那几种队列纯“推”模式下的数据流量会有很多不可管制的因素，并不能间接利用，而是须要在“推”模式和“拉”模式之间思考肯定的平衡性，从而优雅地实现流量管制。这就须要引出响应式零碎中十分重要的一个概念——背压机制（Backpressure）。

什么是背压？简略来说就是上游可能向上游反馈流量申请的机制。通过后面的剖析，咱们晓得如果消费者生产数据的速度赶不上生产者生产数据的速度时，它就会继续耗费零碎的资源，直到这些资源被耗费殆尽。

这个时候，就须要有一种机制使得消费者能够依据本身以后的解决能力告诉生产者来调整生产数据的速度，这种机制就是背压。采纳背压机制，消费者会依据本身的解决能力来申请数据，而生产者也会依据消费者的能力来生产数据，从而在两者之间达成一种动静的均衡，确保零碎的即时响应性。

四、响应式流标准

有了背压机制，咱们再来看下响应式流是如何基于这种机制去设计的一套标准，标准详情请参考：Reactive Streams

Java API 的响应式流只定义了四个外围接口：

• Publisher<T>
• Subscriber<T>
• Subscription
• Processor<T,R>

4.1 Publisher<T>

Publisher 代表的就是一种能够生产有限数据的发布者，接口如下：

public interface Publisher<T> {public void subscribe(Subscriber<? super T> s);
}

能够看到，Publisher 里的 subscribe 办法传入的是 Subscriber 接口，其实这里用的是回调，Publisher 依据收到的申请向以后订阅者 Subscriber 发送元素。

4.2 Subscriber<T>

Subscriber 代表的是一种能够从发布者那里订阅并接管元素的订阅者，接口如下：

public interface Subscriber<T> {public void onSubscribe(Subscription s);
    public void onNext(T t);
    public void onError(Throwable t);
    public void onComplete();}

Subscriber 接口定义的这组办法形成了数据流申请和解决的根本流程，其中，onSubscribe() 从命名上看就是一个回调办法，当发布者的 subscribe() 办法被调用时就会触发这个回调。而在该办法中有一个参数 Subscription，能够把这个 Subscription 看作是一种用于订阅的上下文对象。Subscription 对象中蕴含了这次回调中订阅者想要向发布者申请的数据个数。

当订阅关系曾经建设，那么发布者就能够调用订阅者的 onNext() 办法向订阅者发送一个数据。这个过程是继续一直的，直到所发送的数据曾经达到 Subscription 对象中所申请的数据个数。这时候 onComplete() 办法就会被触发，代表这个数据流曾经全副发送完结。而一旦在这个过程中呈现了异样，那么就会触发 onError() 办法，咱们能够通过这个办法捕捉到具体的异样信息进行解决，而数据流也就主动终止了。

4.3 Subscription

Subscription 代表的就是一种订阅上下文对象，它在订阅者和发布者之间进行传输，从而在两者之间造成一种契约关系，接口如下：

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

这里的 request() 办法用于申请 n 个元素，订阅者能够通过一直调用该办法来向发布者申请数据；而 cancel() 办法显然是用来勾销这次订阅。请留神，Subscription 对象是确保生产者和消费者针对数据处理速度达成一种动态平衡的根底，也是流量管制中实现背压机制的关键所在 。

4.4 Processor<T,R>

Processor 代表的就是订阅者和发布者的解决阶段，Processor 接口继承了 Publisher 和 Subscriber 接口。它用于转换发布者——订阅者管道中的元素。Processor<T,R> 订阅类型 T 的数据元素，接管并转换为类型 R 的数据，并公布变换后的数据。接口如下：

public interface Processor<T,R> extends Subscriber<T>, Publisher<R> {}

下图显示了解决者在发布者——订阅和管道中作为转换器的作用，能够领有多个解决者。

五、总结

• 响应式流标准定义的很简洁，但实现起来并不简略，发布者和订阅者之间的所有交互的异步性质以及背压机制使得实现变得复杂。
• 响应式流标准非常灵活，还能够提供独立的“推”模型和“拉”模型。如果为了实现纯“推”模型，咱们能够思考一次申请足够多的元素；而对于纯“拉”模型，相当于就是在每次调用 Subscriber 的 onNext() 办法时只申请一个新元素。
• JDK 9 中提供了 Flow 响应式流接口，与响应式流兼容的接口，能够看得出，JDK 团队后续的发展趋势也是想往响应式流这块凑近。