日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

1、引言

本文基于 Netty 4.1 展開介紹相關理論模型，使用場景，基本組件、整體架構，知其然且知其所以然，希望給大家在實際開發(fā)實踐、學習開源項目方面提供參考。

2、相關資料

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)絡應用程序 API，但是存在一系列問題，主要如下：

• 1）NIO 的類庫和 API 繁雜，使用麻煩：你需要熟練掌握 Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等。
• 2）需要具備其他的額外技能做鋪墊：例如熟悉 Java 多線程編程，因為 NIO 編程涉及到 Reactor 模式，你必須對多線程和網(wǎng)路編程非常熟悉，才能編寫出高質(zhì)量的 NIO 程序。
• 3）可靠性能力補齊，開發(fā)工作量和難度都非常大：例如客戶端面臨斷連重連、網(wǎng)絡閃斷、半包讀寫、失敗緩存、網(wǎng)絡擁塞和異常碼流的處理等等。NIO 編程的特點是功能開發(fā)相對容易，但是可靠性能力補齊工作量和難度都非常大。
• 4）JDK NIO 的 Bug：例如臭名昭著的 Epoll Bug，它會導致 Selector 空輪詢，最終導致 CPU 100%。官方聲稱在 JDK 1.6 版本的 update 18 修復了該問題，但是直到 JDK 1.7 版本該問題仍舊存在，只不過該 Bug 發(fā)生概率降低了一些而已，它并沒有被根本解決。

4、Netty 的特點

Netty 對 JDK 自帶的 NIO 的 API 進行了封裝，解決了上述問題。
Netty的主要特點有：

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

5、Netty 常見使用場景

Netty 常見的使用場景如下：

• 1）互聯(lián)網(wǎng)行業(yè)：在分布式系統(tǒng)中，各個節(jié)點之間需要遠程服務調(diào)用，高性能的 RPC 框架必不可少，Netty 作為異步高性能的通信框架，往往作為基礎通信組件被這些 RPC 框架使用。典型的應用有：阿里分布式服務框架 Dubbo 的 RPC 框架使用 Dubbo 協(xié)議進行節(jié)點間通信，Dubbo 協(xié)議默認使用 Netty 作為基礎通信組件，用于實現(xiàn)各進程節(jié)點之間的內(nèi)部通信。
• 2）游戲行業(yè)：無論是手游服務端還是大型的網(wǎng)絡游戲，Java 語言得到了越來越廣泛的應用。Netty 作為高性能的基礎通信組件，它本身提供了 TCP/UDP 和 HTTP 協(xié)議棧。

非常方便定制和開發(fā)私有協(xié)議棧，賬號登錄服務器，地圖服務器之間可以方便的通過 Netty 進行高性能的通信。

• 3）大數(shù)據(jù)領域：經(jīng)典的 Hadoop 的高性能通信和序列化組件 Avro 的 RPC 框架，默認采用 Netty 進行跨界點通信，它的 Netty Service 基于 Netty 框架二次封裝實現(xiàn)。
• 4）物聯(lián)網(wǎng)行業(yè)：基于Netty異步高性能事件驅(qū)動機制，開發(fā)與終端通信的Java后臺服務程序已經(jīng)不再是難事，已經(jīng)有很多物聯(lián)網(wǎng)企業(yè)選擇Netty。

有興趣的讀者可以了解一下目前有哪些開源項目使用了 Netty的Related Projects:https://netty.io/wiki/related-projects.html

6、Netty 高性能設計

Netty 作為異步事件驅(qū)動的網(wǎng)絡，高性能之處主要來自于其 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è)務處理，數(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)關鍵是基于 I/O 復用模型，這里用 Selector 對象表示：

Netty 的 IO 線程 NioEventLoop 由于聚合了多路復用器 Selector，可以同時并發(fā)處理成百上千個客戶端連接。
當線程從某客戶端 Socket 通道進行讀寫數(shù)據(jù)時，若沒有數(shù)據(jù)可用時，該線程可以進行其他任務。
線程通常將非阻塞 IO 的空閑時間用于在其他通道上執(zhí)行 IO 操作，所以單獨的線程可以管理多個輸入和輸出通道。
由于讀寫操作都是非阻塞的，這就可以充分提升 IO 線程的運行效率，避免由于頻繁 I/O 阻塞導致的線程掛起。
一個 I/O 線程可以并發(fā)處理 N 個客戶端連接和讀寫操作，這從根本上解決了傳統(tǒng)同步阻塞 I/O 一連接一線程模型，架構的性能、彈性伸縮能力和可靠性都得到了極大的提升。
【基于 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ū)動模型】：
通常，我們設計一個事件處理模型的程序有兩種思路：

• 1）輪詢方式：線程不斷輪詢訪問相關事件發(fā)生源有沒有發(fā)生事件，有發(fā)生事件就調(diào)用事件處理邏輯；
• 2）事件驅(qū)動方式：發(fā)生事件，主線程把事件放入事件隊列，在另外線程不斷循環(huán)消費事件列表中的事件，調(diào)用事件對應的處理邏輯處理事件。事件驅(qū)動方式也被稱為消息通知方式，其實是設計模式中觀察者模式的思路。

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

• 1）輪詢方式：線程不斷輪詢是否發(fā)生按鈕點擊事件，如果發(fā)生，調(diào)用處理邏輯。
• 2）事件驅(qū)動方式：發(fā)生點擊事件把事件放入事件隊列，在另外線程消費的事件列表中的事件，根據(jù)事件類型調(diào)用相關事件處理邏輯。

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

主要包括 4 個基本組件：

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

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

• 1）可擴展性好：分布式的異步架構，事件處理器之間高度解耦，可以方便擴展事件處理邏輯；
• 2）高性能：基于隊列暫存事件，能方便并行異步處理事件。

【Reactor 線程模型】：
Reactor 是反應堆的意思，Reactor 模型是指通過一個或多個輸入同時傳遞給服務處理器的服務請求的事件驅(qū)動處理模式。
服務端程序處理傳入多路請求，并將它們同步分派給請求對應的處理線程，Reactor 模式也叫 Dispatcher 模式，即 I/O 多了復用統(tǒng)一監(jiān)聽事件，收到事件后分發(fā)(Dispatch 給某進程)，是編寫高性能網(wǎng)絡服務器的必備技術之一。
Reactor 模型中有 2 個關鍵組成：

• 1）Reactor：Reactor 在一個單獨的線程中運行，負責監(jiān)聽和分發(fā)事件，分發(fā)給適當?shù)奶幚沓绦騺韺?IO 事件做出反應。它就像公司的電話接線員，它接聽來自客戶的電話并將線路轉(zhuǎn)移到適當?shù)穆?lián)系人；
• 2）Handlers：處理程序執(zhí)行 I/O 事件要完成的實際事件，類似于客戶想要與之交談的公司中的實際官員。Reactor 通過調(diào)度適當?shù)奶幚沓绦騺眄憫?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)生新的事件，稱作反應堆很貼切。
篇幅關系，這里不再具體展開 Reactor 特性、優(yōu)缺點比較，有興趣的讀者可以參考我之前另外一篇文章：《高性能網(wǎng)絡編程(五)：一文讀懂高性能網(wǎng)絡編程中的I/O模型》、《高性能網(wǎng)絡編程(六)：一文讀懂高性能網(wǎng)絡編程中的線程模型》。
【Netty 線程模型】：
Netty 主要基于主從 Reactors 多線程模型（如下圖）做了一定的修改，其中主從 Reactor 多線程模型有多個 Reactor：

• 1）MainReactor 負責客戶端的連接請求，并將請求轉(zhuǎn)交給 SubReactor；
• 2）SubReactor 負責相應通道的 IO 讀寫請求；
• 3）非 IO 請求（具體邏輯處理）的任務則會直接寫入隊列，等待 worker threads 進行處理。

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

特別說明的是：雖然 Netty 的線程模型基于主從 Reactor 多線程，借用了 MainReactor 和 SubReactor 的結構。但是實際實現(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 構造方法中傳入的兩個對象，這兩個 group 均是線程池：

• 1）bossGroup 線程池則只是在 Bind 某個端口后，獲得其中一個線程作為 MainReactor，專門處理端口的 Accept 事件，每個端口對應一個 Boss 線程；
• 2）workerGroup 線程池會被各個 SubReactor 和 Worker 線程充分利用。

【異步處理】：
異步的概念和同步相對。當一個異步過程調(diào)用發(fā)出后，調(diào)用者不能立刻得到結果。實際處理這個調(diào)用的部件在完成后，通過狀態(tài)、通知和回調(diào)來通知調(diào)用者。
Netty 中的 I/O 操作是異步的，包括 Bind、Write、Connect 等操作會簡單的返回一個 ChannelFuture。
調(diào)用者并不能立刻獲得結果，而是通過 Future-Listener 機制，用戶可以方便的主動獲取或者通過通知機制獲得 IO 操作結果。
當 Future 對象剛剛創(chuàng)建時，處于非完成狀態(tài)，調(diào)用者可以通過返回的 ChannelFuture 來獲取操作執(zhí)行的狀態(tài)，注冊監(jiān)聽函數(shù)來執(zhí)行完成后的操作。
常見有如下操作：

• 1）通過 isDone 方法來判斷當前操作是否完成；
• 2）通過 isSuccess 方法來判斷已完成的當前操作是否成功；
• 3）通過 getCause 方法來獲取已完成的當前操作失敗的原因；
• 4）通過 isCancelled 方法來判斷已完成的當前操作是否被取消；
• 5）通過 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)定和更高的吞吐量。