徹底理解Netty，這一篇文章就夠了

 有了Netty，你可以實現自己的HTTP伺服器，FTP伺服器，UDP伺服器，RPC伺服器，WebSocket伺服器，Redis的Proxy伺服器，MySQL的Proxy伺服器等等。  

我們回顧一下傳統的HTTP伺服器的原理 

 1、建立一個ServerSocket，監聽並繫結一個埠

 2、一系列客戶端來請求這個埠

 3、伺服器使用Accept，獲得一個來自客戶端的Socket連線物件 

4、啟動一個新執行緒處理連線 

    4.1、讀Socket，得到位元組流

    4.2、解碼協議，得到Http請求物件 

    4.3、處理Http請求，得到一個結果，封裝成一個HttpResponse物件 

    4.4、編碼協議，將結果序列化位元組流 寫Socket，將位元組流發給客戶端 

5、繼續迴圈步驟3

HTTP伺服器之所以稱為HTTP伺服器，是因為編碼解碼協議是HTTP協議，如果協議是Redis協議，那它就成了Redis伺服器，如果協議是WebSocket，那它就成了WebSocket伺服器，等等。 使用Netty你就可以定製編解碼協議，實現自己的特定協議的伺服器。

NIO

上面是一個傳統處理http的伺服器，但是在高併發的環境下，執行緒數量會比較多，System load也會比較高，於是就有了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()  // 寫訊息
        }
    }
}複製程式碼

Reactor執行緒模型

Reactor單執行緒模型

一個NIO執行緒+一個accept執行緒：

Reactor多執行緒模型

Reactor主從模型

Netty可以基於如上三種模型進行靈活的配置。

總結

 為什麼選擇Netty 

如果不用netty，使用原生JDK的話，有如下問題：

而Netty來說，他的api簡單、效能高而且社群活躍（dubbo、rocketmq等都使用了它）

什麼是TCP 粘包/拆包 

現象

先看如下程式碼，這個程式碼是使用netty在client端重複寫100次資料給server端，ByteBuf是netty的一個位元組容器，裡面存放是的需要傳送的資料

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;    
    }
}複製程式碼

從client端讀取到的資料為：

從服務端的控制檯輸出可以看出，存在三種型別的輸出

1. 一種是正常的字串輸出。
2. 一種是多個字串“粘”在了一起，我們定義這種 ByteBuf 為粘包。
3. 一種是一個字串被“拆”開，形成一個破碎的包，我們定義這種 ByteBuf 為半包。

透過現象分析原因

應用層面使用了Netty，但是對於作業系統來說，只認TCP協議，儘管我們的應用層是按照 ByteBuf 為 單位來傳送資料，server按照Bytebuf讀取，但是到了底層作業系統仍然是按照位元組流傳送資料，因此，資料到了服務端，也是按照位元組流的方式讀入，然後到了 Netty 應用層面，重新拼裝成 ByteBuf，而這裡的 ByteBuf 與客戶端按順序傳送的 ByteBuf 可能是不對等的。因此，我們需要在客戶端根據自定義協議來組裝我們應用層的資料包，然後在服務端根據我們的應用層的協議來組裝資料包，這個過程通常在服務端稱為拆包，而在客戶端稱為粘包。

如何解決

在沒有 Netty 的情況下，使用者如果自己需要拆包，基本原理就是不斷從 TCP 緩衝區中讀取資料，每次讀取完都需要判斷是否是一個完整的資料包 如果當前讀取的資料不足以拼接成一個完整的業務資料包，那就保留該資料，繼續從 TCP 緩衝區中讀取，直到得到一個完整的資料包。 如果當前讀到的資料加上已經讀取的資料足夠拼接成一個資料包，那就將已經讀取的資料拼接上本次讀取的資料，構成一個完整的業務資料包傳遞到業務邏輯，多餘的資料仍然保留，以便和下次讀到的資料嘗試拼接。 

而在Netty中，已經造好了許多型別的拆包器，我們直接用就好：

選好拆包器後，在程式碼中client段和server端將拆包器加入到chanelPipeline之中就好了:

如上例項中：

客戶端：

ch.pipeline().addLast(new FixedLengthFrameDecoder(31));複製程式碼

服務端：

ch.pipeline().addLast(new FixedLengthFrameDecoder(31));複製程式碼