學習WebFlux時常見的問題

只有光頭才能變強。

文字已收錄至我的github精選文章，歡迎star：

相信有過相關了解的同學都知道，servlet 3.1就已經支援非同步非阻塞了。

我們可以以自維護執行緒池的方式實現非同步

}流程圖如下：

簡單的方式，我們還可以使用jdk 8 提供的completablefuture類，這個類可以方便的處理非同步呼叫。

要處理複雜的邏輯時，無論是**或 completablefuture在**編寫上都會比較複雜（**量大，不易於看懂)，而webflux使用的是reactor響應式流，裡邊提供了一系列的api供我們去處理邏輯，就很方便了。

更重要的是：

值得一提的是：

如果web容器使用的是tomcat，那麼就是使用reactor橋接的servlet async api

如果web容器是netty，那麼就是使用的netty，天生支援reactive

官方的推薦是使用netty跑webflux

官網也說了：

使用非同步非阻塞的好處就是：

好處：只需要在程式內啟動少量執行緒擴充套件，而不是水平通過集群擴充套件。非同步能夠規避檔案io/網路io阻塞所帶來的執行緒堆積。

下面來看一下針對相同的請求量，同步阻塞和非同步非阻塞的吞吐量和響應時長對比：

注：

spring webflux在應對高併發的請求時，借助於非同步io，能夠以少量而穩定的執行緒處理更高吞吐量的請求，尤其是當請求處理過程如果因為業務複雜或io阻塞等導致處理時長較長時，對比更加顯著。

springmvc和webflux更多的是互補關係，而不是替換。阻塞的場景該springmvc還是springmvc，並不是webflux出來就把springmvc取代了。

目前對於關係型資料庫，pivotal團隊開源出r2dbc（reactive relational database connectivity），其github位址為：

目前r2dbc支援三種資料來源：

總的來說，因為webflux是響應式的，要想發揮出webflux的效能就得將**全改成響應式的，而jdbc目前是沒支援的(至少mysql還沒支援)，而響應式的程式不好除錯和編寫（相對於同步的程式），所以現在webflux的應用場景還是相對較少的。

所以，我認為在閘道器層用webflux比較合適（本來就是網路io較多的場景）

現在再回來看spring官網的圖，是不是就更親切了？

前面也提到了，webflux提供了兩種模式供我們使用，一種是springmvc 註解的，一種是叫functional endpoints的

lambda-based, lightweight, and functional programming model

有lambda表示式和stream流的基礎，等真正用到的時候再學也不是啥問題~

以下是通過註解的方式來使用webflux的示例：

以下是通過functional endpoints的方式來使用webflux的示例：

userhandler，相當於usercontroller：

總的來說，因為webflux是響應式的，要想發揮出webflux的效能就得將**全改成響應式的，而jdbc目前是沒支援的(至少mysql還沒支援)，而響應式的程式不好除錯和編寫（相對於同步的程式），老專案也不太可能把依賴直接公升上spring5.0，所以現在webflux的應用場景還是相對較少的(個人覺得)。

閘道器層用webflux比較合適（本來就是網路io較多的場景）

本已收錄至我的github精選文章，歡迎star：