關於Netty咱們都須要知道什麼

請戳GitHub原文: https://github.com/wangzhiwub...

其餘文章推薦：

大數據成神之路系列：
Java高級特性加強-集合
Java高級特性加強-多線程
Java高級特性加強-Synchronized
Java高級特性加強-volatile
Java高級特性加強-併發集合框架
Java高級特性加強-分佈式
Java高級特性加強-Zookeeper
Java高級特性加強-JVM
Java高級特性加強-NIO

1.BIO、NIO和AIO的區別？

• BIO：一個鏈接一個線程，客戶端有鏈接請求時服務器端就須要啓動一個線程進行處理。線程開銷大。
• 僞異步IO：將請求鏈接放入線程池，一對多，但線程仍是很寶貴的資源。
• NIO：一個請求一個線程，但客戶端發送的鏈接請求都會註冊到多路複用器上，多路複用器輪詢到鏈接有I/O請求時才啓動一個線程進行處理。
• AIO：一個有效請求一個線程，客戶端的I/O請求都是由OS先完成了再通知服務器應用去啓動線程進行處理，
• BIO是面向流的，NIO是面向緩衝區的；BIO的各類流是阻塞的。而NIO是非阻塞的；BIO的Stream是單向的，而NIO的channel是雙向的。
• NIO的特色：事件驅動模型、單線程處理多任務、非阻塞I/O，I/O讀寫再也不阻塞，而是返回0、基於block的傳輸比基於流的傳輸更高效、更高級的IO函數zero-copy、IO多路複用大大提升了Java網絡應用的可伸縮性和實用性。基於Reactor線程模型。
• 在Reactor模式中，事件分發器等待某個事件或者可應用或個操做的狀態發生，事件分發器就把這個事件傳給事先註冊的事件處理函數或者回調函數，由後者來作實際的讀寫操做。如在Reactor中實現讀：註冊讀就緒事件和相應的事件處理器、事件分發器等待事件、事件到來，激活分發器，分發器調用事件對應的處理器、事件處理器完成實際的讀操做，處理讀到的數據，註冊新的事件，而後返還控制權。

2.NIO的組成？

Buffer：與Channel進行交互，數據是從Channel讀入緩衝區，從緩衝區寫入Channel中的

flip方法 ： 反轉此緩衝區，將position給limit，而後將position置爲0，其實就是切換讀寫模式
clear方法 ：清除此緩衝區，將position置爲0，把capacity的值給limit。
rewind方法 ： 重繞此緩衝區，將position置爲0
DirectByteBuffer可減小一次系統空間到用戶空間的拷貝。但Buffer建立和銷燬的成本更高，不可控，一般會用內存池來提升性能。直接緩衝區主要分配給那些易受基礎系統的本機I/O 操做影響的大型、持久的緩衝區。若是數據量比較小的中小應用狀況下，能夠考慮使用heapBuffer，由JVM進行管理。

Channel：表示 IO 源與目標打開的鏈接，是雙向的，但不能直接訪問數據，只能與Buffer 進行交互。經過源碼可知，FileChannel的read方法和write方法都致使數據複製了兩次！

Selector可以使一個單獨的線程管理多個Channel，open方法可建立Selector，register方法向多路複用器器註冊通道，能夠監聽的事件類型：讀、寫、鏈接、accept。註冊事件後會產生一個SelectionKey：它表示SelectableChannel 和Selector 之間的註冊關係，wakeup方法：使還沒有返回的第一個選擇操做當即返回，喚醒的緣由是：註冊了新的channel或者事件；channel關閉，取消註冊；優先級更高的事件觸發（如定時器事件），但願及時處理。

Selector在Linux的實現類是EPollSelectorImpl，委託給EPollArrayWrapper實現，其中三個native方法是對epoll的封裝，而EPollSelectorImpl. implRegister方法，經過調用epoll_ctl向epoll實例中註冊事件，還將註冊的文件描述符(fd)與SelectionKey的對應關係添加到fdToKey中，這個map維護了文件描述符與SelectionKey的映射。

fdToKey有時會變得很是大，由於註冊到Selector上的Channel很是多（百萬鏈接）；過時或失效的Channel沒有及時關閉。fdToKey老是串行讀取的，而讀取是在select方法中進行的，該方法是非線程安全的。

Pipe：兩個線程之間的單向數據鏈接，數據會被寫到sink通道，從source通道讀取

NIO的服務端創建過程：Selector.open()：打開一個Selector；ServerSocketChannel.open()：建立服務端的Channel；bind()：綁定到某個端口上。並配置非阻塞模式；register()：註冊Channel和關注的事件到Selector上；select()輪詢拿到已經就緒的事件

3.Netty的特色？

一個高性能、異步事件驅動的NIO框架，它提供了對TCP、UDP和文件傳輸的支持
使用更高效的socket底層，對epoll空輪詢引發的cpu佔用飆升在內部進行了處理，避免了直接使用NIO的陷阱，簡化了NIO的處理方式。
採用多種decoder/encoder 支持，對TCP粘包/分包進行自動化處理
可以使用接受/處理線程池，提升鏈接效率，對重連、心跳檢測的簡單支持
可配置IO線程數、TCP參數， TCP接收和發送緩衝區使用直接內存代替堆內存，經過內存池的方式循環利用ByteBuf
經過引用計數器及時申請釋放再也不引用的對象，下降了GC頻率
使用單線程串行化的方式，高效的Reactor線程模型
大量使用了volitale、使用了CAS和原子類、線程安全類的使用、讀寫鎖的使用

4.Netty的線程模型？

Netty經過Reactor模型基於多路複用器接收並處理用戶請求，內部實現了兩個線程池，boss線程池和work線程池，其中boss線程池的線程負責處理請求的accept事件，當接收到accept事件的請求時，把對應的socket封裝到一個NioSocketChannel中，並交給work線程池，其中work線程池負責請求的read和write事件，由對應的Handler處理。

單線程模型：全部I/O操做都由一個線程完成，即多路複用、事件分發和處理都是在一個Reactor線程上完成的。既要接收客戶端的鏈接請求,向服務端發起鏈接，又要發送/讀取請求或應答/響應消息。一個NIO 線程同時處理成百上千的鏈路，性能上沒法支撐，速度慢，若線程進入死循環，整個程序不可用，對於高負載、大併發的應用場景不合適。

多線程模型：有一個NIO 線程（Acceptor） 只負責監聽服務端，接收客戶端的TCP 鏈接請求；NIO 線程池負責網絡IO 的操做，即消息的讀取、解碼、編碼和發送；1 個NIO 線程能夠同時處理N 條鏈路，可是1 個鏈路只對應1 個NIO 線程，這是爲了防止發生併發操做問題。但在併發百萬客戶端鏈接或須要安全認證時，一個Acceptor 線程可能會存在性能不足問題。

主從多線程模型：Acceptor 線程用於綁定監聽端口，接收客戶端鏈接，將SocketChannel 從主線程池的Reactor 線程的多路複用器上移除，從新註冊到Sub 線程池的線程上，用於處理I/O 的讀寫等操做，從而保證mainReactor只負責接入認證、握手等操做；

5.TCP 粘包/拆包的緣由及解決方法？

TCP是以流的方式來處理數據，一個完整的包可能會被TCP拆分紅多個包進行發送，也可能把小的封裝成一個大的數據包發送。

TCP粘包/分包的緣由：

• 應用程序寫入的字節大小大於套接字發送緩衝區的大小，會發生拆包現象，而應用程序寫入數據小於套接字緩衝區大小，網卡將應用屢次寫入的數據發送到網絡上，這將會發生粘包現象；
• 進行MSS大小的TCP分段，當TCP報文長度-TCP頭部長度>MSS的時候將發生拆包
• 以太網幀的payload（淨荷）大於MTU（1500字節）進行ip分片。

解決方法

• 消息定長：FixedLengthFrameDecoder類
• 包尾增長特殊字符分割：行分隔符類：LineBasedFrameDecoder或自定義分隔符類 ：DelimiterBasedFrameDecoder
• 將消息分爲消息頭和消息體：LengthFieldBasedFrameDecoder類。分爲有頭部的拆包與粘包、長度字段在前且有頭部的拆包與粘包、多擴展頭部的拆包與粘包。

6.瞭解哪幾種序列化協議？

• 序列化（編碼）是將對象序列化爲二進制形式（字節數組），主要用於網絡傳輸、數據持久化等；而反序列化（解碼）則是將從網絡、磁盤等讀取的字節數組還原成原始對象，主要用於網絡傳輸對象的解碼，以便完成遠程調用。
• 影響序列化性能的關鍵因素：序列化後的碼流大小（網絡帶寬的佔用）、序列化的性能（CPU資源佔用）；是否支持跨語言（異構系統的對接和開發語言切換）。
• Java默認提供的序列化：沒法跨語言、序列化後的碼流太大、序列化的性能差
• XML，優勢：人機可讀性好，可指定元素或特性的名稱。缺點：序列化數據只包含數據自己以及類的結構，不包括類型標識和程序集信息；只能序列化公共屬性和字段；不能序列化方法；文件龐大，文件格式複雜，傳輸佔帶寬。適用場景：當作配置文件存儲數據，實時數據轉換。
• JSON，是一種輕量級的數據交換格式，優勢：兼容性高、數據格式比較簡單，易於讀寫、序列化後數據較小，可擴展性好，兼容性好、與XML相比，其協議比較簡單，解析速度比較快。缺點：數據的描述性比XML差、不適合性能要求爲ms級別的狀況、額外空間開銷比較大。適用場景（可替代ＸＭＬ）：跨防火牆訪問、可調式性要求高、基於Web browser的Ajax請求、傳輸數據量相對小，實時性要求相對低（例如秒級別）的服務。
• Fastjson，採用一種「假定有序快速匹配」的算法。優勢：接口簡單易用、目前java語言中最快的json庫。缺點：過於注重快，而偏離了「標準」及功能性、代碼質量不高，文檔不全。適用場景：協議交互、Web輸出、Android客戶端
• Thrift，不只是序列化協議，仍是一個RPC框架。優勢：序列化後的體積小, 速度快、支持多種語言和豐富的數據類型、對於數據字段的增刪具備較強的兼容性、支持二進制壓縮編碼。缺點：使用者較少、跨防火牆訪問時，不安全、不具備可讀性，調試代碼時相對困難、不能與其餘傳輸層協議共同使用（例如HTTP）、沒法支持向持久層直接讀寫數據，即不適合作數據持久化序列化協議。適用場景：分佈式系統的RPC解決方案
• Avro，Hadoop的一個子項目，解決了JSON的冗長和沒有IDL的問題。優勢：支持豐富的數據類型、簡單的動態語言結合功能、具備自我描述屬性、提升了數據解析速度、快速可壓縮的二進制數據形式、能夠實現遠程過程調用RPC、支持跨編程語言實現。缺點：對於習慣於靜態類型語言的用戶不直觀。適用場景：在Hadoop中作Hive、Pig和MapReduce的持久化數據格式。
• Protobuf，將數據結構以.proto文件進行描述，經過代碼生成工具能夠生成對應數據結構的POJO對象和Protobuf相關的方法和屬性。優勢：序列化後碼流小，性能高、結構化數據存儲格式（XML JSON等）、經過標識字段的順序，能夠實現協議的前向兼容、結構化的文檔更容易管理和維護。缺點：須要依賴於工具生成代碼、支持的語言相對較少，官方只支持Java 、C++ 、python。適用場景：對性能要求高的RPC調用、具備良好的跨防火牆的訪問屬性、適合應用層對象的持久化

• 其它

  • protostuff 基於protobuf協議，但不須要配置proto文件，直接導包便可
  • Jboss marshaling 能夠直接序列化java類， 無須實java.io.Serializable接口
  • Message pack 一個高效的二進制序列化格式
  • Hessian 採用二進制協議的輕量級remoting onhttp工具
  • kryo 基於protobuf協議，只支持java語言,須要註冊（Registration），而後序列化（Output），反序列化（Input）

7.如何選擇序列化協議？

• 具體場景
• 對於公司間的系統調用，若是性能要求在100ms以上的服務，基於XML的SOAP協議是一個值得考慮的方案。
• 基於Web browser的Ajax，以及Mobile app與服務端之間的通信，JSON協議是首選。對於性能要求不過高，或者以動態類型語言爲主，或者傳輸數據載荷很小的的運用場景，JSON也是很是不錯的選擇。
• 對於調試環境比較惡劣的場景，採用JSON或XML可以極大的提升調試效率，下降系統開發成本。
• 當對性能和簡潔性有極高要求的場景，Protobuf，Thrift，Avro之間具備必定的競爭關係。
• 對於T級別的數據的持久化應用場景，Protobuf和Avro是首要選擇。若是持久化後的數據存儲在hadoop子項目裏，Avro會是更好的選擇。
• 對於持久層非Hadoop項目，以靜態類型語言爲主的應用場景，Protobuf會更符合靜態類型語言工程師的開發習慣。因爲Avro的設計理念偏向於動態類型語言，對於動態語言爲主的應用場景，Avro是更好的選擇。
• 若是須要提供一個完整的RPC解決方案，Thrift是一個好的選擇。
• 若是序列化以後須要支持不一樣的傳輸層協議，或者須要跨防火牆訪問的高性能場景，Protobuf能夠優先考慮。
• protobuf的數據類型有多種：bool、double、float、int3二、int6四、string、bytes、enum、message。protobuf的限定符：required: 必須賦值，不能爲空、optional:字段能夠賦值，也能夠不賦值、repeated: 該字段能夠重複任意次數（包括0次）、枚舉；只能用指定的常量集中的一個值做爲其值；
• protobuf的基本規則：每一個消息中必須至少留有一個required類型的字段、包含0個或多個optional類型的字段；repeated表示的字段能夠包含0個或多個數據；[1,15]以內的標識號在編碼的時候會佔用一個字節（經常使用），[16,2047]以內的標識號則佔用2個字節，標識號必定不能重複、使用消息類型，也能夠將消息嵌套任意多層，可用嵌套消息類型來代替組。
• protobuf的消息升級原則：不要更改任何已有的字段的數值標識；不能移除已經存在的required字段，optional和repeated類型的字段能夠被移除，但要保留標號不能被重用。新添加的字段必須是optional或repeated。由於舊版本程序沒法讀取或寫入新增的required限定符的字段。
• 編譯器爲每個消息類型生成了一個.java文件，以及一個特殊的Builder類（該類是用來建立消息類接口的）。如：UserProto.User.Builder builder = UserProto.User.newBuilder();builder.build()；
• Netty中的使用：ProtobufVarint32FrameDecoder 是用於處理半包消息的解碼類；ProtobufDecoder(UserProto.User.getDefaultInstance())這是建立的UserProto.java文件中的解碼類；ProtobufVarint32LengthFieldPrepender 對protobuf協議的消息頭上加上一個長度爲32的整形字段，用於標誌這個消息的長度的類；ProtobufEncoder 是編碼類
• 將StringBuilder轉換爲ByteBuf類型：copiedBuffer()方法

8.Netty的零拷貝實現

• Netty的接收和發送ByteBuffer採用DIRECT BUFFERS，使用堆外直接內存進行Socket讀寫，不須要進行字節緩衝區的二次拷貝。堆內存多了一次內存拷貝，JVM會將堆內存Buffer拷貝一份到直接內存中，而後才寫入Socket中。ByteBuffer由ChannelConfig分配，而ChannelConfig建立ByteBufAllocator默認使用Direct Buffer
• CompositeByteBuf 類能夠將多個 ByteBuf 合併爲一個邏輯上的 ByteBuf, 避免了傳統經過內存拷貝的方式將幾個小Buffer合併成一個大的Buffer。addComponents方法將 header 與 body 合併爲一個邏輯上的 ByteBuf, 這兩個 ByteBuf 在CompositeByteBuf 內部都是單獨存在的, CompositeByteBuf 只是邏輯上是一個總體
• 經過 FileRegion 包裝的FileChannel.tranferTo方法 實現文件傳輸, 能夠直接將文件緩衝區的數據發送到目標 Channel，避免了傳統經過循環write方式致使的內存拷貝問題。
• 經過 wrap方法, 咱們能夠將 byte[] 數組、ByteBuf、ByteBuffer等包裝成一個 Netty ByteBuf 對象, 進而避免了拷貝操做。
• Selector BUG：若Selector的輪詢結果爲空，也沒有wakeup或新消息處理，則發生空輪詢，CPU使用率100%，
• Netty的解決辦法：對Selector的select操做週期進行統計，每完成一次空的select操做進行一次計數，若在某個週期內連續發生N次空輪詢，則觸發了epoll死循環bug。重建Selector，判斷是不是其餘線程發起的重建請求，若不是則將原SocketChannel從舊的Selector上去除註冊，從新註冊到新的Selector上，並將原來的Selector關閉。

9.Netty的高性能表如今哪些方面？

• 心跳，對服務端：會定時清除閒置會話inactive(netty5)，對客戶端:用來檢測會話是否斷開，是否重來，檢測網絡延遲，其中idleStateHandler類 用來檢測會話狀態
• 串行無鎖化設計，即消息的處理儘量在同一個線程內完成，期間不進行線程切換，這樣就避免了多線程競爭和同步鎖。表面上看，串行化設計彷佛CPU利用率不高，併發程度不夠。可是，經過調整NIO線程池的線程參數，能夠同時啓動多個串行化的線程並行運行，這種局部無鎖化的串行線程設計相比一個隊列-多個工做線程模型性能更優。
• 可靠性，鏈路有效性檢測：鏈路空閒檢測機制，讀/寫空閒超時機制；內存保護機制：經過內存池重用ByteBuf;ByteBuf的解碼保護；優雅停機：再也不接收新消息、退出前的預處理操做、資源的釋放操做。
• Netty安全性：支持的安全協議：SSL V2和V3，TLS，SSL單向認證、雙向認證和第三方CA認證。
• 高效併發編程的體現：volatile的大量、正確使用；CAS和原子類的普遍使用；線程安全容器的使用；經過讀寫鎖提高併發性能。IO通訊性能三原則：傳輸（AIO）、協議（Http）、線程（主從多線程）
• 流量整型的做用（變壓器）：防止因爲上下游網元性能不均衡致使下游網元被壓垮，業務流中斷；防止因爲通訊模塊接受消息過快，後端業務線程處理不及時致使撐死問題。
• TCP參數配置：SO_RCVBUF和SO_SNDBUF：一般建議值爲128K或者256K；SO_TCPNODELAY：NAGLE算法經過將緩衝區內的小封包自動相連，組成較大的封包，阻止大量小封包的發送阻塞網絡，從而提升網絡應用效率。可是對於時延敏感的應用場景須要關閉該優化算法；

10.NIOEventLoopGroup源碼

• NioEventLoopGroup(實際上是MultithreadEventExecutorGroup) 內部維護一個類型爲 EventExecutor children [], 默認大小是處理器核數 * 2, 這樣就構成了一個線程池，初始化EventExecutor時NioEventLoopGroup重載newChild方法，因此children元素的實際類型爲NioEventLoop。
• 線程啓動時調用SingleThreadEventExecutor的構造方法，執行NioEventLoop類的run方法，首先會調用hasTasks()方法判斷當前taskQueue是否有元素。若是taskQueue中有元素，執行 selectNow() 方法，最終執行selector.selectNow()，該方法會當即返回。若是taskQueue沒有元素，執行 select(oldWakenUp) 方法
• select ( oldWakenUp) 方法解決了 Nio 中的 bug，selectCnt 用來記錄selector.select方法的執行次數和標識是否執行過selector.selectNow()，若觸發了epoll的空輪詢bug，則會反覆執行selector.select(timeoutMillis)，變量selectCnt 會逐漸變大，當selectCnt 達到閾值（默認512），則執行rebuildSelector方法，進行selector重建，解決cpu佔用100%的bug。
• rebuildSelector方法先經過openSelector方法建立一個新的selector。而後將old selector的selectionKey執行cancel。最後將old selector的channel從新註冊到新的selector中。rebuild後，須要從新執行方法selectNow，檢查是否有已ready的selectionKey。
• 接下來調用processSelectedKeys 方法（處理I/O任務），當selectedKeys != null時，調用processSelectedKeysOptimized方法，迭代 selectedKeys 獲取就緒的 IO 事件的selectkey存放在數組selectedKeys中, 而後爲每一個事件都調用 processSelectedKey 來處理它，processSelectedKey 中分別處理OP_READ；OP_WRITE；OP_CONNECT事件。
• 最後調用runAllTasks方法（非IO任務），該方法首先會調用fetchFromScheduledTaskQueue方法，把scheduledTaskQueue中已經超過延遲執行時間的任務移到taskQueue中等待被執行，而後依次從taskQueue中取任務執行，每執行64個任務，進行耗時檢查，若是已執行時間超過預先設定的執行時間，則中止執行非IO任務，避免非IO任務太多，影響IO任務的執行。
• 每一個NioEventLoop對應一個線程和一個Selector，NioServerSocketChannel會主動註冊到某一個NioEventLoop的Selector上，NioEventLoop負責事件輪詢。
• Outbound 事件都是請求事件, 發起者是 Channel，處理者是 unsafe，經過 Outbound 事件進行通知，傳播方向是 tail到head。Inbound 事件發起者是 unsafe，事件的處理者是 Channel, 是通知事件，傳播方向是從頭至尾。
• 內存管理機制，首先會預申請一大塊內存Arena，Arena由許多Chunk組成，而每一個Chunk默認由2048個page組成。Chunk經過AVL樹的形式組織Page，每一個葉子節點表示一個Page，而中間節點表示內存區域，節點本身記錄它在整個Arena中的偏移地址。當區域被分配出去後，中間節點上的標記位會被標記，這樣就表示這個中間節點如下的全部節點都已被分配了。大於8k的內存分配在poolChunkList中，而PoolSubpage用於分配小於8k的內存，它會把一個page分割成多段，進行內存分配。
• ByteBuf的特色：支持自動擴容（4M），保證put方法不會拋出異常、經過內置的複合緩衝類型，實現零拷貝（zero-copy）；不須要調用flip()來切換讀/寫模式，讀取和寫入索引分開；方法鏈；引用計數基於AtomicIntegerFieldUpdater用於內存回收；PooledByteBuf採用二叉樹來實現一個內存池，集中管理內存的分配和釋放，不用每次使用都新建一個緩衝區對象。UnpooledHeapByteBuf每次都會新建一個緩衝區對象。

請戳GitHub原文: https://github.com/wangzhiwubigdata/God-Of-BigData

                   關注公衆號,內推,面試,資源下載,關注更多大數據技術~
                   大數據成神之路~預計更新500+篇文章，已經更新50+篇~