Netty（DotNetty）原理解析

一、背景介紹

DotNetty是微軟的Azure團隊，使用C#實現的Netty的版本發佈。不但使用了C#和.Net平臺的技術特點，並且保留了Netty原來絕大部分的編程接口。讓我們在使用時，完全可以依照Netty官方的教程來學習和使用DotNetty應用程序。

Netty 是一個異步事件驅動的網絡應用程序框架，用於快速開發可維護的高性能協議服務器和客戶端。

二、NIO

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

 

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

1.客戶端監聽（Listen）時，Accept是阻塞的，只有新連接來了，Accept纔會返回，主線程才能繼讀寫socket時，Read是阻塞的，只有請求消息來了，Read才能返回，子線程才能繼續處理。

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

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

Netty 的非阻塞 I/O 的實現關鍵是基於 I/O 複用模型，這裏用 Selector 對象表示：

 

1.Netty 的 IO 線程 NioEventLoop 由於聚合了多路複用器 Selector，可以同時併發處理成百上千個客戶端連接。

2.當線程從某客戶端 Socket 通道進行讀寫數據時，若沒有數據可用時，該線程可以進行其他任務。

3.線程通常將非阻塞 IO 的空閒時間用於在其他通道上執行 IO 操作，所以單獨的線程可以管理多個輸入和輸出通道。

4.由於讀寫操作都是非阻塞的，這就可以充分提升 IO 線程的運行效率，避免由於頻繁 I/O 阻塞導致的線程掛起。

5.一個 I/O 線程可以併發處理 N 個客戶端連接和讀寫操作，這從根本上解決了傳統同步阻塞 I/O 一連接一線程模型，架構的性能、彈性伸縮能力和可靠性都得到了極大的提升。

基於Buffer

傳統的 I/O 是面向字節流或字符流的，以流式的方式順序地從一個 Stream 中讀取一個或多個字節, 因此也就不能隨意改變讀取指針的位置。

在 NIO 中，拋棄了傳統的 I/O 流，而是引入了 Channel 和 Buffer 的概念。在 NIO 中，只能從 Channel 中讀取數據到 Buffer 中或將數據從 Buffer 中寫入到 Channel。

基於 Buffer 操作不像傳統 IO 的順序操作，NIO 中可以隨意地讀取任意位置的數據。

事件驅動模型

通常，我們設計一個事件處理模型的程序有兩種思路：

• 1.輪詢方式，線程不斷輪詢訪問相關事件發生源有沒有發生事件，有發生事件就調用事件處理邏輯。
• 2.事件驅動方式，發生事件，主線程把事件放入事件隊列，在另外線程不斷循環消費事件列表中的事件，調用事件對應的處理邏輯處理事件。事件驅動方式也被稱爲消息通知方式，其實是設計模式中觀察者模式的思路。

事件機制，它可以用一個線程把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模式使用的是異步非阻塞IO，所有的IO操作都不會導致阻塞，理論上一個線程可以獨立處理所有IO相關的操作。從架構層面看，一個NIO線程確實可以完成其承擔的職責。例如，通過Acceptor類接收客戶端的TCP連接請求消息，鏈路建立成功之後，通過Dispatch將對應的ByteBuffer派發到指定的Handler上進行消息解碼。用戶線程可以通過消息編碼通過NIO線程將消息發送給客戶端。

對於一些小容量應用場景，可以使用單線程模型。但是對於高負載、大併發的應用場景卻不合適，主要原因如下：

1）一個NIO線程同時處理成百上千的鏈路，性能上無法支撐，即便NIO線程的CPU負荷達到100%，也無法滿足海量消息的編碼、解碼、讀取和發送；

2）當NIO線程負載過重之後，處理速度將變慢，這會導致大量客戶端連接超時，超時之後往往會進行重發，這更加重了NIO線程的負載，最終會導致大量消息積壓和處理超時，成爲系統的性能瓶頸；

3）可靠性問題：一旦NIO線程意外跑飛，或者進入死循環，會導致整個系統通信模塊不可用，不能接收和處理外部消息，造成節點故障。

 

Reactor多線程模型

 

Reactor多線程模型的特點：

1）有專門一個NIO線程-Acceptor線程用於監聽服務端，接收客戶端的TCP連接請求；

2）網絡IO操作-讀、寫等由一個NIO線程池負責，線程池可以採用標準的JDK線程池實現，它包含一個任務隊列和N個可用的線程，由這些NIO線程負責消息的讀取、解碼、編碼和發送；

3）1個NIO線程可以同時處理N條鏈路，但是1個鏈路只對應1個NIO線程，防止發生併發操作問題。

在絕大多數場景下，Reactor多線程模型都可以滿足性能需求；但是，在極個別特殊場景中，一個NIO線程負責監聽和處理所有的客戶端連接可能會存在性能問題。例如併發百萬客戶端連接，或者服務端需要對客戶端握手進行安全認證，但是認證本身非常損耗性能。在這類場景下，單獨一個Acceptor線程可能會存在性能不足問題，爲了解決性能問題，產生了第三種Reactor線程模型-主從Reactor多線程模型。

 

Reactor主從模型

、

主從Reactor線程模型的特點是：服務端用於接收客戶端連接的不再是個1個單獨的NIO線程，而是一個獨立的NIO線程池。Acceptor接收到客戶端TCP連接請求處理完成後（可能包含接入認證等），將新創建的SocketChannel註冊到IO線程池（sub reactor線程池）的某個IO線程上，由它負責SocketChannel的讀寫和編解碼工作。Acceptor線程池僅僅只用於客戶端的登陸、握手和安全認證，一旦鏈路建立成功，就將鏈路註冊到後端subReactor線程池的IO線程上，由IO線程負責後續的IO操作。

利用主從NIO線程模型，可以解決1個服務端監聽線程無法有效處理所有客戶端連接的性能不足問題。

它的工作流程總結如下：

1. 從主線程池中隨機選擇一個Reactor線程作爲Acceptor線程，用於綁定監聽端口，接收客戶端連接；
2. Acceptor線程接收客戶端連接請求之後創建新的SocketChannel，將其註冊到主線程池的其它Reactor線程上，由其負責接入認證、IP黑白名單過濾、握手等操作；
3. 步驟2完成之後，業務層的鏈路正式建立，將SocketChannel從主線程池的Reactor線程的多路複用器上摘除，重新註冊到Sub線程池的線程上，用於處理I/O的讀寫操作.

 

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

總結

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

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

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