徹底理解分散式Netty,這一篇文章就夠了!
一、Netty到底是什麼
1、從HTTP說起
有了Netty,你可以實現自己的HTTP伺服器、FTP伺服器、UDP伺服器、RPC伺服器、WebSocket伺服器、Redis的Proxy伺服器、MySQL的Proxy伺服器等等。
我們回顧一下傳統的HTTP伺服器的原理:
- 建立一個ServerSocket,監聽並繫結一個埠
- 一系列客戶端來請求這個埠
- 伺服器使用Accept,獲得一個來自客戶端的Socket連線物件
- 啟動一個新執行緒處理連線
- 讀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的話,有如下問題:
- API複雜
- 對多執行緒很熟悉:因為NIO涉及到Reactor模式
- 高可用的話:需要出路斷連重連、半包讀寫、失敗快取等問題
- JDK NIO的bug
而Netty來說,他的api簡單、效能高而且社群活躍(dubbo、rocketmq等都使用了它)
四、什麼是TCP 粘包/拆包
1、現象
先看如下程式碼,這個程式碼是使用netty在client端重複寫100次資料給server端,ByteBuf是netty的一個位元組容器,裡面存放是的需要傳送的資料:
從client端讀取到的資料為:
從服務端的控制檯輸出可以看出,存在三種類型的輸出
- 一種是正常的字串輸出。
- 一種是多個字串“粘”在了一起,我們定義這種 ByteBuf 為粘包。
- 一種是一個字串被“拆”開,形成一個破碎的包,我們定義這種 ByteBuf 為半包。
2、透過現象分析原因
應用層面使用了Netty,但是對於作業系統來說,只認TCP協議,儘管我們的應用層是按照 ByteBuf 為單位來發送資料,server按照Bytebuf讀取,但是到了底層作業系統仍然是按照位元組流傳送資料,因此,資料到了服務端,也是按照位元組流的方式讀入,然後到了 Netty 應用層面,重新拼裝成 ByteBuf,而這裡的 ByteBuf 與客戶端按順序傳送的 ByteBuf 可能是不對等的。因此,我們需要在客戶端根據自定義協議來組裝我們應用層的資料包,然後在服務端根據我們的應用層的協議來組裝資料包,這個過程通常在服務端稱為拆包,而在客戶端稱為粘包。
拆包和粘包是相對的,一端粘了包,另外一端就需要將粘過的包拆開,傳送端將三個資料包粘成兩個 TCP 資料包傳送到接收端,接收端就需要根據應用協議將兩個資料包重新組裝成三個資料包。
3、如何解決
在沒有Netty的情況下,使用者如果自己需要拆包,基本原理就是不斷從 TCP 緩衝區中讀取資料,每次讀取完都需要判斷是否是一個完整的資料包 如果當前讀取的資料不足以拼接成一個完整的業務資料包,那就保留該資料,繼續從 TCP 緩衝區中讀取,直到得到一個完整的資料包。如果當前讀到的資料加上已經讀取的資料足夠拼接成一個數據包,那就將已經讀取的資料拼接上本次讀取的資料,構成一個完整的業務資料包傳遞到業務邏輯,多餘的資料仍然保留,以便和下次讀到的資料嘗試拼接。
而在Netty中,已經造好了許多型別的拆包器,我們直接用就好:
選好拆包器後,在程式碼中client段和server端將拆包器加入到chanelPipeline之中就好了:
如上例項中:
客戶端:
服務端:
五、Netty 的零拷貝
1、傳統意義的拷貝
是在傳送資料的時候,傳統的實現方式是:
File.read(bytes)
Socket.send(bytes)
這種方式需要四次資料拷貝和四次上下文切換:
- 資料從磁碟讀取到核心的read buffer
- 資料從核心緩衝區拷貝到使用者緩衝區
- 資料從使用者緩衝區拷貝到核心的socket buffer
- 資料從核心的socket buffer拷貝到網絡卡介面(硬體)的緩衝區
2、零拷貝的概念
明顯上面的第二步和第三步是沒有必要的,通過java的FileChannel.transferTo方法,可以避免上面兩次多餘的拷貝(當然這需要底層作業系統支援)
- 呼叫transferTo,資料從檔案由DMA引擎拷貝到核心read buffer
- 接著DMA從核心read buffer將資料拷貝到網絡卡介面buffer
上面的兩次操作都不需要CPU參與,所以就達到了零拷貝。
- 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、服務端:
- 建立ServerBootStrap例項
- 設定並繫結Reactor執行緒池:EventLoopGroup,EventLoop就是處理所有註冊到本執行緒的Selector上面的Channel
- 設定並繫結服務端的channel
- 建立處理網路事件的ChannelPipeline和handler,網路時間以流的形式在其中流轉,handler完成多數的功能定製:比如編解碼
SSl安全認證 - 繫結並啟動監聽埠
- 當輪訓到準備就緒的channel後,由Reactor執行緒:NioEventLoop執行pipline中的方法,最終排程並執行channelHandler
2、客戶端