一、Netty到底是什麼

1、從HTTP說起

有了Netty，你可以實現自己的HTTP伺服器、FTP伺服器、UDP伺服器、RPC伺服器、WebSocket伺服器、Redis的Proxy伺服器、MySQL的Proxy伺服器等等。

我們回顧一下傳統的HTTP伺服器的原理：

1. 建立一個ServerSocket，監聽並繫結一個埠
2. 一系列客戶端來請求這個埠
3. 伺服器使用Accept，獲得一個來自客戶端的Socket連線物件
4. 啟動一個新執行緒處理連線

• 讀Socket，得到位元組流
• 解碼協議，得到Http請求物件
• 處理Http請求，得到一個結果，封裝成一個HttpResponse物件
• 編碼協議，將結果序列化位元組流 寫Socket，將位元組流發給客戶端

最後，繼續迴圈步驟3

HTTP伺服器之所以稱為HTTP伺服器，是因為編碼解碼協議是HTTP協議，如果協議是Redis協議，那它就成了Redis伺服器，如果協議是WebSocket，那它就成了WebSocket伺服器，等等。 使用Netty你就可以定製編解碼協議，實現自己的特定協議的伺服器。

2、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執行緒。用偽程式碼表示：

二、Reactor執行緒模型

1、Reactor單執行緒模型

一個NIO執行緒+一個accept執行緒：

2、Reactor多執行緒模型

3、Reactor主從模型

主從Reactor多執行緒：多個acceptor的NIO執行緒池用於接受客戶端的連線

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

4、小結

Netty是建立在NIO基礎之上，Netty在NIO之上又提供了更高層次的抽象，在Netty裡面，Accept連線可以使用單獨的執行緒池去處理，讀寫操作又是另外的執行緒池來處理。

Accept連線和讀寫操作也可以使用同一個執行緒池來進行處理，而請求處理邏輯既可以使用單獨的執行緒池進行處理，也可以跟放在讀寫執行緒一塊處理。執行緒池中的每一個執行緒都是NIO執行緒，使用者可以根據實際情況進行組裝，構造出滿足系統需求的高效能併發模型。

三、為什麼選擇Netty

如果不用netty，使用原生JDK的話，有如下問題：

1. API複雜
2. 對多執行緒很熟悉：因為NIO涉及到Reactor模式
3. 高可用的話：需要出路斷連重連、半包讀寫、失敗快取等問題
4. JDK NIO的bug

而Netty來說，他的api簡單、效能高而且社群活躍（dubbo、rocketmq等都使用了它）

四、什麼是TCP 粘包/拆包

1、現象

先看如下程式碼，這個程式碼是使用netty在client端重複寫100次資料給server端，ByteBuf是netty的一個位元組容器，裡面存放是的需要傳送的資料:

從client端讀取到的資料為：

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

1. 一種是正常的字串輸出。
2. 一種是多個字串“粘”在了一起，我們定義這種 ByteBuf 為粘包。
3. 一種是一個字串被“拆”開，形成一個破碎的包，我們定義這種 ByteBuf 為半包。

2、透過現象分析原因

應用層面使用了Netty，但是對於作業系統來說，只認TCP協議，儘管我們的應用層是按照 ByteBuf 為單位來發送資料，server按照Bytebuf讀取，但是到了底層作業系統仍然是按照位元組流傳送資料，因此，資料到了服務端，也是按照位元組流的方式讀入，然後到了 Netty 應用層面，重新拼裝成 ByteBuf，而這裡的 ByteBuf 與客戶端按順序傳送的 ByteBuf 可能是不對等的。因此，我們需要在客戶端根據自定義協議來組裝我們應用層的資料包，然後在服務端根據我們的應用層的協議來組裝資料包，這個過程通常在服務端稱為拆包，而在客戶端稱為粘包。

拆包和粘包是相對的，一端粘了包，另外一端就需要將粘過的包拆開，傳送端將三個資料包粘成兩個 TCP 資料包傳送到接收端，接收端就需要根據應用協議將兩個資料包重新組裝成三個資料包。

3、如何解決

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

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

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

如上例項中：

客戶端：

服務端：

五、Netty 的零拷貝

1、傳統意義的拷貝

是在傳送資料的時候，傳統的實現方式是：

1. File.read(bytes)
2. Socket.send(bytes)

這種方式需要四次資料拷貝和四次上下文切換：

1. 資料從磁碟讀取到核心的read buffer
2. 資料從核心緩衝區拷貝到使用者緩衝區
3. 資料從使用者緩衝區拷貝到核心的socket buffer
4. 資料從核心的socket buffer拷貝到網絡卡介面（硬體）的緩衝區

2、零拷貝的概念

明顯上面的第二步和第三步是沒有必要的，通過java的FileChannel.transferTo方法，可以避免上面兩次多餘的拷貝（當然這需要底層作業系統支援）

1. 呼叫transferTo,資料從檔案由DMA引擎拷貝到核心read buffer
2. 接著DMA從核心read buffer將資料拷貝到網絡卡介面buffer

上面的兩次操作都不需要CPU參與，所以就達到了零拷貝。

1. Netty中的零拷貝

主要體現在三個方面：

1、bytebuffer

Netty傳送和接收訊息主要使用bytebuffer，bytebuffer使用對外記憶體（DirectMemory）直接進行Socket讀寫。

原因：如果使用傳統的堆記憶體進行Socket讀寫，JVM會將堆記憶體buffer拷貝一份到直接記憶體中然後再寫入socket，多了一次緩衝區的記憶體拷貝。DirectMemory中可以直接通過DMA傳送到網絡卡介面

2、Composite Buffers

傳統的ByteBuffer，如果需要將兩個ByteBuffer中的資料組合到一起，我們需要首先建立一個size=size1+size2大小的新的陣列，然後將兩個陣列中的資料拷貝到新的陣列中。但是使用Netty提供的組合ByteBuf，就可以避免這樣的操作，因為CompositeByteBuf並沒有真正將多個Buffer組合起來，而是儲存了它們的引用，從而避免了資料的拷貝，實現了零拷貝。

3、對於FileChannel.transferTo的使用

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

除了這些，針對當前網際網路公司的技術需求以及結合主流技術，我自己整理了一套系統的架構技術體系，當你技術過硬的時候，能夠解決技術問題才會服眾。不少公司都很重視高併發高可用的技術，特別是一線網際網路公司，分散式、JVM、spring原始碼分析、微服務等知識點已是面試的必考題，這些東西可能你們平時在工作中接觸過，但是缺少的全面系統的學習，加入後端開發群：943918498，或是關注微信公眾號：Java資訊庫，回覆“架構”，免費領取架構資料。

六、Netty 內部執行流程

1、服務端：

1. 建立ServerBootStrap例項
2. 設定並繫結Reactor執行緒池：EventLoopGroup，EventLoop就是處理所有註冊到本執行緒的Selector上面的Channel
3. 設定並繫結服務端的channel
4. 建立處理網路事件的ChannelPipeline和handler，網路時間以流的形式在其中流轉，handler完成多數的功能定製：比如編解碼
   SSl安全認證
5. 繫結並啟動監聽埠
6. 當輪訓到準備就緒的channel後，由Reactor執行緒：NioEventLoop執行pipline中的方法，最終排程並執行channelHandler

2、客戶端