本文基于Netty4.1展開介紹相關(guān)理論模型春寿，使用場景笔喉，基本組件、整體架構(gòu)鬼雀，知其然且知其所以然顷窒，希望給讀者提供學習實踐參考。
1 Netty簡介
Netty是 一個異步事件驅(qū)動的網(wǎng)絡(luò)應用程序框架源哩，用于快速開發(fā)可維護的高性能協(xié)議服務(wù)器和客戶端鞋吉。
JDK原生NIO程序的問題
JDK原生也有一套網(wǎng)絡(luò)應用程序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酬土，它會導致Selector空輪詢，最終導致CPU 100%格带。官方聲稱在JDK1.6版本的update18修復了該問題撤缴，但是直到JDK1.7版本該問題仍舊存在，只不過該bug發(fā)生概率降低了一些而已叽唱，它并沒有被根本解決
Netty的特點
Netty的對JDK自帶的NIO的API進行封裝屈呕，解決上述問題，主要特點有：
- 設(shè)計優(yōu)雅
適用于各種傳輸類型的統(tǒng)一API - 阻塞和非阻塞Socket
基于靈活且可擴展的事件模型棺亭，可以清晰地分離關(guān)注點
高度可定制的線程模型 - 單線程虎眨，一個或多個線程池
真正的無連接數(shù)據(jù)報套接字支持（自3.1起） - 使用方便
詳細記錄的Javadoc，用戶指南和示例
沒有其他依賴項，JDK 5（Netty 3.x）或6（Netty 4.x）就足夠了 - 高性能
吞吐量更高嗽桩，延遲更低
減少資源消耗
最小化不必要的內(nèi)存復制 - 安全
完整的SSL / TLS和StartTLS支持 - 社區(qū)活躍岳守，不斷更新
社區(qū)活躍，版本迭代周期短碌冶，發(fā)現(xiàn)的BUG可以被及時修復湿痢，同時，更多的新功能會被加入
Netty常見使用常見
Netty常見的使用場景如下：
- 互聯(lián)網(wǎng)行業(yè)
在分布式系統(tǒng)中扑庞，各個節(jié)點之間需要遠程服務(wù)調(diào)用譬重，高性能的RPC框架必不可少，Netty作為異步高新能的通信框架,往往作為基礎(chǔ)通信組件被這些RPC框架使用罐氨。
典型的應用有：阿里分布式服務(wù)框架Dubbo的RPC框架使用Dubbo協(xié)議進行節(jié)點間通信臀规，Dubbo協(xié)議默認使用Netty作為基礎(chǔ)通信組件，用于實現(xiàn)各進程節(jié)點之間的內(nèi)部通信岂昭。 - 游戲行業(yè)
無論是手游服務(wù)端還是大型的網(wǎng)絡(luò)游戲以现，Java語言得到了越來越廣泛的應用。Netty作為高性能的基礎(chǔ)通信組件约啊，它本身提供了TCP/UDP和HTTP協(xié)議棧邑遏。
非常方便定制和開發(fā)私有協(xié)議棧，賬號登錄服務(wù)器恰矩，地圖服務(wù)器之間可以方便的通過Netty進行高性能的通信 - 大數(shù)據(jù)領(lǐng)域
經(jīng)典的Hadoop的高性能通信和序列化組件Avro的RPC框架记盒，默認采用Netty進行跨界點通信，它的Netty Service基于Netty框架二次封裝實現(xiàn)
有興趣的讀者可以了解一下目前有哪些開源項目使用了 Netty：Related projects
2 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)可以用下圖表示：
特點
- 每個請求都需要獨立的線程完成數(shù)據(jù)read技竟，業(yè)務(wù)處理冰肴，數(shù)據(jù)write的完整操作
問題
- 當并發(fā)數(shù)較大時，需要創(chuàng)建大量線程來處理連接榔组，系統(tǒng)資源占用較大
- 連接建立后熙尉，如果當前線程暫時沒有數(shù)據(jù)可讀，則線程就阻塞在read操作上搓扯，造成線程資源浪費
I/O復用模型
在I/O復用模型中检痰，會用到select，這個函數(shù)也會使進程阻塞锨推，與阻塞I/O所不同的铅歼，這個函數(shù)可以同時阻塞多個I/O操作公壤，可同時對多個讀操寫操作的I/O函數(shù)進行檢測，直到有數(shù)據(jù)可讀或可寫時谭贪，才真正調(diào)用I/O操作函數(shù)
Netty的非阻塞I/O的實現(xiàn)關(guān)鍵是基于I/O復用模型境钟，這里用Selector對象表示：
Netty的IO線程NioEventLoop由于聚合了多路復用器Selector，可以同時并發(fā)處理成百上千個客戶端連接俭识。當線程從某客戶端Socket通道進行讀寫數(shù)據(jù)時慨削，若沒有數(shù)據(jù)可用時，該線程可以進行其他任務(wù)套媚。線程通常將非阻塞 IO 的空閑時間用于在其他通道上執(zhí)行 IO 操作缚态，所以單獨的線程可以管理多個輸入和輸出通道。
由于讀寫操作都是非阻塞的堤瘤，這就可以充分提升IO線程的運行效率玫芦，避免由于頻繁I/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ù)報如何讀绕沓住？讀取之后的編解碼在哪個線程進行天揖，編解碼后的消息如何派發(fā)夺欲，線程模型的不同，對性能的影響也非常大今膊。
事件驅(qū)動模型
通常些阅，我們設(shè)計一個事件處理模型的程序有兩種思路
- 輪詢方式
線程不斷輪詢訪問相關(guān)事件發(fā)生源有沒有發(fā)生事件，有發(fā)生事件就調(diào)用事件處理邏輯斑唬。 - 事件驅(qū)動方式
發(fā)生事件扑眉，主線程把事件放入事件隊列，在另外線程不斷循環(huán)消費事件列表中的事件赖钞，調(diào)用事件對應的處理邏輯處理事件。事件驅(qū)動方式也被稱為消息通知方式聘裁，其實是發(fā)布-訂閱模式的思路雪营。
以GUI的邏輯處理為例，說明兩種邏輯的不同：
- 輪詢方式
線程不斷輪詢是否發(fā)生按鈕點擊事件衡便，如果發(fā)生献起，調(diào)用處理邏輯 - 事件驅(qū)動方式
發(fā)生點擊事件把事件放入事件隊列洋访，在另外線程消費的事件列表中的事件，根據(jù)事件類型調(diào)用相關(guān)事件處理邏輯
這里借用O'Reilly 大神關(guān)于事件驅(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)點：
- 可擴展性好，分布式的異步架構(gòu)厌殉，事件處理器之間高度解耦食绿，可以方便擴展事件處理邏輯
- 高性能，基于隊列暫存事件公罕，能方便并行異步處理事件
Reactor線程模型
Reactor是反應堆的意思器紧，Reactor模型，是指通過一個或多個輸入同時傳遞給服務(wù)處理器的服務(wù)請求的事件驅(qū)動處理模式楼眷。 服務(wù)端程序處理傳入多路請求铲汪，并將它們同步分派給請求對應的處理線程，Reactor模式也叫Dispatcher模式罐柳，即I/O多路復用統(tǒng)一監(jiān)聽事件掌腰，收到事件后分發(fā)(Dispatch給某進程)，是編寫高性能網(wǎng)絡(luò)服務(wù)器的必備技術(shù)之一硝清。
Reactor模型中有2個關(guān)鍵組成：
Reactor
Reactor在一個單獨的線程中運行辅斟，負責監(jiān)聽和分發(fā)事件，分發(fā)給適當?shù)奶幚沓绦騺韺O事件做出反應芦拿。 它就像公司的電話接線員士飒，它接聽來自客戶的電話并將線路轉(zhuǎn)移到適當?shù)穆?lián)系人Handlers
處理程序執(zhí)行I/O事件要完成的實際事件，類似于客戶想要與之交談的公司中的實際官員蔗崎。Reactor通過調(diào)度適當?shù)奶幚沓绦騺眄憫狪/O事件酵幕，處理程序執(zhí)行非阻塞操作
取決于Reactor的數(shù)量和Handler線程數(shù)量的不同，Reactor模型有3個變種
- 單Reactor單線程
- 單Reactor多線程
- 主從Reactor多線程
可以這樣理解缓苛，Reactor就是一個執(zhí)行while (true) { selector.select(); ...}循環(huán)的線程芳撒，會源源不斷的產(chǎn)生新的事件，稱作反應堆很貼切未桥。
篇幅關(guān)系笔刹，這里不再具體展開Reactor特性、優(yōu)缺點比較冬耿，有興趣的讀者可以參考我之前另外一篇文章：《理解高性能網(wǎng)絡(luò)模型》
Netty線程模型
Netty主要基于主從Reactors多線程模型（如下圖）做了一定的修改舌菜，其中主從Reactor多線程模型有多個Reactor：MainReactor和SubReactor：
- MainReactor負責客戶端的連接請求，并將請求轉(zhuǎn)交給SubReactor
- SubReactor負責相應通道的IO讀寫請求
- 非IO請求（具體邏輯處理）的任務(wù)則會直接寫入隊列亦镶，等待worker threads進行處理
這里引用Doug Lee大神的Reactor介紹：Scalable IO in Java里面關(guān)于主從Reactor多線程模型的圖
特別說明的是：
雖然Netty的線程模型基于主從Reactor多線程，借用了MainReactor和SubReactor的結(jié)構(gòu)爱咬，但是實際實現(xiàn)上，SubReactor和Worker線程在同一個線程池中：
EventLoopGroup bossGroup = new NioEventLoopGroup();
EventLoopGroup workerGroup = new NioEventLoopGroup();
ServerBootstrap server = new ServerBootstrap();
server.group(bossGroup, workerGroup)
.channel(NioServerSocketChannel.class)
上面代碼中的bossGroup 和workerGroup是Bootstrap構(gòu)造方法中傳入的兩個對象精拟，這兩個group均是線程池
- bossGroup線程池則只是在bind某個端口后，獲得其中一個線程作為MainReactor串前，專門處理端口的accept事件，每個端口對應一個boss線程
- workerGroup線程池會被各個SubReactor和worker線程充分利用
異步處理
異步的概念和同步相對荡碾。當一個異步過程調(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機制怪与，用戶可以方便的主動獲取或者通過通知機制獲得IO操作結(jié)果。
當future對象剛剛創(chuàng)建時性誉，處于非完成狀態(tài)，調(diào)用者可以通過返回的ChannelFuture來獲取操作執(zhí)行的狀態(tài)错览，注冊監(jiān)聽函數(shù)來執(zhí)行完成后的操作倾哺，常見有如下：
- 通過isDone方法來判斷當前操作是否完成
- 通過isSuccess方法來判斷已完成的當前操作是否成功
- 通過getCause方法來獲取已完成的當前操作失敗的原因
- 通過isCancelled方法來判斷已完成的當前操作是否被取消
- 通過addListener方法來注冊監(jiān)聽器刽脖，當操作已完成(isDone方法返回完成)曲管，將會通知指定的監(jiān)聽器院水；如果future對象已完成，則理解通知指定的監(jiān)聽器
例如下面的代碼中綁定端口是異步操作撬腾，當綁定操作處理完民傻，將會調(diào)用相應的監(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操作后線程會被阻塞住, 直到操作完成和簸；異步處理的好處是不會造成線程阻塞锁保，線程在I/O操作期間可以執(zhí)行別的程序，在高并發(fā)情形下會更穩(wěn)定和更高的吞吐量吴菠。
3 Netty架構(gòu)設(shè)計
前面介紹完Netty相關(guān)一些理論介紹做葵，下面從功能特性酿矢、模塊組件、運作過程來介紹Netty的架構(gòu)設(shè)計
功能特性
- 傳輸服務(wù)
支持BIO和NIO - 容器集成
支持OSGI蜜暑、JBossMC肛捍、Spring拙毫、Guice容器 - 協(xié)議支持
HTTP棺禾、Protobuf帘睦、二進制竣付、文本、WebSocket等一系列常見協(xié)議都支持肆良。
還支持通過實行編碼解碼邏輯來實現(xiàn)自定義協(xié)議 - Core核心
可擴展事件模型惹恃、通用通信API棺牧、支持零拷貝的ByteBuf緩沖對象
模塊組件
Bootstrap颊乘、ServerBootstrap
Bootstrap意思是引導乏悄，一個Netty應用通常由一個Bootstrap開始，主要作用是配置整個Netty程序开呐，串聯(lián)各個組件筐付，Netty中Bootstrap類是客戶端程序的啟動引導類瓦戚，ServerBootstrap是服務(wù)端啟動引導類。
Future、ChannelFuture
正如前面介紹哨坪，在Netty中所有的IO操作都是異步的当编，不能立刻得知消息是否被正確處理徒溪，但是可以過一會等它執(zhí)行完成或者直接注冊一個監(jiān)聽臊泌，具體的實現(xiàn)就是通過Future和ChannelFutures渠概，他們可以注冊一個監(jiān)聽播揪，當操作執(zhí)行成功或失敗時監(jiān)聽會自動觸發(fā)注冊的監(jiān)聽事件。
Channel
Netty網(wǎng)絡(luò)通信的組件箱沦，能夠用于執(zhí)行網(wǎng)絡(luò)I/O操作谓形。
Channel為用戶提供：
- 當前網(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操作與對應的處理程序
不同協(xié)議妓雾、不同的阻塞類型的連接都有不同的 Channel 類型與之對應械姻，下面是一些常用的 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多路復用臭脓，通過 Selector, 一個線程可以監(jiān)聽多個連接的Channel事件, 當向一個Selector中注冊Channel 后来累，Selector 內(nèi)部的機制就可以自動不斷地查詢(select) 這些注冊的Channel是否有已就緒的I/O事件(例如可讀, 可寫, 網(wǎng)絡(luò)連接完成等)嘹锁，這樣程序就可以很簡單地使用一個線程高效地管理多個 Channel 兼耀。
NioEventLoop
NioEventLoop中維護了一個線程和任務(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控制楚午，默認為50矾柜，則表示允許非IO任務(wù)執(zhí)行的時間與IO任務(wù)的執(zhí)行時間相等怪蔑。
NioEventLoopGroup
NioEventLoopGroup缆瓣，主要管理eventLoop的生命周期弓坞，可以理解為一個線程池渡冻，內(nèi)部維護了一組線程菩帝，每個線程(NioEventLoop)負責處理多個Channel上的事件呼奢，而一個Channel只對應于一個線程握础。
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的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ù)什黑。 通常通過實際輸入操作（例如SocketChannel.read（ByteBuffer））從遠程讀取入站數(shù)據(jù)愕把。
出站事件由上下方向處理恨豁，如圖右側(cè)所示橘蜜。 出站Handler處理程序通常會生成或轉(zhuǎn)換出站傳輸计福，例如write請求象颖。 I/O線程通常執(zhí)行實際的輸出操作说订，例如SocketChannel.write（ByteBuffer）潮瓶。
在 Netty 中每個 Channel 都有且僅有一個 ChannelPipeline 與之對應, 它們的組成關(guān)系如下:
一個 Channel 包含了一個 ChannelPipeline, 而 ChannelPipeline 中又維護了一個由 ChannelHandlerContext 組成的雙向鏈表, 并且每個 ChannelHandlerContext 中又關(guān)聯(lián)著一個 ChannelHandler埃叭。入站事件和出站事件在一個雙向鏈表中赤屋，入站事件會從鏈表head往后傳遞到最后一個入站的handler类早，出站事件會從鏈表tail往前傳遞到最前一個出站的handler涩僻，兩種類型的handler互不干擾逆日。
工作原理架構(gòu)
初始化并啟動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個NioEventLoopGroup坪圾，其中boosGroup用于Accetpt連接建立事件并分發(fā)請求晓折， workerGroup用于處理I/O讀寫事件和業(yè)務(wù)邏輯
- 2 基于ServerBootstrap(服務(wù)端啟動引導類)，配置EventLoopGroup兽泄、Channel類型漓概，連接參數(shù)、配置入站病梢、出站事件handler
- 3 綁定端口胃珍，開始工作
結(jié)合上面的介紹的Netty Reactor模型蜓陌，介紹服務(wù)端Netty的工作架構(gòu)圖：
server端包含1個Boss NioEventLoopGroup和1個Worker NioEventLoopGroup觅彰，NioEventLoopGroup相當于1個事件循環(huán)組，這個組里包含多個事件循環(huán)NioEventLoop护奈，每個NioEventLoop包含1個selector和1個事件循環(huán)線程缔莲。
每個Boss NioEventLoop循環(huán)執(zhí)行的任務(wù)包含3步：
- 1 輪詢accept事件
- 2 處理accept I/O事件哥纫，與Client建立連接霉旗，生成NioSocketChannel，并將NioSocketChannel注冊到某個Worker NioEventLoop的Selector上
- 3 處理任務(wù)隊列中的任務(wù)蛀骇，runAllTasks厌秒。任務(wù)隊列中的任務(wù)包括用戶調(diào)用eventloop.execute或schedule執(zhí)行的任務(wù)，或者其它線程提交到該eventloop的任務(wù)
每個Worker NioEventLoop循環(huán)執(zhí)行的任務(wù)包含3步：
- 1 輪詢read擅憔、write事件
- 2 處理I/O事件鸵闪，即read、write事件暑诸，在NioSocketChannel可讀蚌讼、可寫事件發(fā)生時進行處理
- 3 處理任務(wù)隊列中的任務(wù)辟灰，runAllTasks
其中任務(wù)隊列中的task有3種典型使用場景
- 1 用戶程序自定義的普通任務(wù)
ctx.channel().eventLoop().execute(new Runnable() {
@Override
public void run() {
//...
}
});
2 非當前reactor線程調(diào)用channel的各種方法
例如在推送系統(tǒng)的業(yè)務(wù)線程里面，根據(jù)用戶的標識篡石，找到對應的channel引用芥喇，然后調(diào)用write類方法向該用戶推送消息，就會進入到這種場景凰萨。最終的write會提交到任務(wù)隊列中后被異步消費继控。3 用戶自定義定時任務(wù)
ctx.channel().eventLoop().schedule(new Runnable() {
@Override
public void run() {
}
}, 60, TimeUnit.SECONDS);
4 總結(jié)
現(xiàn)在穩(wěn)定推薦使用的主流版本還是Netty4，Netty5 中使用了 ForkJoinPool胖眷，增加了代碼的復雜度武通，但是對性能的改善卻不明顯，所以這個版本不推薦使用珊搀，官網(wǎng)也沒有提供下載鏈接冶忱。
Netty 入門門檻相對較高，其實是因為這方面的資料較少食棕，并不是因為他有多難朗和，大家其實都可以像搞透 Spring 一樣搞透 Netty。在學習之前簿晓，建議先理解透整個框架原理結(jié)構(gòu)眶拉，運行過程，可以少走很多彎路憔儿。
參考
Netty入門與實戰(zhàn)：仿寫微信 IM 即時通訊系統(tǒng)
software-architecture-patterns.pdf
《Netty In Action》
《Netty權(quán)威指南》
