Reactor模型分析

本文小編為大家詳細(xì)介紹“Reactor模型分析”，內(nèi)容詳細(xì)，步驟清晰，細(xì)節(jié)處理妥當(dāng)，希望這篇“Reactor模型分析”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來(lái)學(xué)習(xí)新知識(shí)吧。

1.原生 NIO 存在的問(wèn)題

1. NIO 的類庫(kù)和 API 繁雜，使用麻煩：需要熟練掌握 Selector、ServerSocketChannel、
   SocketChannel、ByteBuffer等。

2. 需要具有其余的額外技能：要熟習(xí) Java 多線程編程，由于 NIO 編程涉及到 Reactor 模式，你必需
   對(duì)多線程和網(wǎng)絡(luò)編程非常熟習(xí)，才能編寫(xiě)出高質(zhì)量的 NIO 程序。

3. 開(kāi)發(fā)工作量和難度都非常大：例如用戶端面臨斷連重連、網(wǎng)絡(luò)閃斷、半包讀寫(xiě)、失敗緩存、網(wǎng)絡(luò)擁
   塞和異常流的解決等等。

4. JDK NIO 的 Bug：臭名昭著的 Epoll Bug，它會(huì)導(dǎo)致 Selector 空輪詢，最終導(dǎo)致 CPU 100%。直到
   JDK 1.7版本該問(wèn)題依舊存在，沒(méi)有被根本處理
   （ Epoll Bug：在NIO中通過(guò)Selector的輪詢當(dāng)前能否有IO事件，根據(jù)JDK NIO api形容，Selector的select方
   法會(huì)一直阻塞，直到IO事件達(dá)到或者超時(shí)，但是在Linux平臺(tái)上這里有時(shí)會(huì)出現(xiàn)問(wèn)題，在某些場(chǎng)
   景下select方法會(huì)直接返回，即便沒(méi)有超時(shí)并且也沒(méi)有IO事件到達(dá)，這就是著名的epoll
   bug，這是一個(gè)比較嚴(yán)重的bug，它會(huì)導(dǎo)致線程陷入死循環(huán)，會(huì)讓CPU飆到100%，極大地影
   響系統(tǒng)的可靠性，到目前為止，JDK都沒(méi)有完全處理這個(gè)問(wèn)題。）

2.netty詳情

Netty 是由 JBOSS 提供的一個(gè) Java 開(kāi)源框架。Netty 提供異步的、基于事件驅(qū)動(dòng)的網(wǎng)絡(luò)應(yīng)用程序框
架，用以快速開(kāi)發(fā)高性能、高可靠性的網(wǎng)絡(luò) IO 程序。 Netty 是一個(gè)基于 NIO 的網(wǎng)絡(luò)編程框架，使用
Netty 可以幫助你快速、簡(jiǎn)單的開(kāi)發(fā)出一 個(gè)網(wǎng)絡(luò)應(yīng)用，相當(dāng)于簡(jiǎn)化和流程化了 NIO 的開(kāi)發(fā)過(guò)程。 作為
當(dāng)前最流行的 NIO 框架，Netty 在互聯(lián)網(wǎng)領(lǐng)域、大數(shù)據(jù)分布式計(jì)算領(lǐng)域、游戲行業(yè)、 通信行業(yè)等取得了
廣泛的應(yīng)用，知名的 Elasticsearch 、Dubbo 框架內(nèi)部都采用了 Netty。

Netty 的強(qiáng)大之處：零拷貝、可拓展事件模型；支持 TCP、UDP、HTTP、WebSocket 等協(xié)議；提供安全傳輸、壓縮、大文件傳輸、編解碼支持等等。

具有如下優(yōu)點(diǎn):

1. 設(shè)計(jì)優(yōu)雅，提供阻塞和非阻塞的 Socket；提供靈活可拓展的事件模型；提供高度可定制的線程模型。

2. 具有更高的性能和更大的吞吐量，使用零拷貝技術(shù)最小化不必要的內(nèi)存復(fù)制，減少資源的消耗。

3. 提供安全傳輸特性。

4. 支持多種主流協(xié)議；預(yù)置多種編解碼功能，支持客戶開(kāi)發(fā)私有協(xié)議

3.線程模型

（1）線程模型基本詳情
不同的線程模式，對(duì)程序的性能有很大影響，在學(xué)習(xí)Netty線程模式之前，首先講解下 各個(gè)線程模
式， 最后看看 Netty 線程模型有什么優(yōu)越性.目前存在的線程模型有：
傳統(tǒng)阻塞 I/O 服務(wù)模型
Reactor 模型
根據(jù) Reactor 的數(shù)量和解決資源池線程的數(shù)量不同，有 3 種典型的實(shí)現(xiàn)
·單 Reactor 單線程
·單 Reactor 多線程
·主從 Reactor 多線程

（2）傳統(tǒng)阻塞 I/O 服務(wù)模型
采用阻塞 IO 模式獲取輸入的數(shù)據(jù), 每個(gè)連接都需要獨(dú)立的線程完成數(shù)據(jù)的輸入 , 業(yè)務(wù)解決和數(shù)據(jù)返回
工作.

存在問(wèn)題:

1. 當(dāng)并發(fā)數(shù)很大，就會(huì)創(chuàng)立大量的線程，占用很大系統(tǒng)資源

2. 連接創(chuàng)立后，假如當(dāng)前線程暫時(shí)沒(méi)有數(shù)據(jù)可讀，該線程會(huì)阻塞在 read 操作，造成線程資源白費(fèi)

（3）Reactor 模型
Reactor 模式，通過(guò)一個(gè)或者多個(gè)輸入同時(shí)傳遞給服務(wù)解決器的模式 , 服務(wù)器端程序解決傳入的多個(gè)
請(qǐng)求,并將它們同步分派到相應(yīng)的解決線程， 因而 Reactor 模式也叫 Dispatcher模式. Reactor 模式使用
IO 復(fù)用監(jiān)聽(tīng)事件, 收到事件后，分發(fā)給某個(gè)線程(進(jìn)程), 這點(diǎn)就是網(wǎng)絡(luò)服務(wù)器高并發(fā)解決關(guān)鍵

單Reactor單線程：

·Selector是可以實(shí)現(xiàn)應(yīng)用程序通過(guò)一個(gè)阻塞對(duì)象監(jiān)聽(tīng)多路連接請(qǐng)求
·Reactor 對(duì)象通過(guò) Selector監(jiān)控用戶端請(qǐng)求事件，收到事件后通過(guò) Dispatch 進(jìn)行分發(fā)是建立連接請(qǐng)求事件，則由 Acceptor 通過(guò) Accept 解決連接請(qǐng)求，而后創(chuàng)立一個(gè) Handler 對(duì)象解決連接完成后的后續(xù)業(yè)務(wù)解決
·Handler 會(huì)完成 Read→業(yè)務(wù)解決→Send 的完整業(yè)務(wù)流程

優(yōu)點(diǎn): 模型簡(jiǎn)單，沒(méi)有多線程、進(jìn)程通信、競(jìng)爭(zhēng)的問(wèn)題，一律都在一個(gè)線程中完成
缺點(diǎn):

1. 性能問(wèn)題: 只有一個(gè)線程，無(wú)法完全發(fā)揮多核 CPU 的性能。Handler 在解決某個(gè)連接上的業(yè)務(wù)時(shí)，
   整個(gè)進(jìn)程無(wú)法解決其余連接事件，很容易導(dǎo)致性能瓶頸

2. 可靠性問(wèn)題: 線程意外終止或者者進(jìn)入死循環(huán)，會(huì)導(dǎo)致整個(gè)系統(tǒng)通信模塊不可用，不能接收和處
   理外部消息，造成節(jié)點(diǎn)故障

單Reactor多線程

·Reactor 對(duì)象通過(guò) selector 監(jiān)控用戶端請(qǐng)求事件, 收到事件后，通過(guò) dispatch 進(jìn)行分發(fā)
·假如建立連接請(qǐng)求, 則右 Acceptor 通過(guò)accept 解決連接請(qǐng)求
·假如不是連接請(qǐng)求，則由 reactor 分發(fā)調(diào)用連接對(duì)應(yīng)的 handler 來(lái)解決
·handler 只負(fù)責(zé)響應(yīng)事件，不做具體的業(yè)務(wù)解決, 通過(guò) read 讀取數(shù)據(jù)后，會(huì)分發(fā)給后面的worker 線程池的某個(gè)線程解決業(yè)務(wù)
·worker 線程池會(huì)分配獨(dú)立線程完成真正的業(yè)務(wù)，并將結(jié)果返回給 handler
·handler 收到響應(yīng)后，通過(guò) send 將結(jié)果返回給 client

優(yōu)點(diǎn):
可以充分的利用多核 cpu 的解決能力
缺點(diǎn):
多線程數(shù)據(jù)共享和訪問(wèn)比較復(fù)雜， reactor 解決所有的事件的監(jiān)聽(tīng)和響應(yīng)，在單線程運(yùn)行， 在
高并發(fā)場(chǎng)景容易出現(xiàn)性能瓶頸

主從Reactor多線程

·Reactor 主線程 MainReactor 對(duì)象通過(guò) select 監(jiān)聽(tīng)用戶端連接事件，收到事件后，通過(guò)Acceptor 解決用戶端連接事件
·當(dāng) Acceptor 解決完用戶端連接事件之后（與用戶端建立好 Socket 連接），MainReactor 將連接分配給 SubReactor。（即：MainReactor 只負(fù)責(zé)監(jiān)聽(tīng)用戶端連接請(qǐng)求，和用戶端建立連
接之后將連接交由 SubReactor 監(jiān)聽(tīng)后面的 IO 事件。)
·SubReactor 將連接加入到自己的連接隊(duì)列進(jìn)行監(jiān)聽(tīng)，并創(chuàng)立 Handler 對(duì)各種事件進(jìn)行解決當(dāng)連接上有新事件發(fā)生的時(shí)候，SubReactor 就會(huì)調(diào)用對(duì)應(yīng)的 Handler 解決
·Handler 通過(guò) read 從連接上讀取請(qǐng)求數(shù)據(jù)，將請(qǐng)求數(shù)據(jù)分發(fā)給 Worker 線程池進(jìn)行業(yè)務(wù)解決
·Worker 線程池會(huì)分配獨(dú)立線程來(lái)完成真正的業(yè)務(wù)解決，并將解決結(jié)果返回給 Handler。Handler 通過(guò) send 向用戶端發(fā)送響應(yīng)數(shù)據(jù)
·一個(gè) MainReactor 可以對(duì)應(yīng)多個(gè) SubReactor，即一個(gè) MainReactor 線程可以對(duì)應(yīng)多個(gè)
SubReactor 線程

優(yōu)點(diǎn):

1. MainReactor 線程與 SubReactor 線程的數(shù)據(jù)交互簡(jiǎn)單職責(zé)明確，MainReactor 線程只要要
   接收新連接，SubReactor 線程完成后續(xù)的業(yè)務(wù)解決

2. MainReactor 線程與 SubReactor 線程的數(shù)據(jù)交互簡(jiǎn)單， MainReactor 線程只要要把新連接
   傳給 SubReactor 線程，SubReactor 線程無(wú)需返回?cái)?shù)據(jù)

3. 多個(gè) SubReactor 線程能夠應(yīng)對(duì)更高的并發(fā)請(qǐng)求
   缺點(diǎn):
   這種模式的缺點(diǎn)是編程復(fù)雜度較高。但是因?yàn)槠鋬?yōu)點(diǎn)顯著，在許多項(xiàng)目中被廣泛使用，包括
   Nginx、Memcached、Netty 等。這種模式也被叫做服務(wù)器的 1+M+N 線程模式，即便用該模式開(kāi)
   發(fā)的服務(wù)器包含一個(gè)（或者多個(gè)，1 只是表示相對(duì)較少）連接建立線程+M 個(gè) IO 線程+N 個(gè)業(yè)務(wù)解決
   線程。這是業(yè)界成熟的服務(wù)器程序設(shè)計(jì)模式。

讀到這里，這篇“Reactor模型分析”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識(shí)點(diǎn)還需要大家自己動(dòng)手實(shí)踐使用過(guò)才能領(lǐng)會(huì)，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注億速云行業(yè)資訊頻道。