這可能是目前最透徹的Netty原理架構(gòu)解析

如果想學(xué)習(xí)Java工程化、高性能及分布式吃媒、深入淺出瓤介。性能調(diào)優(yōu)、Spring赘那,MyBatis刑桑,Netty源碼分析的朋友可以加我的Java高級(jí)架構(gòu)進(jìn)階群:180705916,群里有阿里大牛直播講解技術(shù)募舟,以及Java大型互聯(lián)網(wǎng)技術(shù)的視頻免費(fèi)分享給大家

Netty 是一個(gè)異步事件驅(qū)動(dòng)的網(wǎng)絡(luò)應(yīng)用程序框架祠斧,用于快速開發(fā)可維護(hù)的高性能協(xié)議服務(wù)器和客戶端。

JDK 原生 NIO 程序的問(wèn)題

JDK 原生也有一套網(wǎng)絡(luò)應(yīng)用程序 API拱礁,但是存在一系列問(wèn)題琢锋,主要如下:

NIO 的類庫(kù)和 API 繁雜,使用麻煩呢灶。你需要熟練掌握 Selector吴超、ServerSocketChannel、SocketChannel鸯乃、ByteBuffer 等鲸阻。

需要具備其他的額外技能做鋪墊。例如熟悉 Java 多線程編程,因?yàn)?NIO 編程涉及到 Reactor 模式赘娄,你必須對(duì)多線程和網(wǎng)路編程非常熟悉,才能編寫出高質(zhì)量的 NIO 程序宏蛉。

可靠性能力補(bǔ)齊遣臼,開發(fā)工作量和難度都非常大。例如客戶端面臨斷連重連拾并、網(wǎng)絡(luò)閃斷揍堰、半包讀寫、失敗緩存嗅义、網(wǎng)絡(luò)擁塞和異常碼流的處理等等屏歹。

NIO 編程的特點(diǎn)是功能開發(fā)相對(duì)容易,但是可靠性能力補(bǔ)齊工作量和難度都非常大之碗。

JDK NIO 的 Bug蝙眶。例如臭名昭著的 Epoll Bug,它會(huì)導(dǎo)致 Selector 空輪詢褪那,最終導(dǎo)致 CPU 100%幽纷。

官方聲稱在 JDK 1.6 版本的 update 18 修復(fù)了該問(wèn)題,但是直到 JDK 1.7 版本該問(wèn)題仍舊存在博敬,只不過(guò)該 Bug 發(fā)生概率降低了一些而已友浸,它并沒(méi)有被根本解決。

Netty 的特點(diǎn)

Netty 對(duì) JDK 自帶的 NIO 的 API 進(jìn)行封裝偏窝,解決上述問(wèn)題收恢,主要特點(diǎn)有:

設(shè)計(jì)優(yōu)雅,適用于各種傳輸類型的統(tǒng)一 API 阻塞和非阻塞 Socket祭往;基于靈活且可擴(kuò)展的事件模型伦意,可以清晰地分離關(guān)注點(diǎn);高度可定制的線程模型 - 單線程链沼,一個(gè)或多個(gè)線程池默赂;真正的無(wú)連接數(shù)據(jù)報(bào)套接字支持(自 3.1 起)。

使用方便括勺,詳細(xì)記錄的 Javadoc缆八,用戶指南和示例;沒(méi)有其他依賴項(xiàng)疾捍,JDK 5(Netty 3.x)或 6(Netty 4.x)就足夠了奈辰。

高性能,吞吐量更高乱豆,延遲更低奖恰;減少資源消耗;最小化不必要的內(nèi)存復(fù)制。

安全瑟啃,完整的 SSL/TLS 和 StartTLS 支持论泛。

社區(qū)活躍,不斷更新蛹屿,社區(qū)活躍屁奏,版本迭代周期短,發(fā)現(xiàn)的 Bug?可以被及時(shí)修復(fù)错负,同時(shí)坟瓢,更多的新功能會(huì)被加入。

Netty 常見使用場(chǎng)景

Netty 常見的使用場(chǎng)景如下:

互聯(lián)網(wǎng)行業(yè)犹撒。在分布式系統(tǒng)中折联,各個(gè)節(jié)點(diǎn)之間需要遠(yuǎn)程服務(wù)調(diào)用,高性能的 RPC 框架必不可少识颊,Netty 作為異步高性能的通信框架诚镰,往往作為基礎(chǔ)通信組件被這些 RPC 框架使用。

典型的應(yīng)用有:阿里分布式服務(wù)框架 Dubbo 的 RPC 框架使用 Dubbo 協(xié)議進(jìn)行節(jié)點(diǎn)間通信祥款,Dubbo 協(xié)議默認(rèn)使用 Netty 作為基礎(chǔ)通信組件怕享,用于實(shí)現(xiàn)各進(jìn)程節(jié)點(diǎn)之間的內(nèi)部通信。

游戲行業(yè)镰踏。無(wú)論是手游服務(wù)端還是大型的網(wǎng)絡(luò)游戲函筋,Java 語(yǔ)言得到了越來(lái)越廣泛的應(yīng)用。Netty 作為高性能的基礎(chǔ)通信組件奠伪,它本身提供了 TCP/UDP 和 HTTP 協(xié)議棧跌帐。

非常方便定制和開發(fā)私有協(xié)議棧,賬號(hào)登錄服務(wù)器绊率,地圖服務(wù)器之間可以方便的通過(guò) Netty 進(jìn)行高性能的通信谨敛。

大數(shù)據(jù)領(lǐng)域。經(jīng)典的 Hadoop 的高性能通信和序列化組件 Avro 的 RPC 框架滤否,默認(rèn)采用 Netty 進(jìn)行跨界點(diǎn)通信脸狸,它的 Netty Service 基于 Netty 框架二次封裝實(shí)現(xiàn)。

有興趣的讀者可以了解一下目前有哪些開源項(xiàng)目使用了 Netty:Related Projects藐俺。

Netty 高性能設(shè)計(jì)

Netty 作為異步事件驅(qū)動(dòng)的網(wǎng)絡(luò)炊甲,高性能之處主要來(lái)自于其 I/O 模型和線程處理模型,前者決定如何收發(fā)數(shù)據(jù)欲芹,后者決定如何處理數(shù)據(jù)卿啡。


I/O 模型

用什么樣的通道將數(shù)據(jù)發(fā)送給對(duì)方,BIO菱父、NIO 或者 AIO颈娜,I/O 模型在很大程度上決定了框架的性能剑逃。

阻塞 I/O

傳統(tǒng)阻塞型 I/O(BIO)可以用下圖表示:

Blocking I/O

特點(diǎn)如下:

每個(gè)請(qǐng)求都需要獨(dú)立的線程完成數(shù)據(jù) Read,業(yè)務(wù)處理官辽,數(shù)據(jù) Write 的完整操作問(wèn)題蛹磺。

當(dāng)并發(fā)數(shù)較大時(shí),需要?jiǎng)?chuàng)建大量線程來(lái)處理連接同仆,系統(tǒng)資源占用較大称开。

連接建立后,如果當(dāng)前線程暫時(shí)沒(méi)有數(shù)據(jù)可讀乓梨,則線程就阻塞在 Read 操作上,造成線程資源浪費(fèi)清酥。

I/O 復(fù)用模型

在 I/O 復(fù)用模型中扶镀,會(huì)用到 Select,這個(gè)函數(shù)也會(huì)使進(jìn)程阻塞焰轻,但是和阻塞 I/O 所不同的是這兩個(gè)函數(shù)可以同時(shí)阻塞多個(gè) I/O 操作臭觉。

而且可以同時(shí)對(duì)多個(gè)讀操作,多個(gè)寫操作的 I/O 函數(shù)進(jìn)行檢測(cè)辱志,直到有數(shù)據(jù)可讀或可寫時(shí)蝠筑,才真正調(diào)用 I/O 操作函數(shù)。

Netty 的非阻塞 I/O 的實(shí)現(xiàn)關(guān)鍵是基于 I/O 復(fù)用模型揩懒,這里用 Selector 對(duì)象表示:

Nonblocking I/O

Netty 的 IO 線程 NioEventLoop 由于聚合了多路復(fù)用器 Selector什乙,可以同時(shí)并發(fā)處理成百上千個(gè)客戶端連接。

當(dāng)線程從某客戶端 Socket 通道進(jìn)行讀寫數(shù)據(jù)時(shí)已球,若沒(méi)有數(shù)據(jù)可用時(shí)臣镣,該線程可以進(jìn)行其他任務(wù)。

線程通常將非阻塞 IO 的空閑時(shí)間用于在其他通道上執(zhí)行 IO 操作智亮,所以單獨(dú)的線程可以管理多個(gè)輸入和輸出通道忆某。

由于讀寫操作都是非阻塞的,這就可以充分提升 IO 線程的運(yùn)行效率阔蛉,避免由于頻繁 I/O 阻塞導(dǎo)致的線程掛起弃舒。

一個(gè) I/O 線程可以并發(fā)處理 N 個(gè)客戶端連接和讀寫操作,這從根本上解決了傳統(tǒng)同步阻塞 I/O 一連接一線程模型状原,架構(gòu)的性能聋呢、彈性伸縮能力和可靠性都得到了極大的提升。

基于 Buffer

傳統(tǒng)的 I/O 是面向字節(jié)流或字符流的颠区,以流式的方式順序地從一個(gè) Stream 中讀取一個(gè)或多個(gè)字節(jié), 因此也就不能隨意改變讀取指針的位置坝冕。

在 NIO 中,拋棄了傳統(tǒng)的 I/O 流瓦呼,而是引入了 Channel 和 Buffer 的概念喂窟。在 NIO 中测暗,只能從 Channel 中讀取數(shù)據(jù)到 Buffer 中或?qū)?shù)據(jù)從?Buffer 中寫入到 Channel。

基于 Buffer 操作不像傳統(tǒng) IO 的順序操作磨澡,NIO 中可以隨意地讀取任意位置的數(shù)據(jù)碗啄。


線程模型

數(shù)據(jù)報(bào)如何讀取稳摄?讀取之后的編解碼在哪個(gè)線程進(jìn)行稚字,編解碼后的消息如何派發(fā),線程模型的不同厦酬,對(duì)性能的影響也非常大胆描。

事件驅(qū)動(dòng)模型

通常,我們?cè)O(shè)計(jì)一個(gè)事件處理模型的程序有兩種思路:

輪詢方式仗阅,線程不斷輪詢?cè)L問(wèn)相關(guān)事件發(fā)生源有沒(méi)有發(fā)生事件昌讲,有發(fā)生事件就調(diào)用事件處理邏輯。

事件驅(qū)動(dòng)方式减噪,發(fā)生事件短绸,主線程把事件放入事件隊(duì)列,在另外線程不斷循環(huán)消費(fèi)事件列表中的事件筹裕,調(diào)用事件對(duì)應(yīng)的處理邏輯處理事件醋闭。事件驅(qū)動(dòng)方式也被稱為消息通知方式,其實(shí)是設(shè)計(jì)模式中觀察者模式的思路朝卒。

以 GUI 的邏輯處理為例证逻,說(shuō)明兩種邏輯的不同:

輪詢方式,線程不斷輪詢是否發(fā)生按鈕點(diǎn)擊事件抗斤,如果發(fā)生瑟曲,調(diào)用處理邏輯。

事件驅(qū)動(dòng)方式豪治,發(fā)生點(diǎn)擊事件把事件放入事件隊(duì)列洞拨,在另外線程消費(fèi)的事件列表中的事件,根據(jù)事件類型調(diào)用相關(guān)事件處理邏輯负拟。

這里借用 O'Reilly 大神關(guān)于事件驅(qū)動(dòng)模型解釋圖:

事件驅(qū)動(dòng)模型

主要包括 4 個(gè)基本組件:

事件隊(duì)列(event queue):接收事件的入口烦衣,存儲(chǔ)待處理事件。

分發(fā)器(event mediator):將不同的事件分發(fā)到不同的業(yè)務(wù)邏輯單元掩浙。

事件通道(event channel):分發(fā)器與處理器之間的聯(lián)系渠道花吟。

事件處理器(event processor):實(shí)現(xiàn)業(yè)務(wù)邏輯,處理完成后會(huì)發(fā)出事件厨姚,觸發(fā)下一步操作衅澈。

可以看出,相對(duì)傳統(tǒng)輪詢模式谬墙,事件驅(qū)動(dòng)有如下優(yōu)點(diǎn):

可擴(kuò)展性好今布,分布式的異步架構(gòu)经备,事件處理器之間高度解耦,可以方便擴(kuò)展事件處理邏輯部默。

高性能侵蒙,基于隊(duì)列暫存事件,能方便并行異步處理事件傅蹂。

Reactor 線程模型

Reactor 是反應(yīng)堆的意思纷闺,Reactor 模型是指通過(guò)一個(gè)或多個(gè)輸入同時(shí)傳遞給服務(wù)處理器的服務(wù)請(qǐng)求的事件驅(qū)動(dòng)處理模式。

服務(wù)端程序處理傳入多路請(qǐng)求份蝴,并將它們同步分派給請(qǐng)求對(duì)應(yīng)的處理線程犁功,Reactor 模式也叫 Dispatcher 模式,即 I/O 多了復(fù)用統(tǒng)一監(jiān)聽事件婚夫,收到事件后分發(fā)(Dispatch 給某進(jìn)程)浸卦,是編寫高性能網(wǎng)絡(luò)服務(wù)器的必備技術(shù)之一。

Reactor 模型中有 2 個(gè)關(guān)鍵組成:

Reactor请敦,Reactor 在一個(gè)單獨(dú)的線程中運(yùn)行,負(fù)責(zé)監(jiān)聽和分發(fā)事件储玫,分發(fā)給適當(dāng)?shù)奶幚沓绦騺?lái)對(duì) IO 事件做出反應(yīng)侍筛。它就像公司的電話接線員,它接聽來(lái)自客戶的電話并將線路轉(zhuǎn)移到適當(dāng)?shù)穆?lián)系人撒穷。

Handlers匣椰,處理程序執(zhí)行 I/O 事件要完成的實(shí)際事件,類似于客戶想要與之交談的公司中的實(shí)際官員端礼。Reactor 通過(guò)調(diào)度適當(dāng)?shù)奶幚沓绦騺?lái)響應(yīng) I/O 事件禽笑,處理程序執(zhí)行非阻塞操作。

Reactor 模型

取決于 Reactor 的數(shù)量和 Hanndler 線程數(shù)量的不同蛤奥,Reactor 模型有 3 個(gè)變種:

單 Reactor 單線程佳镜。

單 Reactor 多線程。

主從 Reactor 多線程凡桥。

可以這樣理解,Reactor 就是一個(gè)執(zhí)行 while (true) { selector.select(); …} 循環(huán)的線程,會(huì)源源不斷的產(chǎn)生新的事件癞谒,稱作反應(yīng)堆很貼切梗搅。

篇幅關(guān)系,這里不再具體展開 Reactor 特性衰猛、優(yōu)缺點(diǎn)比較迟蜜,有興趣的讀者可以參考我之前另外一篇文章:《理解高性能網(wǎng)絡(luò)模型》

Netty 線程模型

Netty 主要基于主從 Reactors 多線程模型(如下圖)做了一定的修改啡省,其中主從 Reactor 多線程模型有多個(gè) Reactor:

MainReactor 負(fù)責(zé)客戶端的連接請(qǐng)求娜睛,并將請(qǐng)求轉(zhuǎn)交給 SubReactor髓霞。

SubReactor 負(fù)責(zé)相應(yīng)通道的 IO 讀寫請(qǐng)求。

非 IO 請(qǐng)求(具體邏輯處理)的任務(wù)則會(huì)直接寫入隊(duì)列微姊,等待 worker threads 進(jìn)行處理酸茴。

這里引用 Doug Lee 大神的 Reactor 介紹:Scalable IO in Java 里面關(guān)于主從 Reactor 多線程模型的圖:

主從 Rreactor 多線程模型

特別說(shuō)明的是:雖然 Netty 的線程模型基于主從 Reactor 多線程,借用了 MainReactor 和 SubReactor 的結(jié)構(gòu)兢交。但是實(shí)際實(shí)現(xiàn)上 SubReactor 和 Worker 線程在同一個(gè)線程池中:

EventLoopGroup?bossGroup?=newNioEventLoopGroup();

EventLoopGroup?workerGroup?=newNioEventLoopGroup();

ServerBootstrapserver=newServerBootstrap();

server.group(bossGroup,?workerGroup)

.channel(NioServerSocketChannel.class)

上面代碼中的 bossGroup 和 workerGroup 是 Bootstrap 構(gòu)造方法中傳入的兩個(gè)對(duì)象薪捍,這兩個(gè) group 均是線程池:

bossGroup 線程池則只是在 Bind 某個(gè)端口后,獲得其中一個(gè)線程作為 MainReactor配喳,專門處理端口的 Accept 事件酪穿,每個(gè)端口對(duì)應(yīng)一個(gè) Boss 線程。

workerGroup 線程池會(huì)被各個(gè) SubReactor 和 Worker 線程充分利用晴裹。

異步處理

異步的概念和同步相對(duì)被济。當(dāng)一個(gè)異步過(guò)程調(diào)用發(fā)出后,調(diào)用者不能立刻得到結(jié)果涧团。實(shí)際處理這個(gè)調(diào)用的部件在完成后只磷,通過(guò)狀態(tài)、通知和回調(diào)來(lái)通知調(diào)用者泌绣。

Netty 中的 I/O 操作是異步的钮追,包括 Bind、Write阿迈、Connect 等操作會(huì)簡(jiǎn)單的返回一個(gè) ChannelFuture元媚。

調(diào)用者并不能立刻獲得結(jié)果,而是通過(guò) Future-Listener 機(jī)制苗沧,用戶可以方便的主動(dòng)獲取或者通過(guò)通知機(jī)制獲得 IO 操作結(jié)果刊棕。

當(dāng) Future 對(duì)象剛剛創(chuàng)建時(shí),處于非完成狀態(tài)待逞,調(diào)用者可以通過(guò)返回的 ChannelFuture 來(lái)獲取操作執(zhí)行的狀態(tài)甥角,注冊(cè)監(jiān)聽函數(shù)來(lái)執(zhí)行完成后的操作。

常見有如下操作:

通過(guò) isDone 方法來(lái)判斷當(dāng)前操作是否完成识樱。

通過(guò) isSuccess 方法來(lái)判斷已完成的當(dāng)前操作是否成功蜈膨。

通過(guò) getCause 方法來(lái)獲取已完成的當(dāng)前操作失敗的原因。

通過(guò) isCancelled 方法來(lái)判斷已完成的當(dāng)前操作是否被取消牺荠。

通過(guò) addListener 方法來(lái)注冊(cè)監(jiān)聽器翁巍,當(dāng)操作已完成(isDone 方法返回完成),將會(huì)通知指定的監(jiān)聽器休雌;如果 Future 對(duì)象已完成灶壶,則理解通知指定的監(jiān)聽器。

例如下面的代碼中綁定端口是異步操作杈曲,當(dāng)綁定操作處理完驰凛,將會(huì)調(diào)用相應(yīng)的監(jiān)聽器處理邏輯胸懈。

serverBootstrap.bind(port).addListener(future?->?{

if(future.isSuccess())?{

System.out.println(newDate()?+":?端口["+?port?+"]綁定成功!");

}else{

System.err.println("端口["+?port?+"]綁定失敗!");

}

});

相比傳統(tǒng)阻塞 I/O,執(zhí)行 I/O 操作后線程會(huì)被阻塞住, 直到操作完成恰响;異步處理的好處是不會(huì)造成線程阻塞趣钱,線程在 I/O 操作期間可以執(zhí)行別的程序,在高并發(fā)情形下會(huì)更穩(wěn)定和更高的吞吐量胚宦。

Netty 架構(gòu)設(shè)計(jì)

前面介紹完 Netty 相關(guān)一些理論首有,下面從功能特性、模塊組件枢劝、運(yùn)作過(guò)程來(lái)介紹 Netty 的架構(gòu)設(shè)計(jì)井联。


功能特性

Netty 功能特性如下:

傳輸服務(wù),支持 BIO 和 NIO您旁。

容器集成烙常,支持 OSGI、JBossMC鹤盒、Spring蚕脏、Guice 容器。

協(xié)議支持侦锯,HTTP驼鞭、Protobuf、二進(jìn)制率触、文本终议、WebSocket 等一系列常見協(xié)議都支持汇竭。還支持通過(guò)實(shí)行編碼解碼邏輯來(lái)實(shí)現(xiàn)自定義協(xié)議葱蝗。

Core 核心,可擴(kuò)展事件模型细燎、通用通信 API两曼、支持零拷貝的 ByteBuf 緩沖對(duì)象。


模塊組件

Bootstrap玻驻、ServerBootstrap

Bootstrap 意思是引導(dǎo)悼凑,一個(gè) Netty 應(yīng)用通常由一個(gè) Bootstrap 開始,主要作用是配置整個(gè) Netty 程序璧瞬,串聯(lián)各個(gè)組件户辫,Netty 中 Bootstrap 類是客戶端程序的啟動(dòng)引導(dǎo)類,ServerBootstrap 是服務(wù)端啟動(dòng)引導(dǎo)類嗤锉。

Future渔欢、ChannelFuture

正如前面介紹,在 Netty 中所有的 IO 操作都是異步的瘟忱,不能立刻得知消息是否被正確處理奥额。

但是可以過(guò)一會(huì)等它執(zhí)行完成或者直接注冊(cè)一個(gè)監(jiān)聽苫幢,具體的實(shí)現(xiàn)就是通過(guò) Future 和 ChannelFutures,他們可以注冊(cè)一個(gè)監(jiān)聽垫挨,當(dāng)操作執(zhí)行成功或失敗時(shí)監(jiān)聽會(huì)自動(dòng)觸發(fā)注冊(cè)的監(jiān)聽事件韩肝。

Channel

Netty 網(wǎng)絡(luò)通信的組件,能夠用于執(zhí)行網(wǎng)絡(luò) I/O 操作九榔。Channel 為用戶提供:

當(dāng)前網(wǎng)絡(luò)連接的通道的狀態(tài)(例如是否打開哀峻?是否已連接?)

網(wǎng)絡(luò)連接的配置參數(shù) (例如接收緩沖區(qū)大兄闾搿)

提供異步的網(wǎng)絡(luò) I/O 操作(如建立連接谜诫,讀寫,綁定端口)攻旦,異步調(diào)用意味著任何 I/O 調(diào)用都將立即返回喻旷,并且不保證在調(diào)用結(jié)束時(shí)所請(qǐng)求的 I/O 操作已完成。

調(diào)用立即返回一個(gè) ChannelFuture 實(shí)例牢屋,通過(guò)注冊(cè)監(jiān)聽器到 ChannelFuture 上且预,可以 I/O 操作成功、失敗或取消時(shí)回調(diào)通知調(diào)用方烙无。

支持關(guān)聯(lián) I/O 操作與對(duì)應(yīng)的處理程序锋谐。

不同協(xié)議、不同的阻塞類型的連接都有不同的 Channel 類型與之對(duì)應(yīng)截酷。下面是一些常用的 Channel 類型:

NioSocketChannel涮拗,異步的客戶端 TCP Socket 連接。

NioServerSocketChannel迂苛,異步的服務(wù)器端 TCP Socket 連接三热。

NioDatagramChannel,異步的 UDP 連接三幻。

NioSctpChannel就漾,異步的客戶端 Sctp 連接。

NioSctpServerChannel念搬,異步的 Sctp 服務(wù)器端連接抑堡,這些通道涵蓋了 UDP 和 TCP 網(wǎng)絡(luò) IO 以及文件 IO。

Selector

Netty 基于 Selector 對(duì)象實(shí)現(xiàn) I/O 多路復(fù)用朗徊,通過(guò) Selector 一個(gè)線程可以監(jiān)聽多個(gè)連接的 Channel 事件首妖。

當(dāng)向一個(gè) Selector 中注冊(cè) Channel 后,Selector 內(nèi)部的機(jī)制就可以自動(dòng)不斷地查詢(Select) 這些注冊(cè)的 Channel 是否有已就緒的 I/O 事件(例如可讀爷恳,可寫有缆,網(wǎng)絡(luò)連接完成等),這樣程序就可以很簡(jiǎn)單地使用一個(gè)線程高效地管理多個(gè) Channel 。

NioEventLoop

NioEventLoop 中維護(hù)了一個(gè)線程和任務(wù)隊(duì)列妒貌,支持異步提交執(zhí)行任務(wù)通危,線程啟動(dòng)時(shí)會(huì)調(diào)用 NioEventLoop 的 run 方法,執(zhí)行 I/O 任務(wù)和非 I/O 任務(wù):

I/O 任務(wù)灌曙,即 selectionKey 中 ready 的事件菊碟,如 accept、connect在刺、read逆害、write 等,由 processSelectedKeys 方法觸發(fā)蚣驼。

非 IO 任務(wù)魄幕,添加到 taskQueue 中的任務(wù),如 register0颖杏、bind0 等任務(wù)纯陨,由 runAllTasks 方法觸發(fā)。

兩種任務(wù)的執(zhí)行時(shí)間比由變量 ioRatio 控制留储,默認(rèn)為 50翼抠,則表示允許非 IO 任務(wù)執(zhí)行的時(shí)間與 IO 任務(wù)的執(zhí)行時(shí)間相等。

NioEventLoopGroup

NioEventLoopGroup获讳,主要管理 eventLoop 的生命周期阴颖,可以理解為一個(gè)線程池,內(nèi)部維護(hù)了一組線程丐膝,每個(gè)線程(NioEventLoop)負(fù)責(zé)處理多個(gè) Channel 上的事件量愧,而一個(gè) Channel 只對(duì)應(yīng)于一個(gè)線程。

ChannelHandler

ChannelHandler 是一個(gè)接口帅矗,處理 I/O 事件或攔截 I/O 操作偎肃,并將其轉(zhuǎn)發(fā)到其 ChannelPipeline(業(yè)務(wù)處理鏈)中的下一個(gè)處理程序。

ChannelHandler 本身并沒(méi)有提供很多方法损晤,因?yàn)檫@個(gè)接口有許多的方法需要實(shí)現(xiàn)软棺,方便使用期間红竭,可以繼承它的子類:

ChannelInboundHandler 用于處理入站 I/O 事件尤勋。

ChannelOutboundHandler 用于處理出站 I/O 操作。

或者使用以下適配器類:

ChannelInboundHandlerAdapter 用于處理入站 I/O 事件茵宪。

ChannelOutboundHandlerAdapter 用于處理出站 I/O 操作最冰。

ChannelDuplexHandler 用于處理入站和出站事件。

ChannelHandlerContext

保存 Channel 相關(guān)的所有上下文信息稀火,同時(shí)關(guān)聯(lián)一個(gè) ChannelHandler 對(duì)象暖哨。

ChannelPipline

保存 ChannelHandler 的 List,用于處理或攔截 Channel 的入站事件和出站操作凰狞。

ChannelPipeline 實(shí)現(xiàn)了一種高級(jí)形式的攔截過(guò)濾器模式篇裁,使用戶可以完全控制事件的處理方式沛慢,以及 Channel 中各個(gè)的 ChannelHandler 如何相互交互。

下圖引用 Netty 的 Javadoc 4.1 中 ChannelPipeline 的說(shuō)明达布,描述了 ChannelPipeline 中 ChannelHandler 通常如何處理 I/O 事件团甲。

I/O 事件由 ChannelInboundHandler 或 ChannelOutboundHandler 處理,并通過(guò)調(diào)用 ChannelHandlerContext 中定義的事件傳播方法黍聂。

例如 ChannelHandlerContext.fireChannelRead(Object)和 ChannelOutboundInvoker.write(Object)轉(zhuǎn)發(fā)到其最近的處理程序躺苦。

入站事件由自下而上方向的入站處理程序處理,如圖左側(cè)所示产还。入站 Handler 處理程序通常處理由圖底部的 I/O 線程生成的入站數(shù)據(jù)匹厘。

通常通過(guò)實(shí)際輸入操作(例如 SocketChannel.read(ByteBuffer))從遠(yuǎn)程讀取入站數(shù)據(jù)。

出站事件由上下方向處理脐区,如圖右側(cè)所示愈诚。出站 Handler 處理程序通常會(huì)生成或轉(zhuǎn)換出站傳輸,例如 write 請(qǐng)求牛隅。

I/O 線程通常執(zhí)行實(shí)際的輸出操作扰路,例如 SocketChannel.write(ByteBuffer)。

在 Netty 中每個(gè) Channel 都有且僅有一個(gè) ChannelPipeline 與之對(duì)應(yīng)倔叼,它們的組成關(guān)系如下:

一個(gè) Channel 包含了一個(gè) ChannelPipeline汗唱,而 ChannelPipeline 中又維護(hù)了一個(gè)由 ChannelHandlerContext 組成的雙向鏈表,并且每個(gè) ChannelHandlerContext 中又關(guān)聯(lián)著一個(gè) ChannelHandler丈攒。

入站事件和出站事件在一個(gè)雙向鏈表中哩罪,入站事件會(huì)從鏈表 head 往后傳遞到最后一個(gè)入站的 handler,出站事件會(huì)從鏈表 tail 往前傳遞到最前一個(gè)出站的 handler巡验,兩種類型的 handler 互不干擾际插。

Netty?工作原理架構(gòu)

初始化并啟動(dòng) Netty 服務(wù)端過(guò)程如下:

publicstaticvoidmain(String[]?args){

//?創(chuàng)建mainReactor

NioEventLoopGroup?boosGroup?=newNioEventLoopGroup();

//?創(chuàng)建工作線程組

NioEventLoopGroup?workerGroup?=newNioEventLoopGroup();

final?ServerBootstrap?serverBootstrap?=newServerBootstrap();

serverBootstrap

//?組裝NioEventLoopGroup?

.group(boosGroup,?workerGroup)

//?設(shè)置channel類型為NIO類型

.channel(NioServerSocketChannel.class)

//?設(shè)置連接配置參數(shù)

.option(ChannelOption.SO_BACKLOG,1024)

.childOption(ChannelOption.SO_KEEPALIVE,true)

.childOption(ChannelOption.TCP_NODELAY,true)

//?配置入站、出站事件handler

.childHandler(newChannelInitializer()?{

@Override

protectedvoidinitChannel(NioSocketChannel?ch)

{

//?配置入站显设、出站事件channel

ch.pipeline().addLast(...);

ch.pipeline().addLast(...);

}

});

//?綁定端口

intport?=8080;

serverBootstrap.bind(port).addListener(future?->?{

if(future.isSuccess())?{

System.out.println(newDate()?+":?端口["+?port?+"]綁定成功!");

}else{

System.err.println("端口["+?port?+"]綁定失敗!");

}

});

}

基本過(guò)程如下:

初始化創(chuàng)建 2 個(gè) NioEventLoopGroup框弛,其中 boosGroup 用于 Accetpt 連接建立事件并分發(fā)請(qǐng)求,workerGroup 用于處理 I/O 讀寫事件和業(yè)務(wù)邏輯捕捂。

基于 ServerBootstrap(服務(wù)端啟動(dòng)引導(dǎo)類)瑟枫,配置 EventLoopGroup、Channel 類型指攒,連接參數(shù)慷妙、配置入站、出站事件 handler允悦。

綁定端口膝擂,開始工作。

結(jié)合上面介紹的 Netty Reactor 模型,介紹服務(wù)端 Netty 的工作架構(gòu)圖:

服務(wù)端 Netty Reactor 工作架構(gòu)圖

Server 端包含 1 個(gè) Boss NioEventLoopGroup 和 1 個(gè) Worker NioEventLoopGroup架馋。

NioEventLoopGroup 相當(dāng)于 1 個(gè)事件循環(huán)組狞山,這個(gè)組里包含多個(gè)事件循環(huán) NioEventLoop,每個(gè) NioEventLoop 包含 1 個(gè) Selector 和 1 個(gè)事件循環(huán)線程叉寂。

每個(gè) Boss NioEventLoop 循環(huán)執(zhí)行的任務(wù)包含 3 步:

輪詢 Accept 事件铣墨。

處理 Accept I/O 事件,與 Client 建立連接办绝,生成 NioSocketChannel伊约,并將 NioSocketChannel 注冊(cè)到某個(gè) Worker NioEventLoop 的 Selector 上。

處理任務(wù)隊(duì)列中的任務(wù)孕蝉,runAllTasks屡律。任務(wù)隊(duì)列中的任務(wù)包括用戶調(diào)用 eventloop.execute 或 schedule 執(zhí)行的任務(wù),或者其他線程提交到該 eventloop 的任務(wù)降淮。

每個(gè) Worker NioEventLoop 循環(huán)執(zhí)行的任務(wù)包含 3 步:

輪詢 Read超埋、Write 事件。

處理?I/O 事件佳鳖,即 Read霍殴、Write 事件,在 NioSocketChannel 可讀系吩、可寫事件發(fā)生時(shí)進(jìn)行處理来庭。

處理任務(wù)隊(duì)列中的任務(wù),runAllTasks穿挨。

其中任務(wù)隊(duì)列中的 Task 有 3 種典型使用場(chǎng)景月弛。

①用戶程序自定義的普通任務(wù)

ctx.channel().eventLoop().execute(newRunnable()?{

@Override

publicvoidrun(){

//...

}

});

②非當(dāng)前 Reactor 線程調(diào)用 Channel 的各種方法

例如在推送系統(tǒng)的業(yè)務(wù)線程里面,根據(jù)用戶的標(biāo)識(shí)科盛,找到對(duì)應(yīng)的 Channel 引用帽衙,然后調(diào)用 Write 類方法向該用戶推送消息,就會(huì)進(jìn)入到這種場(chǎng)景贞绵。最終的 Write 會(huì)提交到任務(wù)隊(duì)列中后被異步消費(fèi)厉萝。

③用戶自定義定時(shí)任務(wù)

ctx.channel().eventLoop().schedule(newRunnable()?{

@Override

publicvoidrun(){

}

},60,?TimeUnit.SECONDS);

總結(jié)

現(xiàn)在穩(wěn)定推薦使用的主流版本還是 Netty4,Netty5 中使用了 ForkJoinPool榨崩,增加了代碼的復(fù)雜度谴垫,但是對(duì)性能的改善卻不明顯,所以這個(gè)版本不推薦使用蜡饵,官網(wǎng)也沒(méi)有提供下載鏈接弹渔。

Netty 入門門檻相對(duì)較高胳施,是因?yàn)檫@方面的資料較少溯祸,并不是因?yàn)樗卸嚯y,大家其實(shí)都可以像搞透 Spring 一樣搞透 Netty。

在學(xué)習(xí)之前焦辅,建議先理解透整個(gè)框架原理結(jié)構(gòu)博杖,運(yùn)行過(guò)程,可以少走很多彎路筷登。

如果想學(xué)習(xí)Java工程化剃根、高性能及分布式、深入淺出前方。性能調(diào)優(yōu)狈醉、Spring,MyBatis惠险,Netty源碼分析的朋友可以加我的Java高級(jí)架構(gòu)進(jìn)階群:180705916苗傅,群里有阿里大牛直播講解技術(shù),以及Java大型互聯(lián)網(wǎng)技術(shù)的視頻免費(fèi)分享給大家

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末班巩,一起剝皮案震驚了整個(gè)濱河市渣慕,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌抱慌,老刑警劉巖逊桦,帶你破解...
    沈念sama閱讀 222,729評(píng)論 6 517
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異抑进,居然都是意外死亡强经,警方通過(guò)查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 95,226評(píng)論 3 399
  • 文/潘曉璐 我一進(jìn)店門寺渗,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái)夕凝,“玉大人,你說(shuō)我怎么就攤上這事户秤÷氡” “怎么了?”我有些...
    開封第一講書人閱讀 169,461評(píng)論 0 362
  • 文/不壞的土叔 我叫張陵鸡号,是天一觀的道長(zhǎng)转砖。 經(jīng)常有香客問(wèn)我,道長(zhǎng)鲸伴,這世上最難降的妖魔是什么府蔗? 我笑而不...
    開封第一講書人閱讀 60,135評(píng)論 1 300
  • 正文 為了忘掉前任,我火速辦了婚禮汞窗,結(jié)果婚禮上姓赤,老公的妹妹穿的比我還像新娘。我一直安慰自己仲吏,他們只是感情好不铆,可當(dāng)我...
    茶點(diǎn)故事閱讀 69,130評(píng)論 6 398
  • 文/花漫 我一把揭開白布蝌焚。 她就那樣靜靜地躺著,像睡著了一般誓斥。 火紅的嫁衣襯著肌膚如雪只洒。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 52,736評(píng)論 1 312
  • 那天劳坑,我揣著相機(jī)與錄音毕谴,去河邊找鬼。 笑死距芬,一個(gè)胖子當(dāng)著我的面吹牛涝开,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播框仔,決...
    沈念sama閱讀 41,179評(píng)論 3 422
  • 文/蒼蘭香墨 我猛地睜開眼忠寻,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼!你這毒婦竟也來(lái)了存和?” 一聲冷哼從身側(cè)響起奕剃,我...
    開封第一講書人閱讀 40,124評(píng)論 0 277
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤,失蹤者是張志新(化名)和其女友劉穎捐腿,沒(méi)想到半個(gè)月后纵朋,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 46,657評(píng)論 1 320
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡茄袖,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,723評(píng)論 3 342
  • 正文 我和宋清朗相戀三年操软,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片宪祥。...
    茶點(diǎn)故事閱讀 40,872評(píng)論 1 353
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡聂薪,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出蝗羊,到底是詐尸還是另有隱情藏澳,我是刑警寧澤,帶...
    沈念sama閱讀 36,533評(píng)論 5 351
  • 正文 年R本政府宣布耀找,位于F島的核電站翔悠,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏野芒。R本人自食惡果不足惜蓄愁,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 42,213評(píng)論 3 336
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望狞悲。 院中可真熱鬧撮抓,春花似錦、人聲如沸摇锋。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,700評(píng)論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至咽笼,卻和暖如春顷编,著一層夾襖步出監(jiān)牢的瞬間戚炫,已是汗流浹背剑刑。 一陣腳步聲響...
    開封第一講書人閱讀 33,819評(píng)論 1 274
  • 我被黑心中介騙來(lái)泰國(guó)打工, 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留双肤,地道東北人施掏。 一個(gè)月前我還...
    沈念sama閱讀 49,304評(píng)論 3 379
  • 正文 我出身青樓,卻偏偏與公主長(zhǎng)得像茅糜,于是被迫代替她去往敵國(guó)和親七芭。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,876評(píng)論 2 361

推薦閱讀更多精彩內(nèi)容