本文基于Netty4.1展開介紹相關(guān)理論模型，使用場(chǎng)景，基本組件、整體架構(gòu)，知其然且知其所以然，希望給讀者提供學(xué)習(xí)實(shí)踐參考。
1 Netty簡(jiǎn)介
Netty是 一個(gè)異步事件驅(qū)動(dòng)的網(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多線程編程，因?yàn)镹IO編程涉及到Reactor模式，你必須對(duì)多線程和網(wǎng)路編程非常熟悉，才能編寫出高質(zhì)量的NIO程序
- 可靠性開發(fā)工作量和難度都非常大。例如客戶端面臨斷連重連、網(wǎng)絡(luò)閃斷、半包讀寫、失敗緩存、網(wǎng)絡(luò)擁塞和異常碼流的處理等等，NIO編程的特點(diǎn)是功能開發(fā)相對(duì)容易，但是可靠性工作量和難度都非常大
- JDK NIO的BUG，例如臭名昭著的epoll bug，它會(huì)導(dǎo)致Selector空輪詢，最終導(dǎo)致CPU 100%。官方聲稱在JDK1.6版本的update18修復(fù)了該問題，但是直到JDK1.7版本該問題仍舊存在，只不過該bug發(fā)生概率降低了一些而已，它并沒有被根本解決
Netty的特點(diǎn)
Netty的對(duì)JDK自帶的NIO的API進(jìn)行封裝，解決上述問題，主要特點(diǎn)有：
- 設(shè)計(jì)優(yōu)雅
適用于各種傳輸類型的統(tǒng)一API - 阻塞和非阻塞Socket
基于靈活且可擴(kuò)展的事件模型，可以清晰地分離關(guān)注點(diǎn)
高度可定制的線程模型 - 單線程，一個(gè)或多個(gè)線程池
真正的無連接數(shù)據(jù)報(bào)套接字支持（自3.1起） - 使用方便
詳細(xì)記錄的Javadoc，用戶指南和示例
沒有其他依賴項(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常見使用常見
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ǎng)絡(luò)游戲，Java語言得到了越來越廣泛的應(yīng)用。Netty作為高性能的基礎(chǔ)通信組件，它本身提供了TCP/UDP和HTTP協(xié)議棧。
非常方便定制和開發(fā)私有協(xié)議棧，賬號(hào)登錄服務(wù)器，地圖服務(wù)器之間可以方便的通過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
2 Netty高性能設(shè)計(jì)
Netty作為異步事件驅(qū)動(dòng)的網(wǎng)絡(luò)，高性能之處主要來自于其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)可以用下圖表示：
特點(diǎn)
- 每個(gè)請(qǐng)求都需要獨(dú)立的線程完成數(shù)據(jù)read，業(yè)務(wù)處理，數(shù)據(jù)write的完整操作
問題
- 當(dāng)并發(fā)數(shù)較大時(shí)，需要?jiǎng)?chuàng)建大量線程來處理連接，系統(tǒng)資源占用較大
- 連接建立后，如果當(dāng)前線程暫時(shí)沒有數(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è)讀操寫操作的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ì)象表示：
Netty的IO線程N(yùn)ioEventLoop由于聚合了多路復(fù)用器Selector，可以同時(shí)并發(fā)處理成百上千個(gè)客戶端連接。當(dāng)線程從某客戶端Socket通道進(jìn)行讀寫數(shù)據(jù)時(shí)，若沒有數(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問相關(guān)事件發(fā)生源有沒有發(fā)生事件，有發(fā)生事件就調(diào)用事件處理邏輯。 - 事件驅(qū)動(dòng)方式
發(fā)生事件，主線程把事件放入事件隊(duì)列，在另外線程不斷循環(huán)消費(fèi)事件列表中的事件，調(diào)用事件對(duì)應(yīng)的處理邏輯處理事件。事件驅(qū)動(dòng)方式也被稱為消息通知方式，其實(shí)是發(fā)布-訂閱模式的思路。
以GUI的邏輯處理為例，說明兩種邏輯的不同：
- 輪詢方式
線程不斷輪詢是否發(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)模型解釋圖
主要包括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模型，是指通過一個(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ù)奶幚沓绦騺韺?duì)IO事件做出反應(yīng)。 它就像公司的電話接線員，它接聽來自客戶的電話并將線路轉(zhuǎn)移到適當(dāng)?shù)穆?lián)系人Handlers
處理程序執(zhí)行I/O事件要完成的實(shí)際事件，類似于客戶想要與之交談的公司中的實(shí)際官員。Reactor通過調(diào)度適當(dāng)?shù)奶幚沓绦騺眄憫?yīng)I/O事件，處理程序執(zhí)行非阻塞操作
取決于Reactor的數(shù)量和Handler線程數(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和SubReactor：
- 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多線程模型的圖
特別說明的是：
雖然Netty的線程模型基于主從Reactor多線程，借用了MainReactor和SubReactor的結(jié)構(gòu)，但是實(shí)際實(shí)現(xiàn)上，SubReactor和Worker線程在同一個(gè)線程池中：
EventLoopGroup bossGroup = new NioEventLoopGroup();
EventLoopGroup workerGroup = new NioEventLoopGroup();
ServerBootstrap server = new ServerBootstrap();
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è)異步過程調(diào)用發(fā)出后，調(diào)用者不能立刻得到結(jié)果。實(shí)際處理這個(gè)調(diào)用的部件在完成后，通過狀態(tài)、通知和回調(diào)來通知調(diào)用者。
Netty中的I/O操作是異步的，包括bind、write、connect等操作會(huì)簡(jiǎn)單的返回一個(gè)ChannelFuture，調(diào)用者并不能立刻獲得結(jié)果，通過Future-Listener機(jī)制，用戶可以方便的主動(dòng)獲取或者通過通知機(jī)制獲得IO操作結(jié)果。
當(dāng)future對(duì)象剛剛創(chuàng)建時(shí)，處于非完成狀態(tài)，調(diào)用者可以通過返回的ChannelFuture來獲取操作執(zhí)行的狀態(tài)，注冊(cè)監(jiān)聽函數(shù)來執(zhí)行完成后的操作，常見有如下：
- 通過isDone方法來判斷當(dāng)前操作是否完成
- 通過isSuccess方法來判斷已完成的當(dāng)前操作是否成功
- 通過getCause方法來獲取已完成的當(dāng)前操作失敗的原因
- 通過isCancelled方法來判斷已完成的當(dāng)前操作是否被取消
- 通過addListener方法來注冊(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(new Date() + ": 端口[" + port + "]綁定成功!");
} else {
System.err.println("端口[" + port + "]綁定失敗!");
}
});
相比傳統(tǒng)阻塞I/O，執(zhí)行I/O操作后線程會(huì)被阻塞住, 直到操作完成；異步處理的好處是不會(huì)造成線程阻塞，線程在I/O操作期間可以執(zhí)行別的程序，在高并發(fā)情形下會(huì)更穩(wěn)定和更高的吞吐量。
3 Netty架構(gòu)設(shè)計(jì)
前面介紹完Netty相關(guān)一些理論介紹，下面從功能特性、模塊組件、運(yùn)作過程來介紹Netty的架構(gòu)設(shè)計(jì)
功能特性
- 傳輸服務(wù)
支持BIO和NIO - 容器集成
支持OSGI、JBossMC、Spring、Guice容器 - 協(xié)議支持
HTTP、Protobuf、二進(jìn)制、文本、WebSocket等一系列常見協(xié)議都支持。
還支持通過實(shí)行編碼解碼邏輯來實(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操作都是異步的，不能立刻得知消息是否被正確處理，但是可以過一會(huì)等它執(zhí)行完成或者直接注冊(cè)一個(gè)監(jiān)聽，具體的實(shí)現(xiàn)就是通過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í)例，通過注冊(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ù)用，通過 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本身并沒有提供很多方法，因?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í)形式的攔截過濾器模式，使用戶可以完全控制事件的處理方式，以及Channel中各個(gè)的ChannelHandler如何相互交互。
下圖引用Netty的Javadoc4.1中ChannelPipline的說明，描述了ChannelPipeline中ChannelHandler通常如何處理I/O事件。 I/O事件由ChannelInboundHandler或ChannelOutboundHandler處理，并通過調(diào)用ChannelHandlerContext中定義的事件傳播方法（例如ChannelHandlerContext.fireChannelRead（Object）和ChannelOutboundInvoker.write（Object））轉(zhuǎn)發(fā)到其最近的處理程序。
I/O Request
via Channel or
ChannelHandlerContext
|
+---------------------------------------------------+---------------+
| ChannelPipeline | |
| \|/ |
| +---------------------+ +-----------+----------+ |
| | Inbound Handler N | | Outbound Handler 1 | |
| +----------+----------+ +-----------+----------+ |
| /|\ | |
| | \|/ |
| +----------+----------+ +-----------+----------+ |
| | Inbound Handler N-1 | | Outbound Handler 2 | |
| +----------+----------+ +-----------+----------+ |
| /|\ . |
| . . |
| ChannelHandlerContext.fireIN_EVT() ChannelHandlerContext.OUT_EVT()|
| [ method call] [method call] |
| . . |
| . \|/ |
| +----------+----------+ +-----------+----------+ |
| | Inbound Handler 2 | | Outbound Handler M-1 | |
| +----------+----------+ +-----------+----------+ |
| /|\ | |
| | \|/ |
| +----------+----------+ +-----------+----------+ |
| | Inbound Handler 1 | | Outbound Handler M | |
| +----------+----------+ +-----------+----------+ |
| /|\ | |
+---------------+-----------------------------------+---------------+
| \|/
+---------------+-----------------------------------+---------------+
| | | |
| [ Socket.read() ] [ Socket.write() ] |
| |
| Netty Internal I/O Threads (Transport Implementation) |
+-------------------------------------------------------------------+
入站事件由自下而上方向的入站處理程序處理，如圖左側(cè)所示。 入站Handler處理程序通常處理由圖底部的I/O線程生成的入站數(shù)據(jù)。 通常通過實(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互不干擾。
工作原理架構(gòu)
初始化并啟動(dòng)Netty服務(wù)端過程如下：
public static void main(String[] args) {
// 創(chuàng)建mainReactor
NioEventLoopGroup boosGroup = new NioEventLoopGroup();
// 創(chuàng)建工作線程組
NioEventLoopGroup workerGroup = new NioEventLoopGroup();
final ServerBootstrap serverBootstrap = new ServerBootstrap();
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(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) {
// 配置入站、出站事件channel
ch.pipeline().addLast(...);
ch.pipeline().addLast(...);
}
});
// 綁定端口
int port = 8080;
serverBootstrap.bind(port).addListener(future -> {
if (future.isSuccess()) {
System.out.println(new Date() + ": 端口[" + port + "]綁定成功!");
} else {
System.err.println("端口[" + port + "]綁定失敗!");
}
});
}
- 基本過程如下：
- 1 初始化創(chuàng)建2個(gè)NioEventLoopGroup，其中boosGroup用于Accetpt連接建立事件并分發(fā)請(qǐng)求， workerGroup用于處理I/O讀寫事件和業(yè)務(wù)邏輯
- 2 基于ServerBootstrap(服務(wù)端啟動(dòng)引導(dǎo)類)，配置EventLoopGroup、Channel類型，連接參數(shù)、配置入站、出站事件handler
- 3 綁定端口，開始工作
結(jié)合上面的介紹的Netty Reactor模型，介紹服務(wù)端Netty的工作架構(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步：
- 1 輪詢accept事件
- 2 處理accept I/O事件，與Client建立連接，生成NioSocketChannel，并將NioSocketChannel注冊(cè)到某個(gè)Worker NioEventLoop的Selector上
- 3 處理任務(wù)隊(duì)列中的任務(wù)，runAllTasks。任務(wù)隊(duì)列中的任務(wù)包括用戶調(diào)用eventloop.execute或schedule執(zhí)行的任務(wù)，或者其它線程提交到該eventloop的任務(wù)
每個(gè)Worker NioEventLoop循環(huán)執(zhí)行的任務(wù)包含3步：
- 1 輪詢r(jià)ead、write事件
- 2 處理I/O事件，即read、write事件，在NioSocketChannel可讀、可寫事件發(fā)生時(shí)進(jìn)行處理
- 3 處理任務(wù)隊(duì)列中的任務(wù)，runAllTasks
其中任務(wù)隊(duì)列中的task有3種典型使用場(chǎng)景
- 1 用戶程序自定義的普通任務(wù)
ctx.channel().eventLoop().execute(new Runnable() {
@Override
public void run() {
//...
}
});
2 非當(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)。3 用戶自定義定時(shí)任務(wù)
ctx.channel().eventLoop().schedule(new Runnable() {
@Override
public void run() {
}
}, 60, TimeUnit.SECONDS);
4 總結(jié)
現(xiàn)在穩(wěn)定推薦使用的主流版本還是Netty4，Netty5 中使用了 ForkJoinPool，增加了代碼的復(fù)雜度，但是對(duì)性能的改善卻不明顯，所以這個(gè)版本不推薦使用，官網(wǎng)也沒有提供下載鏈接。
Netty 入門門檻相對(duì)較高，其實(shí)是因?yàn)檫@方面的資料較少，并不是因?yàn)樗卸嚯y，大家其實(shí)都可以像搞透 Spring 一樣搞透 Netty。在學(xué)習(xí)之前，建議先理解透整個(gè)框架原理結(jié)構(gòu)，運(yùn)行過程，可以少走很多彎路。
參考
Netty入門與實(shí)戰(zhàn)：仿寫微信 IM 即時(shí)通訊系統(tǒng)
software-architecture-patterns.pdf
《Netty In Action》
《Netty權(quán)威指南》
