文章目錄

• 前言
• 一、Netty
• • · Netty簡介
  • · Netty核心架構(gòu)
  • · Netty中Reactor實(shí)現(xiàn)
  • • 1.工作流程
    • 2.ChannelPipeline 和 ChannelHandler（開發(fā)者關(guān)注實(shí)現(xiàn)點(diǎn)）
  • · Netty一次編解碼（ByteToMessage）——解決TCP粘包、拆包（半包）
  • • 1.TCP粘包、拆包（半包）
    • 2.Netty解決TCP粘包、半包 （一次編解碼）
  • · Netty二次編解碼（MessageToMessage）——對象轉(zhuǎn)換 方便使用
  • • 1.二次編解碼方式
    • 2.常用的二次編解碼器
  • · Keepalive & idle監(jiān)測 （心跳檢測）
• 二、網(wǎng)絡(luò)IO
• • · IO概念
  • · IO類型
  • • 阻塞 / 非阻塞
    • 同步 / 異步
  • · 常見IO模型
  • • 1.同步阻塞IO
    • • Java-BIO模型
    • 2.同步非阻塞IO
    • 3.IO多路復(fù)用
    • • Java-NIO模型
    • 4.信號(hào)IO
    • 5.異步IO
    • • Java-AIO模型
• 三、Reactor線程模型
• • · 概念
  • · NIO下Reactor線程模型
  • • 1.單Reactor單線程
    • 2.單Reactor多線程
    • 3.主從Reactor多線程

為贊皇等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及贊皇網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站制作、網(wǎng)站建設(shè)、贊皇網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！

---

前言

本文介紹了基于NIO、Reactor線程模型的Netty網(wǎng)絡(luò)通信框架，部分內(nèi)容涉及個(gè)人的理解，可能存在理解偏差。

關(guān)鍵字快捷鏈接：NIO 、 主從Reactor多線程

---

一、Netty · Netty簡介

Netty是由JBOSS提供的一個(gè)java開源框架，現(xiàn)為 Github上的獨(dú)立項(xiàng)目。Netty提供非阻塞的、事件驅(qū)動(dòng)的網(wǎng)絡(luò)應(yīng)用程序框架和工具，用以快速開發(fā)高性能、高可靠性的網(wǎng)絡(luò)服務(wù)器和客戶端程序，也就是說，Netty 是一個(gè)基于NIO的客戶、服務(wù)器端的編程框架。

Netty官網(wǎng)鏈接

· Netty核心架構(gòu)

核心（Core）

· 可擴(kuò)展的事件模型
	· 統(tǒng)一的通信API，簡化了通信編碼
	· 零拷貝機(jī)制與豐富的字節(jié)緩沖區(qū)

傳輸服務(wù)（Transport Services）

· 支持socket以及datagram（數(shù)據(jù)報(bào)）
	· http傳輸服務(wù)
	· In-VM Pipe （管道協(xié)議，是jvm的一種進(jìn)程）

協(xié)議支持（Protocol Support）

· http 以及 websocket
	· SSL 安全套接字協(xié)議支持
	· Google Protobuf （序列化框架）
	· 支持zlib、gzip壓縮
	· 支持大文件的傳輸
	· RTSP（實(shí)時(shí)流傳輸協(xié)議，是TCP/IP協(xié)議體系中的一個(gè)應(yīng)用層協(xié)議）
	· 支持二進(jìn)制協(xié)議并且提供了完整的單元測試

· Netty中Reactor實(shí)現(xiàn) 1.工作流程

Netty線程模型是基于Reactor模型實(shí)現(xiàn)的，對Reactor三種模式都有非常好的支持，并做了一定的改進(jìn)，也非常的靈活，一般情況，在服務(wù)端會(huì)采用主從Reactor架構(gòu)模型。

工作流程

1. Netty 抽象出兩組線程池：BossGroup 和 WorkerGroup，每個(gè)線程池中都有EventLoop 線程（可以是OIO,NIO,AIO）。BossGroup
   中的線程專門負(fù)責(zé)和客戶端建立連接，WorkerGroup 中的線程專門負(fù)責(zé)處理連接上的讀寫, EventLoopGroup 相當(dāng)于一個(gè)事件循環(huán)組，
   這個(gè)組中含有多個(gè)事件循環(huán)
2. EventLoop 表示一個(gè)不斷循環(huán)的執(zhí)行事件處理的線程，每個(gè)EventLoop 都包含一個(gè) Selector，用于監(jiān)聽注冊在其上的 Socket 網(wǎng)絡(luò)
   連接（Channel）。
3. 每個(gè) Boss EventLoop 中循環(huán)執(zhí)行以下三個(gè)步驟：
   3.1 select：輪訓(xùn)注冊在其上的 ServerSocketChannel 的 accept 事件（OP_ACCEPT 事件）
   3.2 processSelectedKeys：處理 accept 事件，與客戶端建立連接，生成一個(gè)SocketChannel，并將其注冊到某個(gè) Worker
   EventLoop 上的 Selector 上
   3.3 runAllTasks：再去以此循環(huán)處理任務(wù)隊(duì)列中的其他任務(wù)
4. 每個(gè) Worker EventLoop 中循環(huán)執(zhí)行以下三個(gè)步驟：
   4.1 select：輪訓(xùn)注冊在其上的SocketChannel 的 read/write 事件（OP_READ/OP_WRITE 事件）
   4.2 processSelectedKeys：在對應(yīng)的SocketChannel 上處理 read/write 事件
   4.3 runAllTasks：再去以此循環(huán)處理任務(wù)隊(duì)列中的其他任務(wù)
5. 在以上兩個(gè)processSelectedKeys步驟中，會(huì)使用 Pipeline（管道），Pipeline 中引用了 Channel，即通過 Pipeline 可以獲取到對
   應(yīng)的 Channel，Pipeline 中維護(hù)了很多的處理器（攔截處理器、過濾處理器、自定義處理器等）。
   
   

2.ChannelPipeline 和 ChannelHandler（開發(fā)者關(guān)注實(shí)現(xiàn)點(diǎn)）

開發(fā)者主要關(guān)注和實(shí)現(xiàn)的點(diǎn)是pipeline中的channelHandler，即數(shù)據(jù)處理業(yè)務(wù)操作等在channelHandler上進(jìn)行。

ChannelPipeline 提供了 ChannelHandler 鏈的容器。以服務(wù)端程序?yàn)槔?，客戶端發(fā)送過來的數(shù)據(jù)要接收，讀取處理，我們稱數(shù)據(jù)是入站的，需要經(jīng)過一系列Handler處理后；如果服務(wù)器想向客戶端寫回?cái)?shù)據(jù)，也需要經(jīng)過一系列Handler處理，我們稱數(shù)據(jù)是出站的。

一個(gè)SocketChannel對應(yīng)一個(gè)ChannelPipeline，ChannelPipeline提供了雙向鏈的ChannelHandler容器，初始化了head，tail的ChannelHandler。

入站：從head到tail
出站：從tail到head

ChannelHandler類型

1. inbound——處理入站事件
2. outbound——處理出站事件
3. duplex——混合型處理入站和出站事件

對于數(shù)據(jù)的出站和入站，有著不同的ChannelHandler類型與之對應(yīng)：

1. ChannelInboundHandler 入站事件處理器
2. ChannelOutBoundHandler 出站事件處理器
3. ChannelHandlerAdapter提供了一些方法的默認(rèn)實(shí)現(xiàn)，可減少用戶對于ChannelHandler的編寫
4. ChannelDuplexHandler：混合型，既能處理入站事件又能處理出站事件。

· Netty一次編解碼（ByteToMessage）——解決TCP粘包、拆包（半包） 1.TCP粘包、拆包（半包）

粘包、拆包概念

粘包：發(fā)送方每次寫入數(shù)據(jù)<套接字緩沖區(qū)大小 ； 接收方讀取套接字緩沖區(qū)數(shù)據(jù)不夠及時(shí)

拆包：發(fā)送方寫入數(shù)據(jù)>套接字緩沖區(qū)大小 ； 發(fā)送的大報(bào)文長度大于MSS, 數(shù)據(jù)包大于協(xié)議的MTU（大傳輸單元，1500字節(jié)），必須拆包

收發(fā)角度：一個(gè)發(fā)送可能被多次接收(半包)，多個(gè)發(fā)送可能被一次接收(粘包)
傳輸角度：一個(gè)發(fā)送可能占用多個(gè)傳輸包(半包)，多個(gè)發(fā)送可能公用一個(gè)傳輸包(粘包)

粘包、拆包原因

根本原因： 消息無邊界

TCP 協(xié)議是面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，是一種流式協(xié)議，消息無邊界。

解決思路

解決TCP粘包、半包問題的根本：找出消息的邊界

解決方案

1. TCP變?yōu)槎踢B接，一個(gè)請求一個(gè)短連接
2. 每條數(shù)據(jù)都是固定長度
3. 用分隔符作為標(biāo)識(shí)
4. 包裝消息為 head+body （head描述body的長度等信息）

2.Netty解決TCP粘包、半包 （一次編解碼）

Netty提供了針對封裝成幀這種形式下不同方式的拆包器，所謂的拆包其實(shí)就是數(shù)據(jù)的解碼,所謂解碼就是將網(wǎng)絡(luò)中的一些原始數(shù)據(jù)解碼成上層應(yīng)用的數(shù)據(jù)，那對應(yīng)在發(fā)送數(shù)據(jù)的時(shí)候要按照同樣的方式進(jìn)行數(shù)據(jù)的編碼操作然后發(fā)送到網(wǎng)絡(luò)中。

· Netty二次編解碼（MessageToMessage）——對象轉(zhuǎn)換 方便使用 1.二次編解碼方式

用戶數(shù)據(jù)(ByteBuf )和 Java Object之間的轉(zhuǎn)換，或者將將一種格式轉(zhuǎn)化為另一種格式（譬如將應(yīng)用數(shù)據(jù)轉(zhuǎn)化成某種協(xié)議數(shù)據(jù)）

1. Java 序列化：不推薦使用，占用空間大，也只有java語言能用
2. Marshaling：比java序列化稍好
3. XML ：可讀性好，但是占用空間大
4. JSON ：可讀性也好，空間較小
5. MessagePack ：占用空間比JSON小，可讀性不如JSON，但也還行
6. Protobuf ：性能高，體積小，但是可讀性差
7. hessian ：跨語言、高效的二進(jìn)制序列化協(xié)議，整體性能和protobuf差不多。
8. 其他
   
   

2.常用的二次編解碼器

String編解碼

StringDecoder/StringEncoder

Protostuff編解碼

protostuff是一個(gè)基于protobuf實(shí)現(xiàn)的序列化方法，它較于protobuf最明顯的好處是，在幾乎不損耗性能的情況下做到了不用我們寫.proto文件來實(shí)現(xiàn)序列化

個(gè)人理解：protobuf是需要遵循proto語言進(jìn)編譯proto文件，protostuff是對他進(jìn)一步包裝

Protostuff項(xiàng)目地址鏈接

· Keepalive & idle監(jiān)測 （心跳檢測）

keepalive

定時(shí)keepalive 消息，keepalive 消息與服務(wù)器正常消息交換完全不關(guān)聯(lián)，定時(shí)就發(fā)送；

idel監(jiān)測

Idle 監(jiān)測，只是負(fù)責(zé)診斷，診斷后，做出不同的行為，決定Idle 監(jiān)測的最終用途，一般用來配合keepalive ，減少keepalive 消息；

空閑監(jiān)測+ 判定為Idle 時(shí)才發(fā)keepalive，有其他數(shù)據(jù)傳輸?shù)臅r(shí)候，不發(fā)送keepalive ，無數(shù)據(jù)傳輸超過一定時(shí)間，判定為Idle，再發(fā)keepalive

---

二、網(wǎng)絡(luò)IO

網(wǎng)絡(luò)IO的過程，就是操作系統(tǒng)接收到網(wǎng)卡的數(shù)據(jù)，緩存到一個(gè)buffer中，然后應(yīng)用程序調(diào)用操作系統(tǒng)的函數(shù)，從對應(yīng)的buffer中取出數(shù)據(jù)。

[Client]													[Server]

	應(yīng)用層 HTTP...												 應(yīng)用層
-------------------	 socket									------------------- socket
	傳輸層 TCP -----											---- 傳輸層
                   |==>操作系統(tǒng)：內(nèi)核kernel/內(nèi)核協(xié)議棧 ==>|
	網(wǎng)絡(luò)層 IP  -----   										---- 網(wǎng)絡(luò)層
	
	鏈路層														 鏈路層
	
	物理層														 物理層

連接建立：跟應(yīng)用程序無關(guān)，是內(nèi)核程序棧建立好連接創(chuàng)建一個(gè)socket，分配好對應(yīng)的緩沖區(qū)資源，把連接放到連接隊(duì)列里面，引用程序在連接隊(duì)列將連接取走。

· IO概念

I/O就是計(jì)算機(jī)內(nèi)存與外部設(shè)備之間拷貝數(shù)據(jù)的過程

· IO類型 阻塞 / 非阻塞

阻塞：沒有數(shù)據(jù)傳過來時(shí)，讀會(huì)阻塞直到有數(shù)據(jù)；緩沖區(qū)滿時(shí)，寫操作也會(huì)阻塞。
非阻塞：非阻塞遇到這些情況，直接返回

同步 / 異步

同步：數(shù)據(jù)就緒后需要程序去讀
異步：數(shù)據(jù)就緒后系統(tǒng)直接讀好再回調(diào)給程序

個(gè)人理解：同步是應(yīng)用層主動(dòng)向操作系統(tǒng)要數(shù)據(jù)； 異步是操作系統(tǒng)主動(dòng)通過回調(diào)函數(shù)給程序。
所以異步IO主要看操作系統(tǒng)支持成熟度

· 常見IO模型 1.同步阻塞IO

Java-BIO模型

概述

BIO是blocking I/O的簡稱，它是同步阻塞型IO，其相關(guān)的類和接口在java.io下。

BIO模型簡單來講，就是服務(wù)端為每一個(gè)請求都分配一個(gè)線程進(jìn)行處理，I/O操作都是基于流Stream的操作。

弊端

1.線程開銷：客戶端的并發(fā)數(shù)與后端的線程數(shù)成1：1的比例，線程的創(chuàng)建、銷毀是非常消耗系統(tǒng)資源的，隨著并發(fā)量增大，服務(wù)端性能將顯著下降，甚至?xí)l(fā)生線程堆棧溢出等操作；

2.線程阻塞：當(dāng)連接創(chuàng)建后，如果該線程沒有操作時(shí)，會(huì)進(jìn)行阻塞操作，這樣極大的浪費(fèi)了服務(wù)器資源。

2.同步非阻塞IO

非阻塞： 通過輪詢?nèi)z測是否有數(shù)據(jù)準(zhǔn)備好，沒有數(shù)據(jù)準(zhǔn)備好就一直輪詢，直到有數(shù)據(jù)準(zhǔn)備好則開始數(shù)據(jù)拷貝。

3.IO多路復(fù)用

個(gè)人理解： 基于同步非阻塞IO進(jìn)行優(yōu)化，通過select/epoll等系統(tǒng)調(diào)用，僅遍歷有事件的通道，而非遍歷所有的通道

Java-NIO模型

概述

NIO，稱之為New IO或是non-block IO （非阻塞IO ）
底層基于IO多路復(fù)用，IO多路復(fù)用時(shí)同步非阻塞，不過多加了一套檢測機(jī)制；
檢測機(jī)制核心思想：檢測所有socket，哪些準(zhǔn)備好了就操作，沒準(zhǔn)備好的就不操作

NIO的三大核心組件：Buffer（緩沖區(qū)）、Channel（通道）、Selector（選擇器/多路復(fù)用器）

1.Buffer（緩沖區(qū)）

個(gè)人理解：Buffer作為數(shù)據(jù)容器
Buffer是一個(gè)對象，包含一些要寫入或者讀出的數(shù)據(jù)，在NIO中，所有數(shù)據(jù)都是用緩沖區(qū)處理的，讀數(shù)據(jù)直接從緩沖區(qū)讀，寫數(shù)據(jù)直接寫入到緩沖區(qū)，緩沖區(qū)的本質(zhì)是一個(gè)數(shù)組，通常是一個(gè)字節(jié)數(shù)組（ByteBuffer），也可以使用其他類型，但緩沖區(qū)又不僅僅是一個(gè)數(shù)組，他還提供了對數(shù)據(jù)結(jié)構(gòu)化訪問以及維護(hù)讀寫位置等操作。

2.Channel（通道）

個(gè)人理解：Channel通道，上面有連接、讀取、寫入等事件操作
Channel是一個(gè)通道，管道，網(wǎng)絡(luò)數(shù)據(jù)通過Channel讀取和寫入，Channel和流Stream的不同之處在于Channel是雙向的，流只在一個(gè)方向上移動(dòng)（InputStream/OutputStream），而Channel可以用于讀寫同時(shí)進(jìn)行，即Channel是全雙工的。

3.Selector（選擇器/多路復(fù)用器）

個(gè)人理解：Selector作為注冊輪詢服務(wù)，輪詢Channel的事件
Selector會(huì)不斷輪詢注冊在其他的Channel，如果某個(gè)Channel上面發(fā)生讀或者寫事件，即該Channel處于就緒狀態(tài)，他就會(huì)被Selector輪詢出來，然后通過selectedKeys可以獲取就緒Channel的集合，進(jìn)行后續(xù)的I/O操作

4.信號(hào)IO

安裝一個(gè)signal處理函數(shù)，進(jìn)程繼續(xù)運(yùn)行（不阻塞）。當(dāng)數(shù)據(jù)準(zhǔn)備好時(shí)，進(jìn)程會(huì)收到一個(gè)SIGIO信號(hào)，可以在signal處理函數(shù)中調(diào)用IO操作（如read）處理數(shù)據(jù)。

5.異步IO

基本流程

用戶線程通過系統(tǒng)調(diào)用，告知kernel內(nèi)核啟動(dòng)某個(gè)IO操作，用戶線程返回。
kernel內(nèi)核在整個(gè)IO操作完成后，通知用戶進(jìn)程，用戶執(zhí)行后續(xù)的業(yè)務(wù)操作。

Java-AIO模型

重點(diǎn)在操作系統(tǒng)層面，目前還并不完善

---

三、Reactor線程模型 · 概念

Reactor線程模型是一種并發(fā)編程模型，具有指導(dǎo)意義的思想

Reactor模型中三種角色（Reactor、Acceptor、Handler）：

Reactor

負(fù)責(zé)監(jiān)聽和分配事件，將I/O事件分派給對應(yīng)的Handler。新的事件包含 連接建立就緒、讀就緒、寫就緒

Acceptor

處理客戶端新連接，并分派請求到處理器鏈中

Handler

將自身與事件綁定，執(zhí)行非阻塞讀/寫任務(wù)，完成channel的讀入，完成處理業(yè)務(wù)邏輯后，負(fù)責(zé)將結(jié)果寫出channel

· NIO下Reactor線程模型
1.單Reactor單線程

所有的接收連接，處理數(shù)據(jù)的相關(guān)操作都是在一個(gè)線程中來完成，性能上有瓶頸

2.單Reactor多線程

把比較耗時(shí)的數(shù)據(jù)的編解碼運(yùn)算操作 放入線程池中來執(zhí)行

3.主從Reactor多線程

相較于單Reactor多線程，主從Reactor專門用線程去處理客戶端連接接收工作
主Reactor（mainReactor）處理客戶端連接接收工作；從Reactor（subReactor）處理讀寫編解碼運(yùn)算操作

這種模式也被叫做服務(wù)器的 1+M+N 線程模式
1：使用該模式開發(fā)的服務(wù)器包含一個(gè)（或多個(gè)，1 只是表示相對較少）連接建立線程
M：M 個(gè) IO 線程
N：N 個(gè)業(yè)務(wù)處理線程。這是業(yè)界成熟的服務(wù)器程序設(shè)計(jì)模式。

優(yōu)勢

1. MainReactor 線程與 SubReactor 線程的數(shù)據(jù)交互簡單職責(zé)明確，MainReactor 線程只需要接收新連接，SubReactor 線程完成后續(xù)的業(yè)務(wù)處理。
2. MainReactor 線程與 SubReactor 線程的數(shù)據(jù)交互簡單， MainReactor 線程只需要把新連接傳給SubReactor 線程，SubReactor 線程無需返回?cái)?shù)據(jù)。
3. 多個(gè) SubReactor 線程能夠應(yīng)對更高的并發(fā)請求。

你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機(jī)房具備T級流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級服務(wù)器適合批量采購，新人活動(dòng)首月15元起，快前往官網(wǎng)查看詳情吧

網(wǎng)頁標(biāo)題：【博學(xué)谷學(xué)習(xí)記錄】超強(qiáng)總結(jié)，用心分享|架構(gòu)師Netty框架學(xué)習(xí)總結(jié)-創(chuàng)新互聯(lián)
新聞來源：http://www.rwnh.cn/article10/copogo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App設(shè)計(jì)、手機(jī)網(wǎng)站建設(shè)、網(wǎng)站策劃、營銷型網(wǎng)站建設(shè)、定制開發(fā)、虛擬主機(jī)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)