Java必學技術之一，網絡編程之Netty究竟是什麼？

Netty 是由 JBOSS 提供的一個 java 開源框架。Netty 提供異步的、事件驅動的網絡應用程序框架和工具，用以快速開發高性能、高可靠性的網絡服務器和客戶端程序。

也就是說，Netty 是一個基於 NIO 的客戶、服務器端編程框架，使用 Netty 能夠確保你快速和簡單的開發出一個網絡應用，例如實現了某種協議的客戶，服務端應用。Netty 至關簡化和流線化了網絡應用的編程開發過程，例如，TCP 和 UDP 的 socket 服務開發。

"快速"和"簡單"並不用產生維護性或性能上的問題。Netty 是一個吸取了多種協議的實現經驗，這些協議包括 FTP,SMTP,HTTP，各類二進制，文本協議，並通過至關精心設計的項目，最終，Netty 成功的找到了一種方式，在保證易於開發的同時還保證了其應用的性能，穩定性和伸縮性。

Netty 從 4.x 版本開始，須要使用 JDK1.6 及以上版本提供基礎支撐。

在設計上：針對多種傳輸類型的統一接口 - 阻塞和非阻塞；簡單但更強大的線程模型；真正的無鏈接的數據報套接字支持；連接邏輯支持複用；

在性能上：比核心 Java API 更好的吞吐量，較低的延時；資源消耗更少，這個得益於共享池和重用；減小內存拷貝

在健壯性上：消除因爲慢，快，或重載鏈接產生的 OutOfMemoryError；消除常常發如今 NIO 在高速網絡中的應用中的不公平的讀/寫比

在安全上：完整的 SSL / TLS 和 StartTLS 的支持且已獲得大量商業應用的真實驗證,如：Hadoop 項目的 Avro（RPC 框架）、Dubbo、Dubbox 等 RPC 框架。

Netty 的官網是：http://netty.io

有三方提供的中文翻譯 Netty 用戶手冊（官網提供源信息）： http://ifeve.com/netty5-user-guide/

2 Netty 架構

 

 

3 線程模型

 

 

Netty 中支持單線程模型，多線程模型，主從多線程模型。

3.1 單線程模型

在 ServerBootstrap 調用方法 group 的時候，傳遞的參數是同一個線程組，且在構造線程組的時候，構造參數爲 1，這種開發方式，就是一個單線程模型。

我的機開發測試使用。不推薦。

3.2 多線程模型

在 ServerBootstrap 調用方法 group 的時候，傳遞的參數是兩個不一樣的線程組。負責監聽的 acceptor 線程組，線程數爲 1，也就是構造參數爲 1。負責處理客戶端任務的線程組，線程數大於 1，也就是構造參數大於 1。這種開發方式，就是多線程模型。

長鏈接，且客戶端數量較少，鏈接持續時間較長狀況下使用。如：企業內部交流應用。

3.3 主從多線程模型

在 ServerBootstrap 調用方法 group 的時候，傳遞的參數是兩個不一樣的線程組。負責監聽的 acceptor 線程組，線程數大於 1，也就是構造參數大於 1。負責處理客戶端任務的線程組，線程數大於 1，也就是構造參數大於 1。這種開發方式，就是主從多線程模型。

長鏈接，客戶端數量相對較多，鏈接持續時間比較長的狀況下使用。如：對外提供服務的相冊服務器。

4 基礎程序演示

詳見代碼

4.1 入門案例

 

4.2 拆包粘包問題解決

netty 使用 tcp/ip 協議傳輸數據。而 tcp/ip 協議是相似水流同樣的數據傳輸方式。屢次訪問的時候有可能出現數據粘包的問題，解決這種問題的方式以下：

4.2.1 定長數據流

客戶端和服務器，提早協調好，每一個消息長度固定。（如：長度 10）。若是客戶端或服務器寫出的數據不足 10，則使用空白字符補足（如：使用空格）。

 

4.2.2 特殊結束符

客戶端和服務器，協商定義一個特殊的分隔符號，分隔符號長度自定義。如：'#'、'$_$'、

'AA@'。在通信的時候，只要沒有發送分隔符號，則表明一條數據沒有結束。

 

4.2.3 協議

相對最成熟的數據傳遞方式。有服務器的開發者提供一個固定格式的協議標準。客戶端和服務器發送數據和接受數據的時候，都依據協議制定和解析消息。

4.3 序列化對象

JBoss Marshalling 序列化

Java 是面向對象的開發語言。傳遞的數據若是是 Java 對象，應該是最方便且可靠。

 

4.4 定時斷線重連

客戶端斷線重連機制。

客戶端數量多，且須要傳遞的數據量級較大。能夠週期性的發送數據的時候，使用。要求對數據的即時性不高的時候，纔可以使用。

優勢： 可使用數據緩存。不是每條數據進行一次數據交互。能夠定時回收資源，對資源利用率高。相對來講，即時性能夠經過其餘方式保證。如： 120 秒自動斷線。數據變化 1000 次請求服務器一次。300 秒中自動發送不足 1000 次的變化數據。

 

4.5 心跳監測

使用定時發送消息的方式，實現硬件檢測，達到心態檢測的目的。

心跳監測是用於檢測電腦硬件和軟件信息的一種技術。如：CPU 使用率，磁盤使用率，內存使用率，進程狀況，線程狀況等。

4.5.1 sigar

須要下載一個 zip 壓縮包。內部包含若干 sigar 須要的操做系統文件。sigar 插件是經過 JVM 訪問操做系統，讀取計算機硬件的一個插件庫。讀取計算機硬件過程當中，必須由操做系統提供硬件信息。硬件信息是經過操做系統提供的。zip 壓縮包中是 sigar 編寫的操做系統文件，如：windows 中的動態連接庫文件。

解壓須要的操做系統文件，將操做系統文件賦值到${Java_home}/bin 目錄中。

4.6 HTTP 協議處理

使用 Netty 服務開發。實現 HTTP 協議處理邏輯。

5 流數據的傳輸處理

在基於流的傳輸裏好比 TCP/IP，接收到的數據會先被存儲到一個 socket 接收緩衝裏。不幸的是，基於流的傳輸並非一個數據包隊列，而是一個字節隊列。即便你發送了 2 個獨立的數據包，操做系統也不會做爲 2 個消息處理而僅僅是做爲一連串的字節而言。所以這是不能保證你遠程寫入的數據就會準確地讀取。因此一個接收方無論他是客戶端仍是服務端，都應該把接收到的數據整理成一個或者多個更有意思而且可以讓程序的業務邏輯更好理解的數據。

在處理流數據粘包拆包時，可使用下述處理方式：

使用定長數據處理，如：每一個完整請求數據長度爲 8 字節等。（FixedLengthFrameDecoder）使用特殊分隔符的方式處理，如：每一個完整請求數據末尾使用'\0'做爲數據結束標記。

（DelimiterBasedFrameDecoder）

使用自定義協議方式處理，如：http 協議格式等。

使用 POJO 來替代傳遞的流數據，如：每一個完整的請求數據都是一個 RequestMessage 對象，在 Java 語言中，使用 POJO 更符合語種特性，推薦使用。

 

​