響應式編程以及反應式編程框架Reactor3的簡單介紹

福利

如今關注微信公衆號：碼農小胖哥， 發送關鍵字【抽獎】進行抽獎，可有機會獲取實體編程書籍。【本次抽獎截止到週末，若是錯過之後還有不少機會】

前言

Reactor 3是一個圍繞Reactive Streams規範構建的庫，它在JVM上引入了響應式編程的一個範例。目前Spring5 引入的Webflux就是reactor 3實現的一個響應式web框架。Spring Cloud Gateway是Webflux的一個網關場景實踐。想學好上面這兩項技術必須搞明白響應式編程以及Reactor 3。本篇文章中，小胖哥將帶你來簡單瞭解響應式編程和Reactor 3。

爲何要搞響應式

有這麼一個場景，產品提了一個這麼需求：商品打折，根據商品的原價來計算商品的折扣價。這個需求不是很簡單嘛，按照咱們一般的作法，搞一個以下的方法就搞定了。

可是若是我折扣改了呢，這時有人該說從新計算啊。這樣是否是從新走了一次流程呢，咱們須要花精力來維護這種流程邏輯。那麼能不能我下游能直接響應上游的變化？就像excel表格計算同樣，下游始終監聽上游，有點風吹草動，結果就會變化。這種潛在的需求就是響應式。響應式編程正是用某種操做符幫助你構建這種關係，而不是執行某種賦值命令。這種思想其實在前端的一些框架中已經風靡好久了。

響應式的特色

基於以上的一個簡單事例。咱們能夠看出若是是響應式必定要有一個觸發點。就像咱們點擊了計算機桌面的QQ圖標一隻企鵝跳啊跳。咱們點擊了迅雷圖標有一隻飛鳥在撲騰着翅膀。計算機只維護一個點擊圖標的事件。也就是說響應式編程必定是一個事件觸發機制。而且是以異步和非阻塞的方式發送和接收的。不是咱們日常請求-響應的同步模型。事件驅動的系統經過push而不是pull來處理，生產者在有消息時才推送消息給消費者，而不是經過一種浪費資源方式：讓 消費者不斷地輪詢或等待數據。基於這個機制相對高的吞吐量和實時響應也是響應式的特色。事件驅動因爲Publisher只用關心數據源，Consumer只用關心對處理結果的消費。徹底是鬆耦合的。這就給咱們很大的操做空間來定製化咱們的邏輯組合，從而使異步代碼更易讀和可維護。

Reactor簡介

Reactor 3框架是Pivotal（Spring 母公司）基於Reactive Programming思想實現的。它實現了Reactive Streams(該規範由 Netflix、TypeSafe、Pivotal等公司發起的響應式規範)。其餘諸如RxJava 2, Akka Streams, Vert.x和Ratpack也都實現了該規範。

Reactor有一個很重要概念的就是backpressure。 因爲生產者消費者處理數據的能力不對等，很容易產生下游消費能力過載的問題。這就須要一個backpressure處理，來告訴上游生產者避免過載。打個比方，一我的負責放水，一我的負責接水，若是放水的速度太快，水桶勢必會濺出來，接水的人會根據狀況來告訴放水的人什麼速度最合適，而且在快滿的時候告知放水人關閉開關。

Reactor還添加了運算符的概念，這些運算符被連接在一塊兒以描述在每一個階段對數據應用的處理。應用運算符返回一箇中間Publisher（實際上，它能夠被認爲是上游運算符的訂閱者和下游的發佈者）。數據的最終概括點是在最終Subscriber中（這裏還定義了用戶角度的業務邏輯）。還拿放水舉例，若是咱們放水不是爲了單純放水而是爲了製造肥宅快樂水。這樣就不是一我的接水了，中間加入了原漿流程，下一個接的人接到的是原漿勾兌水，那麼這我的充當了源頭的消費者，也充當了他下游的生產者。他的下游還有加氣兒的。他下游的下游還有罐裝等一系列操做。到最後裝箱整個工藝纔算告一段落。

上面揭示了一個最小單元的Reactor流程，源Publisher產生數據。但默認狀況下，它只有Subscriber在註冊（訂閱）以後纔會把數據推送給Subscriber執行運算符操做，中間可能伴隨者背壓處理。其實這些概念更重要的是理解它們。理解了Reactor的特性才能爲後面更好的學習java響應式編程打好基礎。
關注公衆號：碼農小胖哥 獲取更多資訊