完全理解Netty，這一篇文章就夠了

Netty究竟是什麼

從HTTP提及

有了Netty，你能夠實現本身的HTTP服務器，FTP服務器，UDP服務器，RPC服務器，WebSocket服務器，Redis的Proxy服務器，MySQL的Proxy服務器等等。

咱們回顧一下傳統的HTTP服務器的原理

一、建立一個ServerSocket，監聽並綁定一個端口

二、一系列客戶端來請求這個端口

三、服務器使用Accept，得到一個來自客戶端的Socket鏈接對象

四、啓動一個新線程處理鏈接

4.一、讀Socket，獲得字節流

4.二、解碼協議，獲得Http請求對象

4.三、處理Http請求，獲得一個結果，封裝成一個HttpResponse對象

4.四、編碼協議，將結果序列化字節流 寫Socket，將字節流發給客戶端

五、繼續循環步驟3

HTTP服務器之因此稱爲HTTP服務器，是由於編碼解碼協議是HTTP協議，若是協議是Redis協議，那它就成了Redis服務器，若是協議是WebSocket，那它就成了WebSocket服務器，等等。 使用Netty你就能夠定製編解碼協議，實現本身的特定協議的服務器。

NIO

上面是一個傳統處理http的服務器，可是在高併發的環境下，線程數量會比較多，System load也會比較高，因而就有了NIO。

他並非Java獨有的概念，NIO表明的一個詞彙叫着IO多路複用。它是由操做系統提供的系統調用，早期這個操做系統調用的名字是select，可是性能低下，後來漸漸演化成了Linux下的epoll和Mac裏的kqueue。咱們通常就說是epoll，由於沒有人拿蘋果電腦做爲服務器使用對外提供服務。而Netty就是基於Java NIO技術封裝的一套框架。爲何要封裝，由於原生的Java NIO使用起來沒那麼方便，並且還有臭名昭著的bug，Netty把它封裝以後，提供了一個易於操做的使用模式和接口，用戶使用起來也就便捷多了。

說NIO以前先說一下BIO（Blocking IO）,如何理解這個Blocking呢？

客戶端監聽（Listen）時，Accept是阻塞的，只有新鏈接來了，Accept纔會返回，主線程才能繼

讀寫socket時，Read是阻塞的，只有請求消息來了，Read才能返回，子線程才能繼續處理

讀寫socket時，Write是阻塞的，只有客戶端把消息收了，Write才能返回，子線程才能繼續讀取下一個請求

傳統的BIO模式下，從頭至尾的全部線程都是阻塞的，這些線程就乾等着，佔用系統的資源，什麼事也不幹。

那麼NIO是怎麼作到非阻塞的呢。它用的是事件機制。它能夠用一個線程把Accept，讀寫操做，請求處理的邏輯全乾了。若是什麼事都沒得作，它也不會死循環，它會將線程休眠起來，直到下一個事件來了再繼續幹活，這樣的一個線程稱之爲NIO線程。用僞代碼表示：

while true {

events = takeEvents(fds) // 獲取事件，若是沒有事件，線程就休眠

for event in events { if event.isAcceptable {

doAccept() // 新連接來了

} elif event.isReadable {

request = doRead() // 讀消息

if request.isComplete() {

doProcess()

}

} elif event.isWriteable {

doWrite() // 寫消息

}

}

}複製代碼

Reactor線程模型

Reactor單線程模型

一個NIO線程+一個accept線程：

Reactor多線程模型

Reactor主從模型

主從Reactor多線程：多個acceptor的NIO線程池用於接受客戶端的鏈接

Netty能夠基於如上三種模型進行靈活的配置。

總結

Netty是創建在NIO基礎之上，Netty在NIO之上又提供了更高層次的抽象。

在Netty裏面，Accept鏈接可使用單獨的線程池去處理，讀寫操做又是另外的線程池來處理。

Accept鏈接和讀寫操做也可使用同一個線程池來進行處理。而請求處理邏輯既可使用單獨的線程池進行處理，也能夠跟放在讀寫線程一塊處理。線程池中的每個線程都是NIO線程。用戶能夠根據實際狀況進行組裝，構造出知足系統需求的高性能併發模型。

爲何選擇Netty

若是不用netty，使用原生JDK的話，有以下問題：

一、API複雜

二、對多線程很熟悉：由於NIO涉及到Reactor模式

三、高可用的話：須要出路斷連重連、半包讀寫、失敗緩存等問題

四、JDK NIO的bug

而Netty來講，他的api簡單、性能高並且社區活躍（dubbo、rocketmq等都使用了它）

什麼是TCP 粘包/拆包

現象

先看以下代碼，這個代碼是使用netty在client端重複寫100次數據給server端，ByteBuf是netty的一個字節容器，裏面存放是的須要發送的數據

public class FirstClientHandler extends ChannelInboundHandlerAdapter {

@Override

public void channelActive(ChannelHandlerContext ctx) {

for (int i = 0; i < 1000; i++) {

ByteBuf buffer = getByteBuf(ctx);

ctx.channel().writeAndFlush(buffer);

}

}

private ByteBuf getByteBuf(ChannelHandlerContext ctx) {

byte[] bytes = "你好，個人名字是1234567!".getBytes(Charset.forName("utf-8"));

ByteBuf buffer = ctx.alloc().buffer();

buffer.writeBytes(bytes);

return buffer;

}

}複製代碼

從client端讀取到的數據爲：

從服務端的控制檯輸出能夠看出，存在三種類型的輸出

一種是正常的字符串輸出。

一種是多個字符串「粘」在了一塊兒，咱們定義這種 ByteBuf 爲粘包。

一種是一個字符串被「拆」開，造成一個破碎的包，咱們定義這種 ByteBuf 爲半包。

透過現象分析緣由

應用層面使用了Netty，可是對於操做系統來講，只認TCP協議，儘管咱們的應用層是按照 ByteBuf 爲 單位來發送數據，server按照Bytebuf讀取，可是到了底層操做系統仍然是按照字節流發送數據，所以，數據到了服務端，也是按照字節流的方式讀入，而後到了 Netty 應用層面，從新拼裝成 ByteBuf，而這裏的 ByteBuf 與客戶端按順序發送的 ByteBuf 多是不對等的。所以，咱們須要在客戶端根據自定義協議來組裝咱們應用層的數據包，而後在服務端根據咱們的應用層的協議來組裝數據包，這個過程一般在服務端稱爲拆包，而在客戶端稱爲粘包。

拆包和粘包是相對的，一端粘了包，另一端就須要將粘過的包拆開，發送端將三個數據包粘成兩個 TCP 數據包發送到接收端，接收端就須要根據應用協議將兩個數據包從新組裝成三個數據包。

如何解決

在沒有 Netty 的狀況下，用戶若是本身須要拆包，基本原理就是不斷從 TCP 緩衝區中讀取數據，每次讀取完都須要判斷是不是一個完整的數據包 若是當前讀取的數據不足以拼接成一個完整的業務數據包，那就保留該數據，繼續從 TCP 緩衝區中讀取，直到獲得一個完整的數據包。 若是當前讀到的數據加上已經讀取的數據足夠拼接成一個數據包，那就將已經讀取的數據拼接上本次讀取的數據，構成一個完整的業務數據包傳遞到業務邏輯，多餘的數據仍然保留，以便和下次讀到的數據嘗試拼接。

而在Netty中，已經造好了許多類型的拆包器，咱們直接用就好：

選好拆包器後，在代碼中client段和server端將拆包器加入到chanelPipeline之中就行了:

如上實例中：

客戶端：

ch.pipeline().addLast(new FixedLengthFrameDecoder(31));複製代碼

服務端：

ch.pipeline().addLast(new FixedLengthFrameDecoder(31));複製代碼

Netty 的零拷貝

傳統意義的拷貝

是在發送數據的時候，傳統的實現方式是：

1. `File.read(bytes)`

2. `Socket.send(bytes)`

這種方式須要四次數據拷貝和四次上下文切換：

1. 數據從磁盤讀取到內核的read buffer

2. 數據從內核緩衝區拷貝到用戶緩衝區

3. 數據從用戶緩衝區拷貝到內核的socket buffer

4. 數據從內核的socket buffer拷貝到網卡接口（硬件）的緩衝區

零拷貝的概念

明顯上面的第二步和第三步是沒有必要的，經過java的FileChannel.transferTo方法，能夠避免上面兩次多餘的拷貝（固然這須要底層操做系統支持）

1. 調用transferTo,數據從文件由DMA引擎拷貝到內核read buffer

2. 接着DMA從內核read buffer將數據拷貝到網卡接口buffer

上面的兩次操做都不須要CPU參與，因此就達到了零拷貝。

Netty中的零拷貝

主要體如今三個方面：

一、bytebuffer

Netty發送和接收消息主要使用bytebuffer，bytebuffer使用對外內存（DirectMemory）直接進行Socket讀寫。

緣由：若是使用傳統的堆內存進行Socket讀寫，JVM會將堆內存buffer拷貝一份到直接內存中而後再寫入socket，多了一次緩衝區的內存拷貝。DirectMemory中能夠直接經過DMA發送到網卡接口

二、Composite Buffers

傳統的ByteBuffer，若是須要將兩個ByteBuffer中的數據組合到一塊兒，咱們須要首先建立一個size=size1+size2大小的新的數組，而後將兩個數組中的數據拷貝到新的數組中。可是使用Netty提供的組合ByteBuf，就能夠避免這樣的操做，由於CompositeByteBuf並無真正將多個Buffer組合起來，而是保存了它們的引用，從而避免了數據的拷貝，實現了零拷貝。

三、對於FileChannel.transferTo的使用

Netty中使用了FileChannel的transferTo方法，該方法依賴於操做系統實現零拷貝。

Netty 內部執行流程

服務端：

一、建立ServerBootStrap實例

二、設置並綁定Reactor線程池：EventLoopGroup，EventLoop就是處理全部註冊到本線程的Selector上面的Channel

三、設置並綁定服務端的channel

四、五、建立處理網絡事件的ChannelPipeline和handler，網絡時間以流的形式在其中流轉，handler完成多數的功能定製：好比編解碼 SSl安全認證

六、綁定並啓動監聽端口

七、當輪訓到準備就緒的channel後，由Reactor線程：NioEventLoop執行pipline中的方法，最終調度並執行channelHandler

八、說到這裏順便給你們推薦一個Java的交流學習社區：586446657，裏面不只能夠交流討論，還有面試經驗分享以及免費的資料下載，包括Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。相信對於已經工做和遇到技術瓶頸的碼友，在這裏會有你須要的內容。

客戶端

總結

以上就是我對Netty相關知識整理，若是有不一樣的看法，歡迎討論！