實戰SpringCloud響應式微服務系列教程

背壓是響應式編程的核心概念，這一節也是咱們瞭解響應式編程的重點。

1.背壓的機制

在生產者/消費者模型中，咱們意識到消費者在消費由生產者生產的數據的同時，也須要有一種可以向上遊反饋流量需求的機制，這種可以向上遊反饋請求的機制稱之爲背壓。

以下圖所示

如今咱們從一個具體的角度來講背壓的概念。在1.1.1中咱們瞭解了同步消費和異步消費，其中異步消費者會向生產者訂閱消費數據，當有新的數據可用時，消費者會經過以前訂閱時提供的回調函數激活調用過程。

若是生產者發出的數據比消費者可以處理的數據量大並且快時，消費者可能會被迫一直再獲取或處理數據，消耗愈來愈多的資源，從而埋下潛在的風險。爲了防止這一點，須要有一種機制，消費者能夠通知生產者下降生產數據的速度。生產者能夠經過多種方式來實現這一要求，這時候咱們就會用到背壓機制。

採用背壓機制後，消費者告訴生產者下降生產數據速度並保存元素，知道消費者可以處理更多的元素。使用背壓能夠有效地避免過快的生產者壓制消費者。若是生產者要一直生產和保存元素，使用背壓也可能會要求其擁有無限制的緩衝區。生產者也能夠實現有界緩衝區來保存有限數量的元素，若是緩衝區已滿能夠選擇放棄。

2.背壓的實現方式

背壓的實現方式有兩種，一種是阻塞式背壓另外一種是非阻塞式背壓。

一、阻塞式背壓

阻塞式背壓是比較容易實現的，例如：當生產者和消費者在同一個線程中運行時，其中任何一方都將阻塞其餘線程的執行。這就意味着，當消費者被執行時，生產者就不能發出任何新的數據元素。於是也須要一中天然地方式來平衡生產數據和消費數據的過程。

在有些狀況下，阻塞式背壓會出現不良的問題，好比：當生產者有多個消費者時，不是全部消費者都能以一樣的速度消費消息。當消費者和生產者在不一樣環境中運行時，這就達不到降壓的目的了。

二、非阻塞式背壓

背壓機制應該以非阻塞式的方式工做，實現非阻塞式背壓的方法是放棄推策略，採用拉策略。生產者發送消息給消費者等操做均可以保存在拉策略當中，消費者會要求生產者生成多少消息量，並且最多隻能發送這些量，而後等到更多消息的請求。（關於推策略和拉策略請回顧1.1.1中的流的概念）

1.1.3 響應式流

響應式編程的另一個核心概念就是響應式流。響應式流是一種規範，這種規範表如今技術上就是一批被預先定義好的接口。

1.響應式流規範

響應式流規範是提供非阻塞背壓的異步流處理標準倡議的。響應式流的目標是定義將數據流從生產者傳遞到消費者而不須要生產者阻塞。在響應式流模型中，消費者向生產者發送多個元素的異步請求，而後生產者向消費者發送合適數量的數據。

各個響應式開發庫都要遵循響應式流規範，採用規範的好處是顯而易見的。因爲各個響應式都遵循一套規範，於是互相兼容，不一樣的開發庫之間也是能夠進行交流的。甚至能夠在同一個項目中使用多個開發庫。而Spring WebFlux響應式web是採用Reactor框架來實現的。（其餘開發庫可百度瞭解這裏咱們只探討reactor）。

雖然響應式流規範用來約束響應式開發庫的實現方式的，可是做爲使用者而言，可以瞭解這一規範，對咱們瞭解使用開發庫的方法和基本原理頗有幫助，由於規範內容都是對響應式編程思想的精髓呈現。

2.響應式流接口

Java API響應式流有4個接口，即Publisher<T>、Subscription、Subscriber<T>和Processor<T,R>。

一、Publisher<T>

發佈者（Publisher）是潛在的包含無限數量的有序元素的生產者，他根據收到的請求向當前訂閱者發送元素。接口定義以下：

publicinterfacePublisher<T>{   publicvoidsubscribe (Subscriber<?superT>s);}

二、Subscriber<T>

訂閱者從發佈這那裏訂閱而且接收元素。發佈者想訂閱者發送訂閱令牌。使用訂閱令牌，訂閱者向發佈者請求多個元素。當元素準備就緒時，發佈者就會向訂閱者發送合適數量的元素。而後訂閱者能夠請求更多的元素，發佈者也可能有多個來自訂閱者的待處理請求。接口定義以下：

[url=][/url]
publicinterfaceSubscriber<T>{  publicvoid  onSubscribe(Subscription s);  publicvoid  onNext(T t);  publicvoid  onError(Throwable t);  publicvoid  onComplete();}[url=][/url]

當執行發佈者的subscribe()方法時，發佈者會回調訂閱者的onSubscribe()方法。在這個方法中訂閱者一般會藉助傳入的Subscription 對象向發佈者請求n個數據。而後發佈者經過不斷調用onNext()方法想訂閱者發出最多n個數據。若是數據所有發送完畢，就會調用onComplete()方法告知訂閱者所須要的n個數據已經發送完畢。若是有錯誤發生就會經過調用onError()方法發出錯誤數據，這一樣也會終止數據流。

三、Subscription

訂閱（Subscription ）表示訂閱者訂閱的一個發佈者的令牌，當訂閱請求成功時，發佈者將其傳遞給訂閱者，訂閱者使用訂閱令牌與發佈者進行交互，好比：請求更多的元素或取消訂閱。接口定義以下：

publicinterfaceSubscription{   publicvoid  request(Long n);   publicvoid  cancel();}

當發佈者調用subscribe()方法註冊訂閱者時，會經過訂閱者的回調方法onSubscribe()傳入Subscription對象，以後訂閱者就可使用Subscription對象的request()方法向發佈者請求數據了。

Publisher<T>、Subscription、Subscriber<T>三者的交互以下：

四、Processor<T,R>

處理器（Processor）充當訂閱者和發佈者之間的處理媒介，Processor接口繼承了Publisher和Subscribe接口，它用於轉換髮布者/訂閱者管道中的元素。

Processor<T,R>訂閱類型T的數據元素，接收並轉換爲R的數據，而後發佈該數據。處理器在發佈者/訂閱者管道中充當轉換器的角色。接口定義以下：

publicinterfaceProcessor<T,R>extendsSubscriber<T>,Publisher<R>{}

Processor集Subscriber和Publisher於一身，三者之間的關係以下所示：

這四個接口是實現各個響應式開發庫之間互相兼容的橋樑，響應式流規範也僅僅聚焦於此，而對於轉換、合併、分組等操做並未作要求。也是一個很是抽象且精簡的接口規範。