一流码、Netty到底是什么
1又官、從HTTP說起
有了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)建一個ServerSocket，監(jiān)聽并綁定一個端口
2叮趴、一系列客戶端來請求這個端口
3割笙、服務(wù)器使用Accept，獲得一個來自客戶端的Socket連接對象
4眯亦、啟動一個新線程處理連接
4.1伤溉、讀Socket，得到字節(jié)流
4.2妻率、解碼協(xié)議乱顾，得到Http請求對象
4.3、處理Http請求宫静，得到一個結(jié)果走净，封裝成一個HttpResponse對象
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ù)器。
2慕淡、NIO
上面是一個傳統(tǒng)處理http的服務(wù)器背伴，但是在高并發(fā)的環(huán)境下，線程數(shù)量會比較多，System?load也會比較高傻寂，于是就有了NIO息尺。
他并不是Java獨(dú)有的概念，NIO代表的一個詞匯叫著IO多路復(fù)用疾掰。它是由操作系統(tǒng)提供的系統(tǒng)調(diào)用搂誉，早期這個操作系統(tǒng)調(diào)用的名字是select，但是性能低下静檬，后來漸漸演化成了Linux下的epoll和Mac里的kqueue炭懊。我們一般就說是epoll，因?yàn)闆]有人拿蘋果電腦作為服務(wù)器使用對外提供服務(wù)拂檩。而Netty就是基于Java?NIO技術(shù)封裝的一套框架侮腹。為什么要封裝，因?yàn)樵腏ava?NIO使用起來沒那么方便稻励，而且還有臭名昭著的bug父阻，Netty把它封裝之后，提供了一個易于操作的使用模式和接口望抽，用戶使用起來也就便捷多了加矛。
說NIO之前先說一下BIO（Blocking?IO）,如何理解這個Blocking呢？
客戶端監(jiān)聽（Listen）時煤篙，Accept是阻塞的斟览，只有新連接來了，Accept才會返回辑奈，主線程才能繼;
讀寫socket時趣惠，Read是阻塞的，只有請求消息來了身害，Read才能返回，子線程才能繼續(xù)處理;
讀寫socket時草戈，Write是阻塞的塌鸯，只有客戶端把消息收了，Write才能返回唐片，子線程才能繼續(xù)讀取下一個請求;
傳統(tǒng)的BIO模式下丙猬，從頭到尾的所有線程都是阻塞的，這些線程就干等著费韭，占用系統(tǒng)的資源茧球，什么事也不干。
那么NIO是怎么做到非阻塞的呢星持。它用的是事件機(jī)制抢埋。它可以用一個線程把Accept，讀寫操作，請求處理的邏輯全干了揪垄。如果什么事都沒得做穷吮，它也不會死循環(huán)，它會將線程休眠起來饥努，直到下一個事件來了再繼續(xù)干活捡鱼，這樣的一個線程稱之為NIO線程。用偽代碼表示：
二酷愧、Reactor線程模型
1驾诈、Reactor單線程模型
一個NIO線程+一個accept線程：
2、Reactor多線程模型
3溶浴、Reactor主從模型
主從Reactor多線程：多個acceptor的NIO線程池用于接受客戶端的連接
Netty可以基于如上三種模型進(jìn)行靈活的配置乍迄。
4、小結(jié)
Netty是建立在NIO基礎(chǔ)之上戳葵，Netty在NIO之上又提供了更高層次的抽象就乓。
在Netty里面，Accept連接可以使用單獨(dú)的線程池去處理拱烁，讀寫操作又是另外的線程池來處理生蚁。
Accept連接和讀寫操作也可以使用同一個線程池來進(jìn)行處理。而請求處理邏輯既可以使用單獨(dú)的線程池進(jìn)行處理戏自，也可以跟放在讀寫線程一塊處理邦投。線程池中的每一個線程都是NIO線程。用戶可以根據(jù)實(shí)際情況進(jìn)行組裝擅笔，構(gòu)造出滿足系統(tǒng)需求的高性能并發(fā)模型志衣。
三、為什么選擇Netty
如果不用netty猛们，使用原生JDK的話念脯，有如下問題：
1、API復(fù)雜
2弯淘、對多線程很熟悉：因?yàn)镹IO涉及到Reactor模式
3绿店、高可用的話：需要出路斷連重連、半包讀寫庐橙、失敗緩存等問題
4假勿、JDK NIO的bug
而Netty來說，他的api簡單态鳖、性能高而且社區(qū)活躍（dubbo转培、rocketmq等都使用了它）
四、什么是TCP 粘包/拆包
1浆竭、現(xiàn)象
先看如下代碼浸须，這個代碼是使用netty在client端重復(fù)寫100次數(shù)據(jù)給server端惨寿，ByteBuf是netty的一個字節(jié)容器，里面存放是的需要發(fā)送的數(shù)據(jù):
從client端讀取到的數(shù)據(jù)為：
從服務(wù)端的控制臺輸出可以看出羽戒，存在三種類型的輸出
一種是正常的字符串輸出缤沦。
一種是多個字符串“粘”在了一起，我們定義這種?ByteBuf?為粘包易稠。
一種是一個字符串被“拆”開缸废，形成一個破碎的包，我們定義這種?ByteBuf?為半包驶社。
2企量、透過現(xiàn)象分析原因
應(yīng)用層面使用了Netty，但是對于操作系統(tǒng)來說亡电，只認(rèn)TCP協(xié)議届巩，盡管我們的應(yīng)用層是按照?ByteBuf?為?單位來發(fā)送數(shù)據(jù)，server按照Bytebuf讀取份乒，但是到了底層操作系統(tǒng)仍然是按照字節(jié)流發(fā)送數(shù)據(jù)恕汇，因此，數(shù)據(jù)到了服務(wù)端或辖，也是按照字節(jié)流的方式讀入瘾英，然后到了?Netty?應(yīng)用層面，重新拼裝成?ByteBuf颂暇，而這里的?ByteBuf?與客戶端按順序發(fā)送的?ByteBuf?可能是不對等的缺谴。因此，我們需要在客戶端根據(jù)自定義協(xié)議來組裝我們應(yīng)用層的數(shù)據(jù)包耳鸯，然后在服務(wù)端根據(jù)我們的應(yīng)用層的協(xié)議來組裝數(shù)據(jù)包湿蛔，這個過程通常在服務(wù)端稱為拆包，而在客戶端稱為粘包县爬。
拆包和粘包是相對的阳啥，一端粘了包，另外一端就需要將粘過的包拆開财喳，發(fā)送端將三個數(shù)據(jù)包粘成兩個?TCP?數(shù)據(jù)包發(fā)送到接收端察迟，接收端就需要根據(jù)應(yīng)用協(xié)議將兩個數(shù)據(jù)包重新組裝成三個數(shù)據(jù)包。
3纲缓、如何解決
在沒有?Netty?的情況下，用戶如果自己需要拆包喊废，基本原理就是不斷從?TCP?緩沖區(qū)中讀取數(shù)據(jù)祝高，每次讀取完都需要判斷是否是一個完整的數(shù)據(jù)包?如果當(dāng)前讀取的數(shù)據(jù)不足以拼接成一個完整的業(yè)務(wù)數(shù)據(jù)包，那就保留該數(shù)據(jù)污筷，繼續(xù)從?TCP?緩沖區(qū)中讀取工闺，直到得到一個完整的數(shù)據(jù)包乍赫。?如果當(dāng)前讀到的數(shù)據(jù)加上已經(jīng)讀取的數(shù)據(jù)足夠拼接成一個數(shù)據(jù)包，那就將已經(jīng)讀取的數(shù)據(jù)拼接上本次讀取的數(shù)據(jù)陆蟆，構(gòu)成一個完整的業(yè)務(wù)數(shù)據(jù)包傳遞到業(yè)務(wù)邏輯雷厂，多余的數(shù)據(jù)仍然保留，以便和下次讀到的數(shù)據(jù)嘗試拼接叠殷。
而在Netty中改鲫，已經(jīng)造好了許多類型的拆包器，我們直接用就好：
選好拆包器后林束，在代碼中client段和server端將拆包器加入到chanelPipeline之中就好了:
如上實(shí)例中：
客戶端：
服務(wù)端：
五像棘、Netty 的零拷貝
1、傳統(tǒng)意義的拷貝
是在發(fā)送數(shù)據(jù)的時候壶冒，傳統(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ū)
2缕题、零拷貝的概念
明顯上面的第二步和第三步是沒有必要的，通過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á)到了零拷貝。
3咸作、Netty中的零拷貝
主要體現(xiàn)在三個方面：
1锨阿、bytebuffer
Netty發(fā)送和接收消息主要使用bytebuffer，bytebuffer使用對外內(nèi)存（DirectMemory）直接進(jìn)行Socket讀寫性宏。
原因：如果使用傳統(tǒng)的堆內(nèi)存進(jìn)行Socket讀寫群井，JVM會將堆內(nèi)存buffer拷貝一份到直接內(nèi)存中然后再寫入socket，多了一次緩沖區(qū)的內(nèi)存拷貝毫胜。DirectMemory中可以直接通過DMA發(fā)送到網(wǎng)卡接口
2书斜、Composite Buffers
傳統(tǒng)的ByteBuffer，如果需要將兩個ByteBuffer中的數(shù)據(jù)組合到一起酵使，我們需要首先創(chuàng)建一個size=size1+size2大小的新的數(shù)組荐吉，然后將兩個數(shù)組中的數(shù)據(jù)拷貝到新的數(shù)組中。但是使用Netty提供的組合ByteBuf口渔，就可以避免這樣的操作样屠，因?yàn)镃ompositeByteBuf并沒有真正將多個Buffer組合起來，而是保存了它們的引用痪欲，從而避免了數(shù)據(jù)的拷貝，實(shí)現(xiàn)了零拷貝攻礼。
3业踢、對于FileChannel.transferTo的使用
Netty中使用了FileChannel的transferTo方法，該方法依賴于操作系統(tǒng)實(shí)現(xiàn)零拷貝礁扮。
六知举、Netty 內(nèi)部執(zhí)行流程
1瞬沦、服務(wù)端：
1、創(chuàng)建ServerBootStrap實(shí)例
2雇锡、設(shè)置并綁定Reactor線程池：EventLoopGroup逛钻，EventLoop就是處理所有注冊到本線程的Selector上面的Channel
3、設(shè)置并綁定服務(wù)端的channel
4锰提、5曙痘、創(chuàng)建處理網(wǎng)絡(luò)事件的ChannelPipeline和handler，網(wǎng)絡(luò)時間以流的形式在其中流轉(zhuǎn)欲账，handler完成多數(shù)的功能定制：比如編解碼?SSl安全認(rèn)證
6屡江、綁定并啟動監(jiān)聽端口
7、當(dāng)輪訓(xùn)到準(zhǔn)備就緒的channel后赛不，由Reactor線程：NioEventLoop執(zhí)行pipline中的方法惩嘉，最終調(diào)度并執(zhí)行channelHandler
2、客戶端
擴(kuò)展閱讀
一個“Hello World”理解JVM運(yùn)行時數(shù)據(jù)區(qū)
來源：https://juejin.im/post/5bf8fbd4f265da617006cab8
