面試官：介紹一下自己對 Netty 的認(rèn)識吧

普通人：

Netty是一個高性能NIO框架，它可以用來解決高并發(fā)網(wǎng)絡(luò)通信問題。

在很多中間件的網(wǎng)絡(luò)通信層都是采用Netty，不過我對Netty接觸得比較少，了解不是很多。

高手：

好的，我用三點來簡單的介紹下Netty

• 第一：Netty 是一個?基于 NIO?模型的高性能網(wǎng)絡(luò)通信框架，其實可以認(rèn)為它是對NIO網(wǎng)絡(luò)模。型的封裝，提供了簡單易用的API，我們可以利用這些封裝好的API快速開發(fā)自己的網(wǎng)絡(luò)程序。

• 第二：Netty在NIO的基礎(chǔ)上做了很多優(yōu)化，比如零拷貝機(jī)制、高性能無鎖隊列、內(nèi)存池等，因此性能會比NIO更高。

• 第三：Netty可以支持多種通信協(xié)議，如Http、WebSocket等，并且針對數(shù)據(jù)通信的拆包黏包問題，Netty內(nèi)置了拆包策略。

面試官：那你在說說為什么要用 Netty ？

高手：Nety相比于直接使用 JDK 自帶的 NIO 相關(guān)的 API 來說更加易用。同時，它還具有以下特點：

1、統(tǒng)一的 API，支持多種傳輸類型，如阻塞、非阻塞， 以及epoll、poll等模型。

2、我們可以使用非常少的代碼來實現(xiàn)，多線程Reactor模型以及主從多線程Reactor模型

3、自帶編解碼器解決 TCP 粘包/拆包問題。

4、自帶各種協(xié)議棧。

5、比直接使用 Java 庫中的NIO ?API 有更高的吞吐量、更低的延遲、更低的資源消耗和更少的內(nèi)存復(fù)制。

6、安全性不錯，有完整的 SSL/TLS 以及 StartTLS 支持。

7、社區(qū)活躍成熟穩(wěn)定，經(jīng)歷了大型項目的使用和考驗，而且很多開源項目都使用到了 Netty， 比如我們經(jīng)常接觸的 Dubbo、RocketMQ 等等。

面試官：那你在通俗地說一下 Netty 可以做什么事情？

高手：

我們之所以要用Netty，核心點還是在于解決服務(wù)器如何承載更多的用戶同時訪問的問題。

傳統(tǒng)的BIO模型，由于阻塞的特性，使得在高并發(fā)場景中，很難獲得更高的吞吐量。而后來基于NIO的多路復(fù)用模型雖然在阻塞方面進(jìn)行了優(yōu)化，但是它的API使用比較復(fù)雜，對于初學(xué)者來說使用不是很友好。而Netty是基于NIO的封裝，提供了成熟且簡單易用的API，降低了使用成本和學(xué)習(xí)成本。

本質(zhì)上來說，Netty和NIO所扮演的角色是相同的，都是為了提升服務(wù)端的吞吐量，讓用戶獲得更好的產(chǎn)品體驗。

另外，Netty這個中間件經(jīng)過很多年的驗證，在目前主流的中間件如Zookeeper、Dubbo、RocketMQ中都有應(yīng)用。

面試官：Netty 核心組件了解嗎？分別有什么作用？

高手：Netty由三層結(jié)構(gòu)構(gòu)成：網(wǎng)絡(luò)通信層、事件調(diào)度器與服務(wù)編排層

在網(wǎng)絡(luò)通信層有三個核心組件：Bootstrap、ServerBootStrap、Channel

• Bootstrap負(fù)責(zé)客戶端啟動并用來鏈接遠(yuǎn)程netty server

• ServerBootStrap負(fù)責(zé)服務(wù)端監(jiān)聽，用來監(jiān)聽指定端口，

• Channel是負(fù)責(zé)網(wǎng)絡(luò)通信的載體

事件調(diào)度器有兩個核心組件：EventLoopGroup與EventLoop

• EventLoopGroup本質(zhì)上是一個線程池，主要負(fù)責(zé)接收I/O請求，并分配線程執(zhí)行處理請求。

• EventLoop。相當(dāng)于線程池中的線程

在服務(wù)編排層有三個核心組件ChannelPipeline、ChannelHandler、ChannelHandlerContext

• ChannelPipeline負(fù)責(zé)將多個Channelhandler鏈接在一起

• ChannelHandler針對IO數(shù)據(jù)的處理器，數(shù)據(jù)接收后，通過指定的Handler進(jìn)行處理。

• ChannelHandlerContext用來保存ChannelHandler的上下文信息

面試官：那，在說說Netty 有幾種線程模型吧？

高手Netty提供了三種Reactor模型的支持

• 單線程單Reactor模型

• 多線程單Reactor模型

• 多線程多Reactor模型

面試官：這幾種線程模型如何實現(xiàn)？

高手：Reactor模型有三個重要的組件：

• Reactor ：將I/O事件發(fā)派給對應(yīng)的Handler

• Acceptor ：處理客戶端連接請求

• Handlers ：執(zhí)行非阻塞讀/寫

這是最基本的單Reactor單線程模型?

我們來看這張圖：

?

多線程單Reactor模型

單線程Reactor這種實現(xiàn)方式有存在著缺點，從實例代碼中可以看出，handler的執(zhí)行是串行的，如果其中一個handler處理線程阻塞將導(dǎo)致其他的業(yè)務(wù)處理阻塞。由于handler和reactor在同一個線程中的執(zhí)行，這也將導(dǎo)致無法接收新的請求。因此有人做了一個實驗：

• 在Reactor代碼的DispatchHandler的run方法中，增加一個Thread.sleep()。

• 打開多個客戶端窗口連接到Reactor Server端，其中一個窗口發(fā)送一個信息后被阻塞，另外一個窗口再發(fā)信息時由于前面的請求阻塞導(dǎo)致后續(xù)請求無法被處理。

為了解決這種問題，有人提出使用多線程的方式來處理業(yè)務(wù)，也就是在業(yè)務(wù)處理的地方加入線程池異步處理，將reactor和handler在不同的線程來執(zhí)行，這就是多線程單Reactor模型

多線程多Reactor模型

在多線程單Reactor模型中，所有的I/O操作是由一個Reactor來完成，而Reactor運行在單個線程中，它需要處理包括Accept()/read()/write/connect操作，對于小容量的場景，影響不大。但是對于高負(fù)載、大并發(fā)或大數(shù)據(jù)量的應(yīng)用場景時，容易成為瓶頸，主要原因如下：

• 一個NIO線程同時處理成百上千的鏈路，性能上無法支撐，即便NIO線程的CPU負(fù)荷達(dá)到100%，也無法滿足海量消息的讀取和發(fā)送；

• 當(dāng)NIO線程負(fù)載過重之后，處理速度將變慢，這會導(dǎo)致大量客戶端連接超時，超時之后往往會進(jìn)行重發(fā)，這更加重了NIO線程的負(fù)載，最終會導(dǎo)致大量消息積壓和處理超時，成為系統(tǒng)的性能瓶頸；

所以，我們還可以更進(jìn)一步優(yōu)化，引入多Reactor多線程模式：

• Main Reactor，負(fù)責(zé)接收客戶端的連接請求，然后把接收到的請求傳遞給SubReactor（其中subReactor可以有多個），具體的業(yè)務(wù)IO處理由SubReactor完成。

• Acceptor，請求接收者，在實踐時其職責(zé)類似服務(wù)器，并不真正負(fù)責(zé)連接請求的建立，而只將其請求委托 Main Reactor 線程池來實現(xiàn)，起到一個轉(zhuǎn)發(fā)的作用。

• Main Reactor，主 Reactor 線程組，主要負(fù)責(zé)連接事件，并將IO讀寫請求轉(zhuǎn)發(fā)到 SubReactor 線程池。

• Sub Reactor，Main Reactor 通常監(jiān)聽客戶端連接后會將通道的讀寫轉(zhuǎn)發(fā)到 Sub Reactor 線程池中一個線程(負(fù)載均衡)，負(fù)責(zé)數(shù)據(jù)的讀寫。在 NIO 中 通常注冊通道的讀(OP_READ)、寫事件(OP_WRITE)。

?喜歡的朋友一鍵三連，加個關(guān)注不過分吧！