Netty 原理

Netty 是一個(gè)高性能、異步事件驅(qū)動(dòng)的NIO 框架，基于JAVA NIO 提供的API 實(shí)現(xiàn)。它提供了對(duì)TCP、UDP 和文件傳輸?shù)闹С郑鳛橐粋€(gè)異步NIO 框架，Netty 的所有IO 操作都是異步非阻塞的，通過(guò)Future-Listener 機(jī)制，用戶可以方便的主動(dòng)獲取或者通過(guò)通知機(jī)制獲得IO 操作結(jié)果。

Netty 高性能

在IO 編程過(guò)程中，當(dāng)需要同時(shí)處理多個(gè)客戶端接入請(qǐng)求時(shí)，可以利用多線程或者IO 多路復(fù)用技術(shù)進(jìn)行處理。IO 多路復(fù)用技術(shù)通過(guò)把多個(gè)IO 的阻塞復(fù)用到同一個(gè)select 的阻塞上，從而使得系統(tǒng)在單線程的情況下可以同時(shí)處理多個(gè)客戶端請(qǐng)求。與傳統(tǒng)的多線程/多進(jìn)程模型比，I/O 多路復(fù)用的最大優(yōu)勢(shì)是系統(tǒng)開(kāi)銷小，系統(tǒng)不需要?jiǎng)?chuàng)建新的額外進(jìn)程或者線程，也不需要維護(hù)這些進(jìn)程和線程的運(yùn)行，降低了系統(tǒng)的維護(hù)工作量，節(jié)省了系統(tǒng)資源。

與Socket 類和ServerSocket 類相對(duì)應(yīng)，NIO也提供了SocketChannel 和ServerSocketChannel兩種不同的套接字通道實(shí)現(xiàn)。

多路復(fù)用的通訊方式

Netty 架構(gòu)按照Reactor 模式設(shè)計(jì)和實(shí)現(xiàn)，它的服務(wù)端通信序列圖如下：

image.png

客戶端通信序列圖如下：

image.png

Netty 的IO 線程N(yùn)ioEventLoop 由于聚合了多路復(fù)用器Selector，可以同時(shí)并發(fā)處理成百上千個(gè)客戶端Channel，由于讀寫(xiě)操作都是非阻塞的，這就可以充分提升IO 線程的運(yùn)行效率，避免由于頻繁IO 阻塞導(dǎo)致的線程掛起。

異步通信 NIO

由于Netty 采用了異步通信模式，一個(gè)IO 線程可以并發(fā)處理N 個(gè)客戶端連接和讀寫(xiě)操作，這從根本上解決了傳統(tǒng)同步阻塞IO 一連接一線程模型，架構(gòu)的性能、彈性伸縮能力和可靠性都得到了極大的提升。

零拷貝DIRECT BUFFERS (使用堆外直接內(nèi)存)

1. Netty 的接收和發(fā)送ByteBuffer 采用DIRECT BUFFERS，使用堆外直接內(nèi)存進(jìn)行Socket 讀寫(xiě)，不需要進(jìn)行字節(jié)緩沖區(qū)的二次拷貝。如果使用傳統(tǒng)的堆內(nèi)存（HEAP BUFFERS）進(jìn)行Socket 讀寫(xiě)，JVM 會(huì)將堆內(nèi)存Buffer 拷貝一份到直接內(nèi)存中，然后才寫(xiě)入Socket 中。相比于堆外直接內(nèi)存，消息在發(fā)送過(guò)程中多了一次緩沖區(qū)的內(nèi)存拷貝。
2. Netty 提供了組合Buffer 對(duì)象，可以聚合多個(gè)ByteBuffer 對(duì)象，用戶可以像操作一個(gè)Buffer 那樣方便的對(duì)組合Buffer 進(jìn)行操作，避免了傳統(tǒng)通過(guò)內(nèi)存拷貝的方式將幾個(gè)小Buffer 合并成一個(gè)大的Buffer。
3. Netty 的文件傳輸采用了transferTo方法，它可以直接將文件緩沖區(qū)的數(shù)據(jù)發(fā)送到目標(biāo)Channel，避免了傳統(tǒng)通過(guò)循環(huán)write 方式導(dǎo)致的內(nèi)存拷貝問(wèn)題

內(nèi)存池（基于內(nèi)存池的緩沖區(qū)重用機(jī)制）

隨著JVM 虛擬機(jī)和JIT 即時(shí)編譯技術(shù)的發(fā)展，對(duì)象的分配和回收是個(gè)非常輕量級(jí)的工作。但是對(duì)于緩沖區(qū)Buffer，情況卻稍有不同，特別是對(duì)于堆外直接內(nèi)存的分配和回收，是一件耗時(shí)的操作。為了盡量重用緩沖區(qū)，Netty 提供了基于內(nèi)存池的緩沖區(qū)重用機(jī)制。

高效的 Reactor線程模型

常用的Reactor 線程模型有三種，Reactor 單線程模型, Reactor 多線程模型, 主從Reactor 多線程模型。

Reactor 單線程模型：
Reactor 單線程模型，指的是所有的IO 操作都在同一個(gè)NIO 線程上面完成，NIO 線程的職責(zé)如下：

1. 作為NIO 服務(wù)端，接收客戶端的TCP 連接；
2. 作為NIO 客戶端，向服務(wù)端發(fā)起TCP 連接；
3. 讀取通信對(duì)端的請(qǐng)求或者應(yīng)答消息；

4. 向通信對(duì)端發(fā)送消息請(qǐng)求或者應(yīng)答消息。

   
   
   image.png

由于Reactor 模式使用的是異步非阻塞IO，所有的IO 操作都不會(huì)導(dǎo)致阻塞，理論上一個(gè)線程可以獨(dú)立處理所有IO 相關(guān)的操作。從架構(gòu)層面看，一個(gè)NIO 線程確實(shí)可以完成其承擔(dān)的職責(zé)。例如，通過(guò)Acceptor 接收客戶端的TCP 連接請(qǐng)求消息，鏈路建立成功之后，通過(guò)Dispatch 將對(duì)應(yīng)的ByteBuffer派發(fā)到指定的Handler 上進(jìn)行消息解碼。用戶Handler 可以通過(guò)NIO 線程將消息發(fā)送給客戶端。

Reactor 多線程模型
Rector 多線程模型與單線程模型最大的區(qū)別就是有一組NIO 線程處理IO 操作。 有專門(mén)一個(gè)NIO 線程-Acceptor 線程用于監(jiān)聽(tīng)服務(wù)端，接收客戶端的TCP 連接請(qǐng)求； 網(wǎng)絡(luò)IO 操作-讀、寫(xiě)等由一個(gè)NIO 線程池負(fù)責(zé)，線程池可以采用標(biāo)準(zhǔn)的JDK 線程池實(shí)現(xiàn)，它包含一個(gè)任務(wù)隊(duì)列和N個(gè)可用的線程，由這些NIO 線程負(fù)責(zé)消息的讀取、解碼、編碼和發(fā)送；

image.png

主從Reactor多線程模型
服務(wù)端用于接收客戶端連接的不再是個(gè)1 個(gè)單獨(dú)的NIO 線程，而是一個(gè)獨(dú)立的NIO 線程池。
Acceptor 接收到客戶端TCP 連接請(qǐng)求處理完成后（可能包含接入認(rèn)證等），將新創(chuàng)建的
SocketChannel 注冊(cè)到IO 線程池（sub reactor 線程池）的某個(gè)IO 線程上，由它負(fù)責(zé)
SocketChannel 的讀寫(xiě)和編解碼工作。Acceptor 線程池僅僅只用于客戶端的登陸、握手和安全認(rèn)證，一旦鏈路建立成功，就將鏈路注冊(cè)到后端subReactor 線程池的IO 線程上，由IO 線程負(fù)責(zé)后續(xù)的IO 操作。

image.png

無(wú)鎖設(shè)計(jì)、線程鎖定

Netty 采用了串行無(wú)鎖化設(shè)計(jì)，在IO 線程內(nèi)部進(jìn)行串行操作，避免多線程競(jìng)爭(zhēng)導(dǎo)致的性能下降。表面上看，串行化設(shè)計(jì)似乎CPU 利用率不高，并發(fā)程度不夠。但是，通過(guò)調(diào)整NIO 線程池的線程參數(shù)，可以同時(shí)啟動(dòng)多個(gè)串行化的線程并行運(yùn)行，這種局部無(wú)鎖化的串行線程設(shè)計(jì)相比一個(gè)隊(duì)列-多個(gè)工作線程模型性能更優(yōu)。

image.png

Netty 的NioEventLoop 讀取到消息之后，直接調(diào)用ChannelPipeline 的fireChannelRead(Object msg)，只要用戶不主動(dòng)切換線程，一直會(huì)由NioEventLoop 調(diào)用到用戶的Handler，期間不進(jìn)行線程切換，這種串行化處理方式避免了多線程操作導(dǎo)致的鎖的競(jìng)爭(zhēng)，從性能角度看是最優(yōu)的。

高性能的序列化框架

Netty 默認(rèn)提供了對(duì)Google Protobuf 的支持，通過(guò)擴(kuò)展Netty 的編解碼接口，用戶可以實(shí)現(xiàn)其它的高性能序列化框架，例如Thrift 的壓縮二進(jìn)制編解碼框架。

1. SO_RCVBUF 和SO_SNDBUF：通常建議值為128K 或者256K。
   小包封大包，防止網(wǎng)絡(luò)阻塞
2. SO_TCPNODELAY：NAGLE 算法通過(guò)將緩沖區(qū)內(nèi)的小封包自動(dòng)相連，組成較大的封包，阻止大量小封包的發(fā)送阻塞網(wǎng)絡(luò)，從而提高網(wǎng)絡(luò)應(yīng)用效率。但是對(duì)于時(shí)延敏感的應(yīng)用場(chǎng)景需要關(guān)閉該優(yōu)化算法。
   軟中斷 Hash 值和 CPU 綁定
3. 軟中斷：開(kāi)啟RPS 后可以實(shí)現(xiàn)軟中斷，提升網(wǎng)絡(luò)吞吐量。RPS 根據(jù)數(shù)據(jù)包的源地址，目的地址以及目的和源端口，計(jì)算出一個(gè)hash 值，然后根據(jù)這個(gè)hash 值來(lái)選擇軟中斷運(yùn)行的cpu，從上層來(lái)看，也就是說(shuō)將每個(gè)連接和cpu 綁定，并通過(guò)這個(gè)hash 值，來(lái)均衡軟中斷在多個(gè)cpu 上，提升網(wǎng)絡(luò)并行處理性能。