TCP粘包/拆包 ByteBuf和channel 若是沒有Netty？ 傳統的多線程服務器，這個也是Apache處理請求的模式

通俗地講，Netty 能作什麼？ - 知乎 https://www.zhihu.com/question/24322387

謝邀.netty是一套在java NIO的基礎上封裝的便於用戶開發網絡應用程序的api. 應用場景不少,諸如阿里的消息隊列(RocketMQ),分佈式rpc(Dubbo)通訊層都使用到了netty(dubbo能夠用服務發現自由選擇通訊層). 主要優勢我的總結以下:

1. netty是非阻塞事件驅動框架, 並結合線程組(group)的概念,能夠很好的支持高併發,慢鏈接的場景。

2. 編程接口很是容易,而且也較好的解決了TCP粘包/拆包的問題.netty提供了本身的ByteBuf和channel,相比於jdk的ByteBuffer和channel來講更簡便靈活操做, 並提供了pipeline的概念,並針對每一個contextHandler均可以由用戶定義, 方便直接.

3. 有一些web框架已經開始直接使用netty作爲底層通訊服務,諸如play. 這樣play就不用依賴於容器去進行部署,在沒有nginx作反向代理的狀況下也能支持高併發.編解碼器能夠隨意擴展,今天是個web，明天就能夠是一個ftp或email服務器,我的以爲比較靈活。

發佈於 2014-07-01

若是沒有Netty？

遠古：

java.net + java.io

近代：

java.nio

其餘：

Mina，Grizzly

Netty是什麼？

1）本質：JBoss作的一個Jar包

2）目的：快速開發高性能、高可靠性的網絡服務器和客戶端程序

3）優勢：提供異步的、事件驅動的網絡應用程序框架和工具

通俗的說：一個好使的處理Socket的東東

若是沒有Netty？

遠古：

java.net + java.io

近代：

java.nio

其餘：

Mina，Grizzly

與Mina相比有什麼優點？

一、都是Trustin Lee的做品，Netty更晚；

二、Mina將內核和一些特性的聯繫過於緊密，使得用戶在不須要這些特性的時候沒法脫離，相比下性能會有所降低，Netty解決了這個設計問題；

三、Netty的文檔更清晰，不少Mina的特性在Netty裏都有；

四、Netty更新週期更短，新版本的發佈比較快；

五、它們的架構差異不大，Mina靠apache生存，而Netty靠jboss，和jboss的結合度很是高，Netty有對google protocal buf的支持，有更完整的ioc容器支持(spring,guice,jbossmc和osgi)；

六、Netty比Mina使用起來更簡單，Netty裏你能夠自定義的處理upstream events 或/和 downstream events，可使用decoder和encoder來解碼和編碼發送內容；

七、Netty和Mina在處理UDP時有一些不一樣，Netty將UDP無鏈接的特性暴露出來；而Mina對UDP進行了高級層次的抽象，能夠把UDP當成"面向鏈接"的協議，而要Netty作到這一點比較困難。

-----------------------------------------------------------------------------------------------------------------------------------------

Netty的特性

1）設計

統一的API，適用於不一樣的協議（阻塞和非阻塞）

基於靈活、可擴展的事件驅動模型

高度可定製的線程模型

可靠的無鏈接數據Socket支持（UDP）

2）性能

更好的吞吐量，低延遲

更省資源

儘可能減小沒必要要的內存拷貝

3）安全

完整的SSL/TLS和STARTTLS的支持

能在Applet與Android的限制環境運行良好

4）健壯性

再也不因過快、過慢或超負載鏈接致使OutOfMemoryError

再也不有在高速網絡環境下NIO讀寫頻率不一致的問題

5）易用

完善的JavaDoc，用戶指南和樣例

簡潔簡單

僅信賴於JDK1.5

-------------------------------------------------------------------------------------------------------------------------------------------

Netty 在哪些行業獲得了應用？

• 互聯網行業：隨着網站規模的不斷擴大，系統併發訪問量也愈來愈高，傳統基於 Tomcat 等 Web 容器的垂直架構已經沒法知足需求，須要拆分應用進行服務化，以提升開發和維護效率。從組網狀況看，垂直的架構拆分以後，系統採用分佈式部署，各個節點之間須要遠程服務調用，高性能的 RPC 框架必不可少，Netty 做爲異步高性能的通訊框架，每每做爲基礎通訊組件被這些 RPC 框架使用。

　　典型的應用有：阿里分佈式服務框架 Dubbo 的 RPC 框架使用 Dubbo 協議進行節點間通訊，Dubbo 協議默認使用 Netty 做爲基礎通訊組件，用於實現各進程節點之間的內部通訊。它的架構圖以下：

其中，服務提供者和服務消費者之間，服務提供者、服務消費者和性能統計節點之間使用 Netty 進行異步/同步通訊。

　　除了 Dubbo 以外，淘寶的消息中間件 RocketMQ 的消息生產者和消息消費者之間，也採用 Netty 進行高性能、異步通訊。

　　除了阿里系和淘寶系以外，不少其它的大型互聯網公司或者電商內部也已經大量使用 Netty 構建高性能、分佈式的網絡服務器。

• 遊戲行業：不管是手遊服務端、仍是大型的網絡遊戲，Java 語言獲得了愈來愈普遍的應用。Netty 做爲高性能的基礎通訊組件，它自己提供了 TCP/UDP 和 HTTP 協議棧，很是方便定製和開發私有協議棧。帳號登錄服務器、地圖服務器之間能夠方便的經過 Netty 進行高性能的通訊，架構示意圖以下：

　　圖1-2 Netty 在遊戲服務器架構中的應用

• 大數據領域：經典的 Hadoop 的高性能通訊和序列化組件 Avro 的 RPC 框架，默認採用 Netty 進行跨節點通訊，它的 Netty Service 基於 Netty 框架二次封裝實現。

　　大數據計算每每採用多個計算節點和一個/N個彙總節點進行分佈式部署，各節點之間存在海量的數據交換。因爲 Netty 的綜合性能是目前各個成熟 NIO 框架中最高的，所以，每每會被選中用做大數據各節點間的通訊。

• 企業軟件：企業和 IT 集成須要 ESB，Netty 對多協議支持、私有協議定製的簡潔性和高性能是 ESB RPC 框架的首選通訊組件。事實上，不少企業總線廠商會選擇 Netty 做爲基礎通訊組件，用於企業的 IT 集成。

• 通訊行業：Netty 的異步高性能、高可靠性和高成熟度的優勢，使它在通訊行業獲得了大量的應用。

 

做者：知乎用戶
連接：https://www.zhihu.com/question/24322387/answer/282001188
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

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

若是你想知道Nginx是怎麼寫出來的，若是你想知道Tomcat和Jetty是如何實現的，若是你也想實現一個簡單的Redis服務器，那都應該好好理解一下Netty，它們高性能的原理都是相似的。

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

1. 建立一個ServerSocket，監聽並綁定一個端口
2. 一系列客戶端來請求這個端口
3. 服務器使用Accept，得到一個來自客戶端的Socket鏈接對象
4. 啓動一個新線程處理鏈接
1. 讀Socket，獲得字節流
2. 解碼協議，獲得Http請求對象
3. 處理Http請求，獲得一個結果，封裝成一個HttpResponse對象
4. 編碼協議，將結果序列化字節流
5. 寫Socket，將字節流發給客戶端
5. 繼續循環步驟3

HTTP服務器之因此稱爲HTTP服務器，是由於編碼解碼協議是HTTP協議，若是協議是Redis協議，那它就成了Redis服務器，若是協議是WebSocket，那它就成了WebSocket服務器，等等。

使用Netty你就能夠定製編解碼協議，實現本身的特定協議的服務器。

上面咱們說的是一個傳統的多線程服務器，這個也是Apache處理請求的模式。在高併發環境下，線程數量可能會建立太多，操做系統的任務調度壓力大，系統負載也會比較高。那怎麼辦呢？

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

那NIO到底是什麼東西呢？

NIO的全稱是NoneBlocking IO，非阻塞IO，區別與BIO，BIO的全稱是Blocking IO，阻塞IO。那這個阻塞是什麼意思呢？

1. Accept是阻塞的，只有新鏈接來了，Accept纔會返回，主線程才能繼
2. Read是阻塞的，只有請求消息來了，Read才能返回，子線程才能繼續處理
3. Write是阻塞的，只有客戶端把消息收了，Write才能返回，子線程才能繼續讀取下一個請求

因此傳統的多線程服務器是BlockingIO模式的，從頭至尾全部的線程都是阻塞的。這些線程就乾等在哪裏，佔用了操做系統的調度資源，什麼事也不幹，是浪費。

那麼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() // 寫消息 } } } 

NIO的流程大體就是上面的僞代碼描述的過程，跟實際真實的代碼有較多差別，不過對於初學者，這樣理解也是足夠了。

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

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

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

Netty提供了內置的經常使用編解碼器，包括行編解碼器［一行一個請求］，前綴長度編解碼器［前N個字節定義請求的字節長度］，可重放解碼器［記錄半包消息的狀態］，HTTP編解碼器，WebSocket消息編解碼器等等

Netty提供了一些列生命週期回調接口，當一個完整的請求到達時，當一個鏈接關閉時，當一個鏈接創建時，用戶都會收到回調事件，而後進行邏輯處理。

Netty能夠同時管理多個端口，可使用NIO客戶端模型，這些對於RPC服務是頗有必要的。

Netty除了能夠處理TCP Socket以外，還能夠處理UDP Socket。

在消息讀寫過程當中，須要大量使用ByteBuffer，Netty對ByteBuffer在性能和使用的便捷性上都進行了優化和抽象。

總之，Netty是Java程序員進階的必備神奇。若是你知其然，還想知其因此然，必定要好好研究下Netty。若是你以爲Java枯燥無謂，Netty則是從新開啓你對Java興趣大門的鑰匙。

附上本人基於Netty作的兩個開源項目

錢文品：大廚小鮮——基於Netty本身動手實現RPC框架​zhuanlan.zhihu.com 錢文品：大廚小鮮——基於Netty本身動手實現Web框架​zhuanlan.zhihu.com