簡單了解Java Netty Reactor三種線程模型
1. Reactor三種線程模型
1.1. 單線程模型
Reactor單線程模型,指的是所有的IO操作都在同一個NIO線程上面完成,NIO線程的職責如下:
1)作為NIO服務(wù)端,接收客戶端的TCP連接;
2)作為NIO客戶端,向服務(wù)端發(fā)起TCP連接;
3)讀取通信對端的請求或者應(yīng)答消息;
4)向通信對端發(fā)送消息請求或者應(yīng)答消息。
Reactor單線程模型示意圖如下所示:

Reactor單線程模型
由于Reactor模式使用的是異步非阻塞IO,所有的IO操作都不會導致阻塞,理論上一個線程可以獨立處理所有IO相關(guān)的操作。從架構(gòu)層面看,一個NIO線程確實可以完成其承擔的職責。例如,通過Acceptor類接收客戶端的TCP連接請求消息,鏈路建立成功之后,通過Dispatch將對應(yīng)的ByteBuffer派發(fā)到指定的Handler上進行消息解碼。用戶線程可以通過消息編碼通過NIO線程將消息發(fā)送給客戶端。
對于一些小容量應(yīng)用場景,可以使用單線程模型。但是對于高負載、大并發(fā)的應(yīng)用場景卻不合適,主要原因如下:
1)一個NIO線程同時處理成百上千的鏈路,性能上無法支撐,即便NIO線程的CPU負荷達到100%,也無法滿足海量消息的編碼、解碼、讀取和發(fā)送;
2)當NIO線程負載過重之后,處理速度將變慢,這會導致大量客戶端連接超時,超時之后往往會進行重發(fā),這更加重了NIO線程的負載,最終會導致大量消息積壓和處理超時,成為系統(tǒng)的性能瓶頸;
3)可靠性問題:一旦NIO線程意外跑飛,或者進入死循環(huán),會導致整個系統(tǒng)通信模塊不可用,不能接收和處理外部消息,造成節(jié)點故障。
為了解決這些問題,演進出了Reactor多線程模型,如下。
1.2. 多線程模型
Rector多線程模型與單線程模型最大的區(qū)別就是有一組NIO線程處理IO操作,它的原理圖如下:

Rector多線程模型
Reactor多線程模型的特點:
1)有專門一個NIO線程-Acceptor線程用于監(jiān)聽服務(wù)端,接收客戶端的TCP連接請求;
2)網(wǎng)絡(luò)IO操作-讀、寫等由一個NIO線程池負責,線程池可以采用標準的JDK線程池實現(xiàn),它包含一個任務(wù)隊列和N個可用的線程,由這些NIO線程負責消息的讀取、解碼、編碼和發(fā)送;
3)1個NIO線程可以同時處理N條鏈路,但是1個鏈路只對應(yīng)1個NIO線程,防止發(fā)生并發(fā)操作問題。
在絕大多數(shù)場景下,Reactor多線程模型都可以滿足性能需求;但是,在極個別特殊場景中,一個NIO線程負責監(jiān)聽和處理所有的客戶端連接可能會存在性能問題。例如并發(fā)百萬客戶端連接,或者服務(wù)端需要對客戶端握手進行安全認證,但是認證本身非常損耗性能。在這類場景下,單獨一個Acceptor線程可能會存在性能不足問題,為了解決性能問題,產(chǎn)生了第三種Reactor線程模型-主從Reactor多線程模型。
1.3. 主從多線程模型
主從Reactor線程模型的特點是:服務(wù)端用于接收客戶端連接的不再是個1個單獨的NIO線程,而是一個獨立的NIO線程池。Acceptor接收到客戶端TCP連接請求處理完成后(可能包含接入認證等),將新創(chuàng)建的SocketChannel注冊到IO線程池(sub reactor線程池)的某個IO線程上,由它負責SocketChannel的讀寫和編解碼工作。Acceptor線程池僅僅只用于客戶端的登陸、握手和安全認證,一旦鏈路建立成功,就將鏈路注冊到后端subReactor線程池的IO線程上,由IO線程負責后續(xù)的IO操作。
主從多線程模型如下圖所示:

主從多線程模型
利用主從NIO線程模型,可以解決1個服務(wù)端監(jiān)聽線程無法有效處理所有客戶端連接的性能不足問題。
它的工作流程總結(jié)如下:
1)從主線程池中隨機選擇一個Reactor線程作為Acceptor線程,用于綁定監(jiān)聽端口,接收客戶端連接;Acceptor線程接收客戶端連接請求之后創(chuàng)建新的SocketChannel,將其注冊到主線程池的其它Reactor線程上,由其負責接入認證、IP黑白名單過濾、握手等操作;
2)步驟2完成之后,業(yè)務(wù)層的鏈路正式建立,將SocketChannel從主線程池的Reactor線程的多路復用器上摘除,重新注冊到Sub線程池的線程上,用于處理I/O的讀寫操作。
2. Netty線程模型
2.1. Netty線程模型分類
事實上,Netty的線程模型與1.2章節(jié)中介紹的三種Reactor線程模型相似,下面章節(jié)我們通過Netty服務(wù)端和客戶端的線程處理流程圖來介紹Netty的線程模型。
2.1.1. 服務(wù)端線程模型
一種比較流行的做法是服務(wù)端監(jiān)聽線程和IO線程分離,類似于Reactor的多線程模型,它的工作原理圖如下:

2.1.2. 客戶端線程模型
相比于服務(wù)端,客戶端的線程模型簡單一些,它的工作原理如下:

2.2. Reactor線程NioEventLoop
NioEventLoop是Netty的Reactor線程,它的職責如下:
- 作為服務(wù)端Acceptor線程,負責處理客戶端的請求接入;
- 作為客戶端Connecor線程,負責注冊監(jiān)聽連接操作位,用于判斷異步連接結(jié)果;
- 作為IO線程,監(jiān)聽網(wǎng)絡(luò)讀操作位,負責從SocketChannel中讀取報文;
- 作為IO線程,負責向SocketChannel寫入報文發(fā)送給對方,如果發(fā)生寫半包,會自動注冊監(jiān)聽寫事件,用于后續(xù)繼續(xù)發(fā)送半包數(shù)據(jù),直到數(shù)據(jù)全部發(fā)送完成;
- 作為定時任務(wù)線程,可以執(zhí)行定時任務(wù),例如鏈路空閑檢測和發(fā)送心跳消息等;
- 作為線程執(zhí)行器可以執(zhí)行普通的任務(wù)線程(Runnable)。
2.3. NioEventLoop設(shè)計原理
我們知道當系統(tǒng)在運行過程中,如果頻繁的進行線程上下文切換,會帶來額外的性能損耗。多線程并發(fā)執(zhí)行某個業(yè)務(wù)流程,業(yè)務(wù)開發(fā)者還需要時刻對線程安全保持警惕,哪些數(shù)據(jù)可能會被并發(fā)修改,如何保護?這不僅降低了開發(fā)效率,也會帶來額外的性能損耗。
串行執(zhí)行Handler鏈
為了解決上述問題,Netty采用了串行化設(shè)計理念,從消息的讀取、編碼以及后續(xù)Handler的執(zhí)行,始終都由IO線程NioEventLoop負責,這就意外著整個流程不會進行線程上下文的切換,數(shù)據(jù)也不會面臨被并發(fā)修改的風險,對于用戶而言,甚至不需要了解Netty的線程細節(jié),這確實是個非常好的設(shè)計理念,它的工作原理圖如下:

一個NioEventLoop聚合了一個多路復用器Selector,因此可以處理成百上千的客戶端連接,Netty的處理策略是每當有一個新的客戶端接入,則從NioEventLoop線程組中順序獲取一個可用的NioEventLoop,當?shù)竭_數(shù)組上限之后,重新返回到0,通過這種方式,可以基本保證各個NioEventLoop的負載均衡。一個客戶端連接只注冊到一個NioEventLoop上,這樣就避免了多個IO線程去并發(fā)操作它。
Netty通過串行化設(shè)計理念降低了用戶的開發(fā)難度,提升了處理性能。利用線程組實現(xiàn)了多個串行化線程水平并行執(zhí)行,線程之間并沒有交集,這樣既可以充分利用多核提升并行處理能力,同時避免了線程上下文的切換和并發(fā)保護帶來的額外性能損耗。
以上就是本文的全部內(nèi)容,希望對大家的學習有所幫助,也希望大家多多支持腳本之家。
相關(guān)文章
python實現(xiàn)兩個經(jīng)緯度點之間的距離和方位角的方法
今天小編就為大家分享一篇python實現(xiàn)兩個經(jīng)緯度點之間的距離和方位角的方法,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧2019-07-07
使用PIL(Python-Imaging)反轉(zhuǎn)圖像的顏色方法
今天小編就為大家分享一篇使用PIL(Python-Imaging)反轉(zhuǎn)圖像的顏色方法,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧2019-01-01
通過實例了解Python str()和repr()的區(qū)別
這篇文章主要介紹了通過實例了解Python str()和repr()的區(qū)別,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2020-01-01

