1、引言
本文基于 Netty 4.1 展開介紹相關(guān)理論模型，使用場景，基本組件、整體架構(gòu)，知其然且知其所以然，希望給大家在實際開發(fā)實踐、學(xué)習(xí)開源項目方面提供參考。
2、相關(guān)資料
Netty源碼在線閱讀：
- Netty-4.1.x地址是：http://docs.52im.net/extend/docs/src/netty4_1/
- Netty-4.0.x地址是：http://docs.52im.net/extend/docs/src/netty4/
- Netty-3.x地址是：http://docs.52im.net/extend/docs/src/netty3/
Netty在線API文檔：
- Netty-4.1.x API文檔(在線版)：http://docs.52im.net/extend/docs/api/netty4_1/
- Netty-4.0.x API文檔(在線版)：http://docs.52im.net/extend/docs/api/netty4/
- Netty-3.x API文檔(在線版)：http://docs.52im.net/extend/docs/api/netty3/
3、JDK 原生 NIO 程序的問題
JDK 原生也有一套網(wǎng)絡(luò)應(yīng)用程序 API，但是存在一系列問題，主要如下：
- 1）NIO 的類庫和 API 繁雜，使用麻煩：你需要熟練掌握 Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等。
- 2）需要具備其他的額外技能做鋪墊：例如熟悉 Java 多線程編程，因為 NIO 編程涉及到 Reactor 模式，你必須對多線程和網(wǎng)路編程非常熟悉，才能編寫出高質(zhì)量的 NIO 程序。
- 3）可靠性能力補齊，開發(fā)工作量和難度都非常大：例如客戶端面臨斷連重連、網(wǎng)絡(luò)閃斷、半包讀寫、失敗緩存、網(wǎng)絡(luò)擁塞和異常碼流的處理等等。NIO 編程的特點是功能開發(fā)相對容易，但是可靠性能力補齊工作量和難度都非常大。
- 4）JDK NIO 的 Bug：例如臭名昭著的 Epoll Bug，它會導(dǎo)致 Selector 空輪詢，最終導(dǎo)致 CPU 100%。官方聲稱在 JDK 1.6 版本的 update 18 修復(fù)了該問題，但是直到 JDK 1.7 版本該問題仍舊存在，只不過該 Bug 發(fā)生概率降低了一些而已，它并沒有被根本解決。
4、Netty 的特點
Netty 對 JDK 自帶的 NIO 的 API 進行了封裝，解決了上述問題。
Netty的主要特點有：
- 1）設(shè)計優(yōu)雅：適用于各種傳輸類型的統(tǒng)一 API 阻塞和非阻塞 Socket；基于靈活且可擴展的事件模型，可以清晰地分離關(guān)注點；高度可定制的線程模型 - 單線程，一個或多個線程池；真正的無連接數(shù)據(jù)報套接字支持（自 3.1 起）。
- 2）使用方便：詳細記錄的 Javadoc，用戶指南和示例；沒有其他依賴項，JDK 5（Netty 3.x）或 6（Netty 4.x）就足夠了。
- 3）高性能、吞吐量更高：延遲更低；減少資源消耗；最小化不必要的內(nèi)存復(fù)制。
- 4）安全：完整的 SSL/TLS 和 StartTLS 支持。
- 5）社區(qū)活躍、不斷更新：社區(qū)活躍，版本迭代周期短，發(fā)現(xiàn)的 Bug 可以被及時修復(fù)，同時，更多的新功能會被加入。
5、Netty 常見使用場景
Netty 常見的使用場景如下：
- 1）互聯(lián)網(wǎng)行業(yè)：在分布式系統(tǒng)中，各個節(jié)點之間需要遠程服務(wù)調(diào)用，高性能的 RPC 框架必不可少，Netty 作為異步高性能的通信框架，往往作為基礎(chǔ)通信組件被這些 RPC 框架使用。典型的應(yīng)用有：阿里分布式服務(wù)框架 Dubbo 的 RPC 框架使用 Dubbo 協(xié)議進行節(jié)點間通信，Dubbo 協(xié)議默認使用 Netty 作為基礎(chǔ)通信組件，用于實現(xiàn)各進程節(jié)點之間的內(nèi)部通信。
- 2）游戲行業(yè)：無論是手游服務(wù)端還是大型的網(wǎng)絡(luò)游戲，Java 語言得到了越來越廣泛的應(yīng)用。Netty 作為高性能的基礎(chǔ)通信組件，它本身提供了 TCP/UDP 和 HTTP 協(xié)議棧。
非常方便定制和開發(fā)私有協(xié)議棧，賬號登錄服務(wù)器，地圖服務(wù)器之間可以方便的通過 Netty 進行高性能的通信。
- 3）大數(shù)據(jù)領(lǐng)域：經(jīng)典的 Hadoop 的高性能通信和序列化組件 Avro 的 RPC 框架，默認采用 Netty 進行跨界點通信，它的 Netty Service 基于 Netty 框架二次封裝實現(xiàn)。
- 4）物聯(lián)網(wǎng)行業(yè)：基于Netty異步高性能事件驅(qū)動機制，開發(fā)與終端通信的Java后臺服務(wù)程序已經(jīng)不再是難事，已經(jīng)有很多物聯(lián)網(wǎng)企業(yè)選擇Netty。
有興趣的讀者可以了解一下目前有哪些開源項目使用了 Netty的Related Projects:https://netty.io/wiki/related-projects.html
6、Netty 高性能設(shè)計
Netty 作為異步事件驅(qū)動的網(wǎng)絡(luò)，高性能之處主要來自于其 I/O 模型和線程處理模型，前者決定如何收發(fā)數(shù)據(jù)，后者決定如何處理數(shù)據(jù)（重點理解這點）。
6.1I/O 模型
用什么樣的通道將數(shù)據(jù)發(fā)送給對方，BIO、NIO 或者 AIO，I/O 模型在很大程度上決定了框架的性能。
【阻塞 I/O】：
傳統(tǒng)阻塞型 I/O(BIO)可以用下圖表示：
特點如下：
- 每個請求都需要獨立的線程完成數(shù)據(jù) Read，業(yè)務(wù)處理，數(shù)據(jù) Write 的完整操作問題。
- 當(dāng)并發(fā)數(shù)較大時，需要創(chuàng)建大量線程來處理連接，系統(tǒng)資源占用較大。
- 連接建立后，如果當(dāng)前線程暫時沒有數(shù)據(jù)可讀，則線程就阻塞在 Read 操作上，造成線程資源浪費。
【I/O 復(fù)用模型】：
在 I/O 復(fù)用模型中，會用到 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 復(fù)用模型，這里用 Selector 對象表示：
Netty 的 IO 線程 NioEventLoop 由于聚合了多路復(fù)用器 Selector，可以同時并發(fā)處理成百上千個客戶端連接。
當(dāng)線程從某客戶端 Socket 通道進行讀寫數(shù)據(jù)時，若沒有數(shù)據(jù)可用時，該線程可以進行其他任務(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ù)。
6.2線程模型
數(shù)據(jù)報如何讀??？讀取之后的編解碼在哪個線程進行，編解碼后的消息如何派發(fā)，線程模型的不同，對性能的影響也非常大。
【事件驅(qū)動模型】：
通常，我們設(shè)計一個事件處理模型的程序有兩種思路：
- 1）輪詢方式：線程不斷輪詢訪問相關(guān)事件發(fā)生源有沒有發(fā)生事件，有發(fā)生事件就調(diào)用事件處理邏輯；
- 2）事件驅(qū)動方式：發(fā)生事件，主線程把事件放入事件隊列，在另外線程不斷循環(huán)消費事件列表中的事件，調(diào)用事件對應(yīng)的處理邏輯處理事件。事件驅(qū)動方式也被稱為消息通知方式，其實是設(shè)計模式中觀察者模式的思路。
以 GUI 的邏輯處理為例，說明兩種邏輯的不同：
- 1）輪詢方式：線程不斷輪詢是否發(fā)生按鈕點擊事件，如果發(fā)生，調(diào)用處理邏輯。
- 2）事件驅(qū)動方式：發(fā)生點擊事件把事件放入事件隊列，在另外線程消費的事件列表中的事件，根據(jù)事件類型調(diào)用相關(guān)事件處理邏輯。
這里借用 O'Reilly 大神關(guān)于事件驅(qū)動模型解釋圖：
主要包括 4 個基本組件：
- 1）事件隊列（event queue）：接收事件的入口，存儲待處理事件；
- 2）分發(fā)器（event mediator）：將不同的事件分發(fā)到不同的業(yè)務(wù)邏輯單元；
- 3）事件通道（event channel）：分發(fā)器與處理器之間的聯(lián)系渠道；
- 4）事件處理器（event processor）：實現(xiàn)業(yè)務(wù)邏輯，處理完成后會發(fā)出事件，觸發(fā)下一步操作。
可以看出，相對傳統(tǒng)輪詢模式，事件驅(qū)動有如下優(yōu)點：
- 1）可擴展性好：分布式的異步架構(gòu)，事件處理器之間高度解耦，可以方便擴展事件處理邏輯；
- 2）高性能：基于隊列暫存事件，能方便并行異步處理事件。
【Reactor 線程模型】：
Reactor 是反應(yīng)堆的意思，Reactor 模型是指通過一個或多個輸入同時傳遞給服務(wù)處理器的服務(wù)請求的事件驅(qū)動處理模式。
服務(wù)端程序處理傳入多路請求，并將它們同步分派給請求對應(yīng)的處理線程，Reactor 模式也叫 Dispatcher 模式，即 I/O 多了復(fù)用統(tǒng)一監(jiān)聽事件，收到事件后分發(fā)(Dispatch 給某進程)，是編寫高性能網(wǎng)絡(luò)服務(wù)器的必備技術(shù)之一。
Reactor 模型中有 2 個關(guān)鍵組成：
- 1）Reactor：Reactor 在一個單獨的線程中運行，負責(zé)監(jiān)聽和分發(fā)事件，分發(fā)給適當(dāng)?shù)奶幚沓绦騺韺?IO 事件做出反應(yīng)。它就像公司的電話接線員，它接聽來自客戶的電話并將線路轉(zhuǎn)移到適當(dāng)?shù)穆?lián)系人；
- 2）Handlers：處理程序執(zhí)行 I/O 事件要完成的實際事件，類似于客戶想要與之交談的公司中的實際官員。Reactor 通過調(diào)度適當(dāng)?shù)奶幚沓绦騺眄憫?yīng) I/O 事件，處理程序執(zhí)行非阻塞操作。
取決于 Reactor 的數(shù)量和 Hanndler 線程數(shù)量的不同，Reactor 模型有 3 個變種：
- 1）單 Reactor 單線程；
- 2）單 Reactor 多線程；
- 3）主從 Reactor 多線程。
可以這樣理解，Reactor 就是一個執(zhí)行 while (true) { selector.select(); …} 循環(huán)的線程，會源源不斷的產(chǎn)生新的事件，稱作反應(yīng)堆很貼切。
篇幅關(guān)系，這里不再具體展開 Reactor 特性、優(yōu)缺點比較，有興趣的讀者可以參考我之前另外一篇文章：《高性能網(wǎng)絡(luò)編程(五)：一文讀懂高性能網(wǎng)絡(luò)編程中的I/O模型》、《高性能網(wǎng)絡(luò)編程(六)：一文讀懂高性能網(wǎng)絡(luò)編程中的線程模型》。
【Netty 線程模型】：
Netty 主要基于主從 Reactors 多線程模型（如下圖）做了一定的修改，其中主從 Reactor 多線程模型有多個 Reactor：
- 1）MainReactor 負責(zé)客戶端的連接請求，并將請求轉(zhuǎn)交給 SubReactor；
- 2）SubReactor 負責(zé)相應(yīng)通道的 IO 讀寫請求；
- 3）非 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 均是線程池：
- 1）bossGroup 線程池則只是在 Bind 某個端口后，獲得其中一個線程作為 MainReactor，專門處理端口的 Accept 事件，每個端口對應(yīng)一個 Boss 線程；
- 2）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 機制，用戶可以方便的主動獲取或者通過通知機制獲得 IO 操作結(jié)果。
當(dāng) Future 對象剛剛創(chuàng)建時，處于非完成狀態(tài)，調(diào)用者可以通過返回的 ChannelFuture 來獲取操作執(zhí)行的狀態(tài)，注冊監(jiān)聽函數(shù)來執(zhí)行完成后的操作。
常見有如下操作：
- 1）通過 isDone 方法來判斷當(dāng)前操作是否完成；
- 2）通過 isSuccess 方法來判斷已完成的當(dāng)前操作是否成功；
- 3）通過 getCause 方法來獲取已完成的當(dāng)前操作失敗的原因；
- 4）通過 isCancelled 方法來判斷已完成的當(dāng)前操作是否被取消；
- 5）通過 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(new Date() + ": 端口[" + port + "]綁定成功!");
} else {
System.err.println("端口[" + port + "]綁定失敗!");
}
});
相比傳統(tǒng)阻塞 I/O，執(zhí)行 I/O 操作后線程會被阻塞住, 直到操作完成；異步處理的好處是不會造成線程阻塞，線程在 I/O 操作期間可以執(zhí)行別的程序，在高并發(fā)情形下會更穩(wěn)定和更高的吞吐量。
