徹底理解Netty他炊,這一篇文章就夠了

Netty到底是什么

從HTTP說(shuō)起

有了Netty争剿,你可以實(shí)現(xiàn)自己的HTTP服務(wù)器,F(xiàn)TP服務(wù)器痊末,UDP服務(wù)器蚕苇,RPC服務(wù)器,WebSocket服務(wù)器凿叠,Redis的Proxy服務(wù)器涩笤,MySQL的Proxy服務(wù)器等等。

我們回顧一下傳統(tǒng)的HTTP服務(wù)器的原理

1盒件、創(chuàng)建一個(gè)ServerSocket蹬碧,監(jiān)聽并綁定一個(gè)端口

2、一系列客戶端來(lái)請(qǐng)求這個(gè)端口

3炒刁、服務(wù)器使用Accept锰茉,獲得一個(gè)來(lái)自客戶端的Socket連接對(duì)象

4、啟動(dòng)一個(gè)新線程處理連接

4.1切心、讀Socket飒筑,得到字節(jié)流

4.2、解碼協(xié)議绽昏,得到Http請(qǐng)求對(duì)象

4.3协屡、處理Http請(qǐng)求,得到一個(gè)結(jié)果全谤,封裝成一個(gè)HttpResponse對(duì)象

4.4肤晓、編碼協(xié)議,將結(jié)果序列化字節(jié)流 寫Socket认然,將字節(jié)流發(fā)給客戶端

5补憾、繼續(xù)循環(huán)步驟3

HTTP服務(wù)器之所以稱為HTTP服務(wù)器,是因?yàn)榫幋a解碼協(xié)議是HTTP協(xié)議卷员,如果協(xié)議是Redis協(xié)議盈匾,那它就成了Redis服務(wù)器,如果協(xié)議是WebSocket毕骡,那它就成了WebSocket服務(wù)器削饵,等等。 使用Netty你就可以定制編解碼協(xié)議未巫,實(shí)現(xiàn)自己的特定協(xié)議的服務(wù)器窿撬。

NIO

上面是一個(gè)傳統(tǒng)處理http的服務(wù)器,但是在高并發(fā)的環(huán)境下叙凡,線程數(shù)量會(huì)比較多劈伴,System load也會(huì)比較高,于是就有了NIO握爷。

他并不是Java獨(dú)有的概念跛璧,NIO代表的一個(gè)詞匯叫著IO多路復(fù)用苏遥。它是由操作系統(tǒng)提供的系統(tǒng)調(diào)用,早期這個(gè)操作系統(tǒng)調(diào)用的名字是select赡模,但是性能低下,后來(lái)漸漸演化成了Linux下的epoll和Mac里的kqueue师抄。我們一般就說(shuō)是epoll漓柑,因?yàn)闆](méi)有人拿蘋果電腦作為服務(wù)器使用對(duì)外提供服務(wù)。而Netty就是基于Java NIO技術(shù)封裝的一套框架叨吮。為什么要封裝辆布,因?yàn)樵腏ava NIO使用起來(lái)沒(méi)那么方便,而且還有臭名昭著的bug茶鉴,Netty把它封裝之后锋玲,提供了一個(gè)易于操作的使用模式和接口,用戶使用起來(lái)也就便捷多了涵叮。

說(shuō)NIO之前先說(shuō)一下BIO(Blocking IO),如何理解這個(gè)Blocking呢惭蹂?

客戶端監(jiān)聽(Listen)時(shí),Accept是阻塞的割粮,只有新連接來(lái)了盾碗,Accept才會(huì)返回,主線程才能繼

讀寫socket時(shí)舀瓢,Read是阻塞的廷雅,只有請(qǐng)求消息來(lái)了,Read才能返回京髓,子線程才能繼續(xù)處理

讀寫socket時(shí)航缀,Write是阻塞的,只有客戶端把消息收了堰怨,Write才能返回芥玉,子線程才能繼續(xù)讀取下一個(gè)請(qǐng)求

傳統(tǒng)的BIO模式下,從頭到尾的所有線程都是阻塞的备图,這些線程就干等著飞傀,占用系統(tǒng)的資源,什么事也不干诬烹。

那么NIO是怎么做到非阻塞的呢砸烦。它用的是事件機(jī)制。它可以用一個(gè)線程把Accept绞吁,讀寫操作幢痘,請(qǐng)求處理的邏輯全干了。如果什么事都沒(méi)得做家破,它也不會(huì)死循環(huán)颜说,它會(huì)將線程休眠起來(lái)购岗,直到下一個(gè)事件來(lái)了再繼續(xù)干活,這樣的一個(gè)線程稱之為NIO線程门粪。用偽代碼表示:

while?true?{

????events?=?takeEvents(fds)??//?獲取事件喊积,如果沒(méi)有事件,線程就休眠

????for?event?in?events?{????????if?event.isAcceptable?{

????????????doAccept()?//?新鏈接來(lái)了

????????}?elif?event.isReadable?{

????????????request?=?doRead()?//?讀消息

????????????if?request.isComplete()?{

????????????????doProcess()

????????????}

????????}?elif?event.isWriteable?{

????????????doWrite()??//?寫消息

????????}

????}

}復(fù)制代碼

Reactor線程模型

Reactor單線程模型

一個(gè)NIO線程+一個(gè)accept線程:

Reactor多線程模型

Reactor主從模型

主從Reactor多線程:多個(gè)acceptor的NIO線程池用于接受客戶端的連接

Netty可以基于如上三種模型進(jìn)行靈活的配置玄妈。

總結(jié)

Netty是建立在NIO基礎(chǔ)之上乾吻,Netty在NIO之上又提供了更高層次的抽象。

在Netty里面拟蜻,Accept連接可以使用單獨(dú)的線程池去處理绎签,讀寫操作又是另外的線程池來(lái)處理。

Accept連接和讀寫操作也可以使用同一個(gè)線程池來(lái)進(jìn)行處理酝锅。而請(qǐng)求處理邏輯既可以使用單獨(dú)的線程池進(jìn)行處理诡必,也可以跟放在讀寫線程一塊處理。線程池中的每一個(gè)線程都是NIO線程搔扁。用戶可以根據(jù)實(shí)際情況進(jìn)行組裝爸舒,構(gòu)造出滿足系統(tǒng)需求的高性能并發(fā)模型。

為什么選擇Netty

如果不用netty稿蹲,使用原生JDK的話碳抄,有如下問(wèn)題:

1、API復(fù)雜

2场绿、對(duì)多線程很熟悉:因?yàn)镹IO涉及到Reactor模式

3剖效、高可用的話:需要出路斷連重連、半包讀寫焰盗、失敗緩存等問(wèn)題

4璧尸、JDK NIO的bug

而Netty來(lái)說(shuō),他的api簡(jiǎn)單熬拒、性能高而且社區(qū)活躍(dubbo爷光、rocketmq等都使用了它)

什么是TCP 粘包/拆包

現(xiàn)象

先看如下代碼,這個(gè)代碼是使用netty在client端重復(fù)寫100次數(shù)據(jù)給server端澎粟,ByteBuf是netty的一個(gè)字節(jié)容器蛀序,里面存放是的需要發(fā)送的數(shù)據(jù)

public?class?FirstClientHandler?extends?ChannelInboundHandlerAdapter?{????

????@Override????

????public?void?channelActive(ChannelHandlerContext?ctx)?{???????

????????for?(int?i?=?0;?i?<?1000;?i++)?{????????????

????????????ByteBuf?buffer?=?getByteBuf(ctx);????????????

????????????ctx.channel().writeAndFlush(buffer);????????

????????}????

????}????

????private?ByteBuf?getByteBuf(ChannelHandlerContext?ctx)?{????????

????????byte[]?bytes?=?"你好,我的名字是1234567!".getBytes(Charset.forName("utf-8"));????????

????????ByteBuf?buffer?=?ctx.alloc().buffer();????????

????????buffer.writeBytes(bytes);????????

????????return?buffer;????

????}

}復(fù)制代碼

從client端讀取到的數(shù)據(jù)為:

從服務(wù)端的控制臺(tái)輸出可以看出活烙,存在三種類型的輸出

一種是正常的字符串輸出徐裸。

一種是多個(gè)字符串“粘”在了一起,我們定義這種 ByteBuf 為粘包啸盏。

一種是一個(gè)字符串被“拆”開重贺,形成一個(gè)破碎的包,我們定義這種 ByteBuf 為半包。

透過(guò)現(xiàn)象分析原因

應(yīng)用層面使用了Netty气笙,但是對(duì)于操作系統(tǒng)來(lái)說(shuō)次企,只認(rèn)TCP協(xié)議,盡管我們的應(yīng)用層是按照 ByteBuf 為 單位來(lái)發(fā)送數(shù)據(jù)潜圃,server按照Bytebuf讀取缸棵,但是到了底層操作系統(tǒng)仍然是按照字節(jié)流發(fā)送數(shù)據(jù),因此谭期,數(shù)據(jù)到了服務(wù)端堵第,也是按照字節(jié)流的方式讀入,然后到了 Netty 應(yīng)用層面崇堵,重新拼裝成 ByteBuf,而這里的 ByteBuf 與客戶端按順序發(fā)送的 ByteBuf 可能是不對(duì)等的客燕。因此鸳劳,我們需要在客戶端根據(jù)自定義協(xié)議來(lái)組裝我們應(yīng)用層的數(shù)據(jù)包,然后在服務(wù)端根據(jù)我們的應(yīng)用層的協(xié)議來(lái)組裝數(shù)據(jù)包也搓,這個(gè)過(guò)程通常在服務(wù)端稱為拆包赏廓,而在客戶端稱為粘包。

拆包和粘包是相對(duì)的傍妒,一端粘了包幔摸,另外一端就需要將粘過(guò)的包拆開,發(fā)送端將三個(gè)數(shù)據(jù)包粘成兩個(gè) TCP 數(shù)據(jù)包發(fā)送到接收端颤练,接收端就需要根據(jù)應(yīng)用協(xié)議將兩個(gè)數(shù)據(jù)包重新組裝成三個(gè)數(shù)據(jù)包既忆。

如何解決

在沒(méi)有 Netty 的情況下,用戶如果自己需要拆包嗦玖,基本原理就是不斷從 TCP 緩沖區(qū)中讀取數(shù)據(jù)患雇,每次讀取完都需要判斷是否是一個(gè)完整的數(shù)據(jù)包 如果當(dāng)前讀取的數(shù)據(jù)不足以拼接成一個(gè)完整的業(yè)務(wù)數(shù)據(jù)包,那就保留該數(shù)據(jù)宇挫,繼續(xù)從 TCP 緩沖區(qū)中讀取苛吱,直到得到一個(gè)完整的數(shù)據(jù)包。 如果當(dāng)前讀到的數(shù)據(jù)加上已經(jīng)讀取的數(shù)據(jù)足夠拼接成一個(gè)數(shù)據(jù)包器瘪,那就將已經(jīng)讀取的數(shù)據(jù)拼接上本次讀取的數(shù)據(jù)翠储,構(gòu)成一個(gè)完整的業(yè)務(wù)數(shù)據(jù)包傳遞到業(yè)務(wù)邏輯,多余的數(shù)據(jù)仍然保留橡疼,以便和下次讀到的數(shù)據(jù)嘗試拼接援所。

而在Netty中,已經(jīng)造好了許多類型的拆包器欣除,我們直接用就好:

選好拆包器后任斋,在代碼中client段和server端將拆包器加入到chanelPipeline之中就好了:

如上實(shí)例中:

客戶端:

ch.pipeline().addLast(new?FixedLengthFrameDecoder(31));復(fù)制代碼

服務(wù)端:

ch.pipeline().addLast(new?FixedLengthFrameDecoder(31));復(fù)制代碼

Netty 的零拷貝

傳統(tǒng)意義的拷貝

是在發(fā)送數(shù)據(jù)的時(shí)候,傳統(tǒng)的實(shí)現(xiàn)方式是:

1. `File.read(bytes)`

2. `Socket.send(bytes)`

這種方式需要四次數(shù)據(jù)拷貝和四次上下文切換:

1. 數(shù)據(jù)從磁盤讀取到內(nèi)核的read buffer

2. 數(shù)據(jù)從內(nèi)核緩沖區(qū)拷貝到用戶緩沖區(qū)

3. 數(shù)據(jù)從用戶緩沖區(qū)拷貝到內(nèi)核的socket buffer

4. 數(shù)據(jù)從內(nèi)核的socket buffer拷貝到網(wǎng)卡接口(硬件)的緩沖區(qū)

零拷貝的概念

明顯上面的第二步和第三步是沒(méi)有必要的,通過(guò)java的FileChannel.transferTo方法废酷,可以避免上面兩次多余的拷貝(當(dāng)然這需要底層操作系統(tǒng)支持)

1. 調(diào)用transferTo,數(shù)據(jù)從文件由DMA引擎拷貝到內(nèi)核read buffer

2. 接著DMA從內(nèi)核read buffer將數(shù)據(jù)拷貝到網(wǎng)卡接口buffer

上面的兩次操作都不需要CPU參與瘟檩,所以就達(dá)到了零拷貝。

Netty中的零拷貝

主要體現(xiàn)在三個(gè)方面:

1澈蟆、bytebuffer

Netty發(fā)送和接收消息主要使用bytebuffer墨辛,bytebuffer使用對(duì)外內(nèi)存(DirectMemory)直接進(jìn)行Socket讀寫。

原因:如果使用傳統(tǒng)的堆內(nèi)存進(jìn)行Socket讀寫趴俘,JVM會(huì)將堆內(nèi)存buffer拷貝一份到直接內(nèi)存中然后再寫入socket睹簇,多了一次緩沖區(qū)的內(nèi)存拷貝。DirectMemory中可以直接通過(guò)DMA發(fā)送到網(wǎng)卡接口

2寥闪、Composite Buffers

傳統(tǒng)的ByteBuffer太惠,如果需要將兩個(gè)ByteBuffer中的數(shù)據(jù)組合到一起,我們需要首先創(chuàng)建一個(gè)size=size1+size2大小的新的數(shù)組疲憋,然后將兩個(gè)數(shù)組中的數(shù)據(jù)拷貝到新的數(shù)組中凿渊。但是使用Netty提供的組合ByteBuf,就可以避免這樣的操作缚柳,因?yàn)镃ompositeByteBuf并沒(méi)有真正將多個(gè)Buffer組合起來(lái)埃脏,而是保存了它們的引用,從而避免了數(shù)據(jù)的拷貝秋忙,實(shí)現(xiàn)了零拷貝彩掐。

3、對(duì)于FileChannel.transferTo的使用

Netty中使用了FileChannel的transferTo方法灰追,該方法依賴于操作系統(tǒng)實(shí)現(xiàn)零拷貝堵幽。

Netty 內(nèi)部執(zhí)行流程

服務(wù)端:

1、創(chuàng)建ServerBootStrap實(shí)例

2弹澎、設(shè)置并綁定Reactor線程池:EventLoopGroup谐檀,EventLoop就是處理所有注冊(cè)到本線程的Selector上面的Channel

3、設(shè)置并綁定服務(wù)端的channel

4裁奇、5桐猬、創(chuàng)建處理網(wǎng)絡(luò)事件的ChannelPipeline和handler,網(wǎng)絡(luò)時(shí)間以流的形式在其中流轉(zhuǎn)刽肠,handler完成多數(shù)的功能定制:比如編解碼 SSl安全認(rèn)證

6溃肪、綁定并啟動(dòng)監(jiān)聽端口

7、當(dāng)輪訓(xùn)到準(zhǔn)備就緒的channel后音五,由Reactor線程:NioEventLoop執(zhí)行pipline中的方法惫撰,最終調(diào)度并執(zhí)行channelHandler?

8、說(shuō)到這里順便給大家推薦一個(gè)Java的交流學(xué)習(xí)社區(qū):586446657躺涝,里面不僅可以交流討論厨钻,還有面試經(jīng)驗(yàn)分享以及免費(fèi)的資料下載,包括Spring,MyBatis夯膀,Netty源碼分析诗充,高并發(fā)、高性能诱建、分布式蝴蜓、微服務(wù)架構(gòu)的原理,JVM性能優(yōu)化這些成為架構(gòu)師必備的知識(shí)體系俺猿。相信對(duì)于已經(jīng)工作和遇到技術(shù)瓶頸的碼友茎匠,在這里會(huì)有你需要的內(nèi)容。

客戶端

總結(jié)

以上就是我對(duì)Netty相關(guān)知識(shí)整理押袍,如果有不同的見解诵冒,歡迎討論!

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末谊惭,一起剝皮案震驚了整個(gè)濱河市汽馋,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌午笛,老刑警劉巖惭蟋,帶你破解...
    沈念sama閱讀 212,718評(píng)論 6 492
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件苗桂,死亡現(xiàn)場(chǎng)離奇詭異药磺,居然都是意外死亡,警方通過(guò)查閱死者的電腦和手機(jī)煤伟,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,683評(píng)論 3 385
  • 文/潘曉璐 我一進(jìn)店門癌佩,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái),“玉大人便锨,你說(shuō)我怎么就攤上這事围辙。” “怎么了放案?”我有些...
    開封第一講書人閱讀 158,207評(píng)論 0 348
  • 文/不壞的土叔 我叫張陵姚建,是天一觀的道長(zhǎng)。 經(jīng)常有香客問(wèn)我吱殉,道長(zhǎng)掸冤,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 56,755評(píng)論 1 284
  • 正文 為了忘掉前任友雳,我火速辦了婚禮稿湿,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘押赊。我一直安慰自己饺藤,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 65,862評(píng)論 6 386
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著涕俗,像睡著了一般罗丰。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上咽袜,一...
    開封第一講書人閱讀 50,050評(píng)論 1 291
  • 那天丸卷,我揣著相機(jī)與錄音,去河邊找鬼询刹。 笑死谜嫉,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的凹联。 我是一名探鬼主播沐兰,決...
    沈念sama閱讀 39,136評(píng)論 3 410
  • 文/蒼蘭香墨 我猛地睜開眼,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼蔽挠!你這毒婦竟也來(lái)了住闯?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 37,882評(píng)論 0 268
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤澳淑,失蹤者是張志新(化名)和其女友劉穎比原,沒(méi)想到半個(gè)月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體杠巡,經(jīng)...
    沈念sama閱讀 44,330評(píng)論 1 303
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡量窘,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 36,651評(píng)論 2 327
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了氢拥。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片蚌铜。...
    茶點(diǎn)故事閱讀 38,789評(píng)論 1 341
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖嫩海,靈堂內(nèi)的尸體忽然破棺而出冬殃,到底是詐尸還是另有隱情,我是刑警寧澤叁怪,帶...
    沈念sama閱讀 34,477評(píng)論 4 333
  • 正文 年R本政府宣布审葬,位于F島的核電站,受9級(jí)特大地震影響奕谭,放射性物質(zhì)發(fā)生泄漏涣觉。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 40,135評(píng)論 3 317
  • 文/蒙蒙 一展箱、第九天 我趴在偏房一處隱蔽的房頂上張望旨枯。 院中可真熱鬧,春花似錦混驰、人聲如沸攀隔。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,864評(píng)論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)昆汹。三九已至明刷,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間满粗,已是汗流浹背辈末。 一陣腳步聲響...
    開封第一講書人閱讀 32,099評(píng)論 1 267
  • 我被黑心中介騙來(lái)泰國(guó)打工, 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留映皆,地道東北人挤聘。 一個(gè)月前我還...
    沈念sama閱讀 46,598評(píng)論 2 362
  • 正文 我出身青樓,卻偏偏與公主長(zhǎng)得像捅彻,于是被迫代替她去往敵國(guó)和親组去。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 43,697評(píng)論 2 351

推薦閱讀更多精彩內(nèi)容

  • 1步淹、Netty基礎(chǔ)入門 Netty是由JBOSS提供的一個(gè)java開源框架从隆。Netty提供異步的、事件驅(qū)動(dòng)的網(wǎng)絡(luò)應(yīng)...
    我是嘻哈大哥閱讀 4,689評(píng)論 0 31
  • 作者:李林鋒 原文:http://www.infoq.com/cn/articles/netty-high-per...
    楊鑫科閱讀 3,969評(píng)論 0 64
  • 轉(zhuǎn)載自:http://www.cnblogs.com/rainy-shurun/p/5213086.html Ne...
    達(dá)微閱讀 2,511評(píng)論 0 14
  • 前奏 https://tech.meituan.com/2016/11/04/nio.html 綜述 netty通...
    jiangmo閱讀 5,846評(píng)論 0 13
  • 在寫這篇文章之前缭裆,我沒(méi)有多少寫文的經(jīng)驗(yàn)键闺,不知道會(huì)寫成什么樣,也不知道能不能把自己的想法完全表達(dá)出來(lái)澈驼,不過(guò)思...
    周舞閱讀 380評(píng)論 4 5