Netty知行 - 簡書

本文基于 Netty 4.1 展開介紹相關(guān)理論模型壶笼，使用場景神僵，基本組件、整體架構(gòu)覆劈，知其然且知其所以然保礼，希望給大家在實際開發(fā)實踐、學(xué)習(xí)開源項目方面提供參考责语。

圖片.png

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

JDK 原生 NIO 程序的問題

JDK 原生也有一套網(wǎng)絡(luò)應(yīng)用程序 API坤候，但是存在一系列問題铝阐，主要如下：

NIO 的類庫和 API 繁雜，使用麻煩铐拐。你需要熟練掌握 Selector徘键、ServerSocketChannel练对、SocketChannel、ByteBuffer 等吹害。
需要具備其他的額外技能做鋪墊螟凭。例如熟悉 Java 多線程編程，因為 NIO 編程涉及到 Reactor 模式它呀，你必須對多線程和網(wǎng)路編程非常熟悉螺男，才能編寫出高質(zhì)量的 NIO 程序。
可靠性能力補齊纵穿，開發(fā)工作量和難度都非常大下隧。例如客戶端面臨斷連重連、網(wǎng)絡(luò)閃斷谓媒、半包讀寫淆院、失敗緩存、網(wǎng)絡(luò)擁塞和異常碼流的處理等等句惯。 NIO 編程的特點是功能開發(fā)相對容易土辩，但是可靠性能力補齊工作量和難度都非常大。
JDK NIO 的 Bug抢野。例如臭名昭著的 Epoll Bug拷淘，它會導(dǎo)致 Selector 空輪詢，最終導(dǎo)致 CPU 100%指孤。官方聲稱在 JDK 1.6 版本的 update 18 修復(fù)了該問題启涯，但是直到 JDK 1.7 版本該問題仍舊存在，只不過該 Bug 發(fā)生概率降低了一些而已恃轩，它并沒有被根本解決结洼。

Netty 的特點

Netty 對 JDK 自帶的 NIO 的 API 進(jìn)行封裝，解決上述問題详恼，主要特點有：

設(shè)計優(yōu)雅，適用于各種傳輸類型的統(tǒng)一 API 阻塞和非阻塞 Socket引几；基于靈活且可擴(kuò)展的事件模型昧互，可以清晰地分離關(guān)注點；高度可定制的線程模型 - 單線程伟桅，一個或多個線程池敞掘；真正的無連接數(shù)據(jù)報套接字支持（自 3.1 起）。
使用方便楣铁，詳細(xì)記錄的 Javadoc玖雁，用戶指南和示例；沒有其他依賴項盖腕，JDK 5（Netty 3.x）或 6（Netty 4.x）就足夠了赫冬。
高性能浓镜，吞吐量更高，延遲更低劲厌；減少資源消耗膛薛；最小化不必要的內(nèi)存復(fù)制。
安全补鼻，完整的 SSL/TLS 和 StartTLS 支持哄啄。
社區(qū)活躍，不斷更新风范，社區(qū)活躍咨跌，版本迭代周期短，發(fā)現(xiàn)的 Bug 可以被及時修復(fù)硼婿，同時锌半，更多的新功能會被加入。

Netty 常見使用場景

Netty 常見的使用場景如下：

互聯(lián)網(wǎng)行業(yè)加酵。在分布式系統(tǒng)中拳喻，各個節(jié)點之間需要遠(yuǎn)程服務(wù)調(diào)用，高性能的 RPC 框架必不可少猪腕，Netty 作為異步高性能的通信框架冗澈，往往作為基礎(chǔ)通信組件被這些 RPC 框架使用。典型的應(yīng)用有：阿里分布式服務(wù)框架 Dubbo 的 RPC 框架使用 Dubbo 協(xié)議進(jìn)行節(jié)點間通信陋葡，Dubbo 協(xié)議默認(rèn)使用 Netty 作為基礎(chǔ)通信組件亚亲，用于實現(xiàn)各進(jìn)程節(jié)點之間的內(nèi)部通信。
游戲行業(yè)腐缤。無論是手游服務(wù)端還是大型的網(wǎng)絡(luò)游戲捌归，Java 語言得到了越來越廣泛的應(yīng)用。Netty 作為高性能的基礎(chǔ)通信組件岭粤，它本身提供了 TCP/UDP 和 HTTP 協(xié)議棧惜索。非常方便定制和開發(fā)私有協(xié)議棧，賬號登錄服務(wù)器剃浇，地圖服務(wù)器之間可以方便的通過 Netty 進(jìn)行高性能的通信巾兆。
大數(shù)據(jù)領(lǐng)域。經(jīng)典的 Hadoop 的高性能通信和序列化組件 Avro 的 RPC 框架，默認(rèn)采用 Netty 進(jìn)行跨界點通信，它的 Netty Service 基于 Netty 框架二次封裝實現(xiàn)嚼蚀。

有興趣的讀者可以了解一下目前有哪些開源項目使用了 Netty：Related Projects解藻。

Netty 高性能設(shè)計

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

I/O 模型

用什么樣的通道將數(shù)據(jù)發(fā)送給對方窒朋，BIO搀罢、NIO 或者 AIO，I/O 模型在很大程度上決定了框架的性能炼邀。

阻塞 I/O

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

image

Blocking I/O

特點如下：

每個請求都需要獨立的線程完成數(shù)據(jù) Read，業(yè)務(wù)處理拭宁，數(shù)據(jù) Write 的完整操作問題洛退。
當(dāng)并發(fā)數(shù)較大時，需要創(chuàng)建大量線程來處理連接杰标，系統(tǒng)資源占用較大兵怯。
連接建立后，如果當(dāng)前線程暫時沒有數(shù)據(jù)可讀腔剂，則線程就阻塞在 Read 操作上媒区，造成線程資源浪費。

I/O 復(fù)用模型

image

在 I/O 復(fù)用模型中掸犬，會用到 Select袜漩，這個函數(shù)也會使進(jìn)程阻塞，但是和阻塞 I/O 所不同的是這兩個函數(shù)可以同時阻塞多個 I/O 操作湾碎。

而且可以同時對多個讀操作宙攻，多個寫操作的 I/O 函數(shù)進(jìn)行檢測，直到有數(shù)據(jù)可讀或可寫時介褥，才真正調(diào)用 I/O 操作函數(shù)座掘。

Netty 的非阻塞 I/O 的實現(xiàn)關(guān)鍵是基于 I/O 復(fù)用模型，這里用 Selector 對象表示：

image

Nonblocking I/O

Netty 的 IO 線程 NioEventLoop 由于聚合了多路復(fù)用器 Selector柔滔，可以同時并發(fā)處理成百上千個客戶端連接溢陪。

當(dāng)線程從某客戶端 Socket 通道進(jìn)行讀寫數(shù)據(jù)時，若沒有數(shù)據(jù)可用時睛廊，該線程可以進(jìn)行其他任務(wù)形真。

線程通常將非阻塞 IO 的空閑時間用于在其他通道上執(zhí)行 IO 操作，所以單獨的線程可以管理多個輸入和輸出通道超全。

由于讀寫操作都是非阻塞的咆霜，這就可以充分提升 IO 線程的運行效率，避免由于頻繁 I/O 阻塞導(dǎo)致的線程掛起卵迂。

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

基于 Buffer

傳統(tǒng)的 I/O 是面向字節(jié)流或字符流的挂疆，以流式的方式順序地從一個 Stream 中讀取一個或多個字節(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ù)報如何讀取订晌？讀取之后的編解碼在哪個線程進(jìn)行虏辫，編解碼后的消息如何派發(fā)，線程模型的不同锈拨，對性能的影響也非常大砌庄。

事件驅(qū)動模型

通常，我們設(shè)計一個事件處理模型的程序有兩種思路：

輪詢方式奕枢，線程不斷輪詢訪問相關(guān)事件發(fā)生源有沒有發(fā)生事件娄昆，有發(fā)生事件就調(diào)用事件處理邏輯。
事件驅(qū)動方式缝彬，發(fā)生事件萌焰，主線程把事件放入事件隊列，在另外線程不斷循環(huán)消費事件列表中的事件跌造，調(diào)用事件對應(yīng)的處理邏輯處理事件杆怕。事件驅(qū)動方式也被稱為消息通知方式，其實是設(shè)計模式中觀察者模式的思路壳贪。

以 GUI 的邏輯處理為例陵珍，說明兩種邏輯的不同：

輪詢方式，線程不斷輪詢是否發(fā)生按鈕點擊事件违施，如果發(fā)生互纯，調(diào)用處理邏輯。
事件驅(qū)動方式磕蒲，發(fā)生點擊事件把事件放入事件隊列留潦，在另外線程消費的事件列表中的事件，根據(jù)事件類型調(diào)用相關(guān)事件處理邏輯辣往。

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

image

事件驅(qū)動模型

主要包括 4 個基本組件：

事件隊列（event queue）：接收事件的入口兔院，存儲待處理事件。
分發(fā)器（event mediator）：將不同的事件分發(fā)到不同的業(yè)務(wù)邏輯單元站削。
事件通道（event channel）：分發(fā)器與處理器之間的聯(lián)系渠道坊萝。
事件處理器（event processor）：實現(xiàn)業(yè)務(wù)邏輯，處理完成后會發(fā)出事件，觸發(fā)下一步操作十偶。

可以看出菩鲜，相對傳統(tǒng)輪詢模式，事件驅(qū)動有如下優(yōu)點：

可擴(kuò)展性好惦积，分布式的異步架構(gòu)接校，事件處理器之間高度解耦，可以方便擴(kuò)展事件處理邏輯狮崩。
高性能蛛勉，基于隊列暫存事件，能方便并行異步處理事件睦柴。

Reactor 線程模型

Reactor 是反應(yīng)堆的意思董习，Reactor 模型是指通過一個或多個輸入同時傳遞給服務(wù)處理器的服務(wù)請求的事件驅(qū)動處理模式。

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

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

Reactor训柴，Reactor 在一個單獨的線程中運行哑舒，負(fù)責(zé)監(jiān)聽和分發(fā)事件，分發(fā)給適當(dāng)?shù)奶幚沓绦騺韺?IO 事件做出反應(yīng)幻馁。它就像公司的電話接線員洗鸵，它接聽來自客戶的電話并將線路轉(zhuǎn)移到適當(dāng)?shù)穆?lián)系人。
Handlers仗嗦，處理程序執(zhí)行 I/O 事件要完成的實際事件膘滨，類似于客戶想要與之交談的公司中的實際官員。Reactor 通過調(diào)度適當(dāng)?shù)奶幚沓绦騺眄憫?yīng) I/O 事件稀拐，處理程序執(zhí)行非阻塞操作火邓。

image

Reactor 模型

取決于 Reactor 的數(shù)量和 Hanndler 線程數(shù)量的不同，Reactor 模型有 3 個變種：

單 Reactor 單線程德撬。
單 Reactor 多線程铲咨。
主從 Reactor 多線程。

可以這樣理解蜓洪，Reactor 就是一個執(zhí)行 while (true) { selector.select(); …} 循環(huán)的線程纤勒，會源源不斷的產(chǎn)生新的事件，稱作反應(yīng)堆很貼切隆檀。

篇幅關(guān)系摇天，這里不再具體展開 Reactor 特性北滥、優(yōu)缺點比較，有興趣的讀者可以參考我之前另外一篇文章：《理解高性能網(wǎng)絡(luò)模型》闸翅。

Netty 線程模型

Netty 主要基于主從 Reactors 多線程模型（如下圖）做了一定的修改，其中主從 Reactor 多線程模型有多個 Reactor：

MainReactor 負(fù)責(zé)客戶端的連接請求菊霜，并將請求轉(zhuǎn)交給 SubReactor坚冀。
SubReactor 負(fù)責(zé)相應(yīng)通道的 IO 讀寫請求。
非 IO 請求（具體邏輯處理）的任務(wù)則會直接寫入隊列鉴逞，等待 worker threads 進(jìn)行處理记某。

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

image

主從 Rreactor 多線程模型

特別說明的是：雖然 Netty 的線程模型基于主從 Reactor 多線程，借用了 MainReactor 和 SubReactor 的結(jié)構(gòu)构捡。但是實際實現(xiàn)上 SubReactor 和 Worker 線程在同一個線程池中：

EventLoopGroup bossGroup = newNioEventLoopGroup();

EventLoopGroup workerGroup = newNioEventLoopGroup();

ServerBootstrap server= newServerBootstrap();

server.group(bossGroup, workerGroup)

.channel(NioServerSocketChannel. class)

上面代碼中的 bossGroup 和 workerGroup 是 Bootstrap 構(gòu)造方法中傳入的兩個對象液南，這兩個 group 均是線程池：

bossGroup 線程池則只是在 Bind 某個端口后，獲得其中一個線程作為 MainReactor勾徽，專門處理端口的 Accept 事件滑凉，每個端口對應(yīng)一個 Boss 線程。
workerGroup 線程池會被各個 SubReactor 和 Worker 線程充分利用喘帚。

異步處理

異步的概念和同步相對畅姊。當(dāng)一個異步過程調(diào)用發(fā)出后，調(diào)用者不能立刻得到結(jié)果吹由。實際處理這個調(diào)用的部件在完成后若未，通過狀態(tài)、通知和回調(diào)來通知調(diào)用者倾鲫。

Netty 中的 I/O 操作是異步的粗合，包括 Bind、Write乌昔、Connect 等操作會簡單的返回一個 ChannelFuture隙疚。

調(diào)用者并不能立刻獲得結(jié)果，而是通過 Future-Listener 機(jī)制磕道，用戶可以方便的主動獲取或者通過通知機(jī)制獲得 IO 操作結(jié)果甚淡。

當(dāng) Future 對象剛剛創(chuàng)建時，處于非完成狀態(tài)捅厂，調(diào)用者可以通過返回的 ChannelFuture 來獲取操作執(zhí)行的狀態(tài)贯卦，注冊監(jiān)聽函數(shù)來執(zhí)行完成后的操作。

常見有如下操作：

通過 isDone 方法來判斷當(dāng)前操作是否完成焙贷。
通過 isSuccess 方法來判斷已完成的當(dāng)前操作是否成功撵割。
通過 getCause 方法來獲取已完成的當(dāng)前操作失敗的原因。
通過 isCancelled 方法來判斷已完成的當(dāng)前操作是否被取消辙芍。
通過 addListener 方法來注冊監(jiān)聽器啡彬，當(dāng)操作已完成(isDone 方法返回完成)羹与，將會通知指定的監(jiān)聽器；如果 Future 對象已完成庶灿，則理解通知指定的監(jiān)聽器纵搁。

例如下面的代碼中綁定端口是異步操作，當(dāng)綁定操作處理完往踢，將會調(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 操作后線程會被阻塞住, 直到操作完成峻呕；異步處理的好處是不會造成線程阻塞利职，線程在 I/O 操作期間可以執(zhí)行別的程序，在高并發(fā)情形下會更穩(wěn)定和更高的吞吐量瘦癌。

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

前面介紹完 Netty 相關(guān)一些理論猪贪，下面從功能特性、模塊組件讯私、運作過程來介紹 Netty 的架構(gòu)設(shè)計热押。

功能特性

image

Netty 功能特性如下：

傳輸服務(wù)，支持 BIO 和 NIO斤寇。
容器集成楞黄，支持 OSGI、JBossMC抡驼、Spring鬼廓、Guice 容器。
協(xié)議支持致盟，HTTP碎税、Protobuf、二進(jìn)制馏锡、文本、WebSocket 等一系列常見協(xié)議都支持杯道。還支持通過實行編碼解碼邏輯來實現(xiàn)自定義協(xié)議。
Core 核心党巾，可擴(kuò)展事件模型萎庭、通用通信 API、支持零拷貝的 ByteBuf 緩沖對象齿拂。

模塊組件

Bootstrap驳规、ServerBootstrap

Bootstrap 意思是引導(dǎo)，一個 Netty 應(yīng)用通常由一個 Bootstrap 開始署海，主要作用是配置整個 Netty 程序吗购，串聯(lián)各個組件医男，Netty 中 Bootstrap 類是客戶端程序的啟動引導(dǎo)類，ServerBootstrap 是服務(wù)端啟動引導(dǎo)類捻勉。

Future镀梭、ChannelFuture

正如前面介紹，在 Netty 中所有的 IO 操作都是異步的踱启，不能立刻得知消息是否被正確處理报账。

但是可以過一會等它執(zhí)行完成或者直接注冊一個監(jiān)聽，具體的實現(xiàn)就是通過 Future 和 ChannelFutures禽捆，他們可以注冊一個監(jiān)聽，當(dāng)操作執(zhí)行成功或失敗時監(jiān)聽會自動觸發(fā)注冊的監(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é)束時所請求的 I/O 操作已完成孽拷。調(diào)用立即返回一個 ChannelFuture 實例，通過注冊監(jiān)聽器到 ChannelFuture 上半抱，可以 I/O 操作成功脓恕、失敗或取消時回調(diào)通知調(diào)用方。
支持關(guān)聯(lián) I/O 操作與對應(yīng)的處理程序炼幔。

不同協(xié)議史简、不同的阻塞類型的連接都有不同的 Channel 類型與之對應(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 對象實現(xiàn) I/O 多路復(fù)用秦躯，通過 Selector 一個線程可以監(jiān)聽多個連接的 Channel 事件裆装。

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

NioEventLoop

NioEventLoop 中維護(hù)了一個線程和任務(wù)隊列呈础，支持異步提交執(zhí)行任務(wù)而钞，線程啟動時會調(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í)行時間比由變量 ioRatio 控制，默認(rèn)為 50么鹤，則表示允許非 IO 任務(wù)執(zhí)行的時間與 IO 任務(wù)的執(zhí)行時間相等。

NioEventLoopGroup

NioEventLoopGroup，主要管理 eventLoop 的生命周期窍荧，可以理解為一個線程池蕊退，內(nèi)部維護(hù)了一組線程瓤荔，每個線程(NioEventLoop)負(fù)責(zé)處理多個 Channel 上的事件输硝，而一個 Channel 只對應(yīng)于一個線程点把。

ChannelHandler

ChannelHandler 是一個接口作烟，處理 I/O 事件或攔截 I/O 操作衣厘，并將其轉(zhuǎn)發(fā)到其 ChannelPipeline(業(yè)務(wù)處理鏈)中的下一個處理程序影暴。

ChannelHandler 本身并沒有提供很多方法撬呢，因為這個接口有許多的方法需要實現(xiàn)，方便使用期間芯勘，可以繼承它的子類：

ChannelInboundHandler 用于處理入站 I/O 事件荷愕。
ChannelOutboundHandler 用于處理出站 I/O 操作。

或者使用以下適配器類：

ChannelInboundHandlerAdapter 用于處理入站 I/O 事件够委。
ChannelOutboundHandlerAdapter 用于處理出站 I/O 操作掉冶。
ChannelDuplexHandler 用于處理入站和出站事件。

ChannelHandlerContext

保存 Channel 相關(guān)的所有上下文信息恢共，同時關(guān)聯(lián)一個 ChannelHandler 對象战秋。

ChannelPipline

保存 ChannelHandler 的 List，用于處理或攔截 Channel 的入站事件和出站操作讨韭。

ChannelPipeline 實現(xiàn)了一種高級形式的攔截過濾器模式脂信，使用戶可以完全控制事件的處理方式，以及 Channel 中各個的 ChannelHandler 如何相互交互透硝。

下圖引用 Netty 的 Javadoc 4.1 中 ChannelPipeline 的說明狰闪，描述了 ChannelPipeline 中 ChannelHandler 通常如何處理 I/O 事件。

I/O 事件由 ChannelInboundHandler 或 ChannelOutboundHandler 處理濒生，并通過調(diào)用 ChannelHandlerContext 中定義的事件傳播方法埋泵。

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

image

入站事件由自下而上方向的入站處理程序處理霉撵，如圖左側(cè)所示崭参。入站 Handler 處理程序通常處理由圖底部的 I/O 線程生成的入站數(shù)據(jù)海洼。

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

出站事件由上下方向處理事秀，如圖右側(cè)所示供炼。出站 Handler 處理程序通常會生成或轉(zhuǎn)換出站傳輸轧苫，例如 write 請求岔乔。

I/O 線程通常執(zhí)行實際的輸出操作茁影，例如 SocketChannel.write（ByteBuffer）浩螺。

在 Netty 中每個 Channel 都有且僅有一個 ChannelPipeline 與之對應(yīng)相嵌，它們的組成關(guān)系如下：

image

一個 Channel 包含了一個 ChannelPipeline，而 ChannelPipeline 中又維護(hù)了一個由 ChannelHandlerContext 組成的雙向鏈表石抡，并且每個 ChannelHandlerContext 中又關(guān)聯(lián)著一個 ChannelHandler鞍帝。

入站事件和出站事件在一個雙向鏈表中续徽，入站事件會從鏈表 head 往后傳遞到最后一個入站的 handler，出站事件會從鏈表 tail 往前傳遞到最前一個出站的 handler，兩種類型的 handler 互不干擾技掏。

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

初始化并啟動 Netty 服務(wù)端過程如下：

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<NioSocketChannel>() {

@ Override

protectedvoidinitChannel(NioSocketChannel ch) {

// 配置入站鸠真、出站事件channel

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

}

});

// 綁定端口

intport = 8080;

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

if(future.isSuccess()) {

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

} else{

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

}

});

}

基本過程如下：

初始化創(chuàng)建 2 個 NioEventLoopGroup，其中 boosGroup 用于 Accetpt 連接建立事件并分發(fā)請求茴她，workerGroup 用于處理 I/O 讀寫事件和業(yè)務(wù)邏輯。
基于 ServerBootstrap(服務(wù)端啟動引導(dǎo)類)霹粥，配置 EventLoopGroup张抄、Channel 類型，連接參數(shù)舶斧、配置入站欣鳖、出站事件 handler。
綁定端口茴厉，開始工作泽台。

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

image

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

Server 端包含 1 個 Boss NioEventLoopGroup 和 1 個 Worker NioEventLoopGroup矾缓。

NioEventLoopGroup 相當(dāng)于 1 個事件循環(huán)組怀酷，這個組里包含多個事件循環(huán) NioEventLoop，每個 NioEventLoop 包含 1 個 Selector 和 1 個事件循環(huán)線程嗜闻。

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

輪詢 Accept 事件蜕依。
處理 Accept I/O 事件，與 Client 建立連接琉雳，生成 NioSocketChannel样眠，并將 NioSocketChannel 注冊到某個 Worker NioEventLoop 的 Selector 上。
處理任務(wù)隊列中的任務(wù)翠肘，runAllTasks檐束。任務(wù)隊列中的任務(wù)包括用戶調(diào)用 eventloop.execute 或 schedule 執(zhí)行的任務(wù)，或者其他線程提交到該 eventloop 的任務(wù)束倍。

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

輪詢 Read被丧、Write 事件。
處理 I/O 事件绪妹，即 Read甥桂、Write 事件，在 NioSocketChannel 可讀邮旷、可寫事件發(fā)生時進(jìn)行處理黄选。
處理任務(wù)隊列中的任務(wù)，runAllTasks婶肩。

其中任務(wù)隊列中的 Task 有 3 種典型使用場景糕簿。

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

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

@Override

publicvoidrun(){

//...

}

});

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

例如在推送系統(tǒng)的業(yè)務(wù)線程里面，根據(jù)用戶的標(biāo)識狡孔，找到對應(yīng)的 Channel 引用懂诗，然后調(diào)用 Write 類方法向該用戶推送消息，就會進(jìn)入到這種場景苗膝。最終的 Write 會提交到任務(wù)隊列中后被異步消費殃恒。

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

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

@Override

publicvoidrun(){

}

}, 60, TimeUnit.SECONDS);

總結(jié)

現(xiàn)在穩(wěn)定推薦使用的主流版本還是 Netty4，Netty5 中使用了 ForkJoinPool辱揭，增加了代碼的復(fù)雜度离唐，但是對性能的改善卻不明顯，所以這個版本不推薦使用问窃，官網(wǎng)也沒有提供下載鏈接亥鬓。

Netty 入門門檻相對較高，是因為這方面的資料較少域庇，并不是因為它有多難嵌戈，大家其實都可以像搞透 Spring 一樣搞透 Netty覆积。

在學(xué)習(xí)之前，建議先理解透整個框架原理結(jié)構(gòu)熟呛，運行過程宽档，可以少走很多彎路。

參考資料：

Netty入門與實戰(zhàn)：仿寫微信 IM 即時通訊系統(tǒng)
Netty官網(wǎng)
Netty 4.x學(xué)習(xí)筆記 - 線程模型
Netty入門與實戰(zhàn)
理解高性能網(wǎng)絡(luò)模型
Netty基本原理介紹
software-architecture-patterns.pdf
Netty高性能之道 —— 李林鋒
《Netty In Action》
《Netty權(quán)威指南》

作者：陳彩華

編輯：陶家龍庵朝、孫淑娟

出處：轉(zhuǎn)載自Hollis（ID：hollischuang）微信公眾號

陳彩華(caison)吗冤，從事服務(wù)端開發(fā)，善于系統(tǒng)設(shè)計九府、優(yōu)化重構(gòu)椎瘟、線上問題排查工作，主要開發(fā)語言是 Java侄旬，微信號：hua1881375肺蔚。