Netty
2020-04-02 14:10:19 11 举报AI智能生成
Netty学习
作者其他创作
大纲/内容
启动类
链式编程，类似于java8常见语法
ServerBootstrap
创建服务端的辅助启动类ServerBootstrap对象，目的是降低服务端的开发复杂度<br>
Bootstrap<br>
创建客户端辅助启动类Bootstrap对象
常用方法
group(parentGroup,childGroup)<br>
参数配置Reactor线程模型
channel(Channel)
参数配置Channel类型，工厂模式创建Channel实例
服务端配置为NioServerSocketChannel，客户端配置为NioSocketChannel
option()
参数配置parentGroup的Option
handler(ChannelHandler)
参数配置parentGroup中accept线程的Handler
childOption(ChannelOption)
参数配置TCP属性
childAttr(AttributeKey)
参数配置childGroup的Reactor线程Attr
childHandler(ChildChannelHandler)
参数配置childGroup的Reactor线程Handler
bind(ip,port)
服务端监听端口，返回ChannelFuture
connect(ip,port)<br>
客户端连接Tcp服务端，返回ChannelFuture
EventLoopGroup<br>
通过适当的参数配置，就可以支持三种Reactor线程模型，类似于web应用中的tomcat<br>
父类
<font color="#c41230">EventLoopGroup</font>->EventExcutorGroup->ScheduledExcutorService->ExcutorService
子类
NioEventLoopGroup<br>
NioEventLoop并不是一个纯粹的I/O线程，它除了负责I/O的读写之外，还兼顾处理以下两类任务 <br>
系统Task
通过调用 NioEventLoop的 execute（Runnable task）方法实现
当I/O线程和用户线程同时操作网络资源时，为了防止并发操作导致的锁竞争，将用户线程的操作封装成Task放入消息队列中，由I/O线程负责执行，这样就实现了局部无锁化。
定时任务
通过调用 NioEventLoop的 schedule（Runnable command，long delay，TimeUnit unit）方法实现
线程模型
服务端启动的时候，创建了两个NioEventLoopGroup，它们实际是两个独立的Reactor线程池。线程池的<font color="#c41230">隔离术</font>，一个用于接收客户端的TCP连接，另一个用于处理I/O相关的读写操作，或者执行系统Task、定时任务Task等。
parentGroup
管理accept连接的线程<br>
boss线程池
bossGroup对应的就是主线程池，只接收客户端的连接（注册，初始化逻辑）<br>
将链路状态变更事件通知给ChannelPipeline
childGroup
管理Reactor事件的线程
worker线程池
具体的工作由workerGroup这个从线程池来完成
异步读取通信对端的数据报，发送读事件到ChannelPipeline
异步发送消息到通信对端，调用ChannelPipeline的消息发送接口
常用方法
shutdownGracefully()
优雅退出操作，通过该方法方便的关闭各种资源
channel
类似web应用的request&response
Netty提供了自己的Channel和其子类实现
NioServerSocketChannel
NioSocketChannel
常用方法
关联引用方法
pipeline()、Unsafe()
返回ChannelPipeline、Unsafe
closeFuture()
返回channel对象中的closeFuture对象
bind()、connect()、read()、write()、flush()、writeAndFlush()
与NIO中Channel对应的方法功能相似
入参可以新增ChannelPromise
返回参数ChannelFuture
config()
获取当前Channel的配置信息，例如CONNECT_ TIMEOUT_ MILLIS
attr()
设置用户自定义的属性，类似于request上的attribute
unsafe接口
封装了java底层的socket操作，作为连接netty和java底层NIO的重要桥梁，channel会初始化unsafe来和socket打交道<br>
ChannelPipeline<br>
责任链模式，类似于web应用中<font color="#c41230">所有</font>Filter、Servlet<font color="#c41230">行为管理类</font>
它本质就是一个负责处理网络事件的职责链，网络事件以事件流的形式在ChannelPipeline中流转
ChannelPipeline的事件处理流程
用户自定义ChannelHandler会插入到head和tail之间
如果是ChannelInboundHandler的回调，根据插入的顺序从左向右进行链式调用，ChannelOutboundHandler则相反
<br>
常用方法
获取关联引用方法
channel()、context()
返回Channel、ChannelHandlerContext
触发outbound事件方法
ChannelPipeline拥有channel所有方法
触发Inbound事件方法
fireChannelActive()、fireChannelRead()、fireChannelRegistered()<br>
返回ChannelPipeline
addLast、addFirst、addBefore、addAfter((EventExecutorGroup,Name,ChannelHandler))<br>
ChannelHandlerContext<br>
类似于web应用中<font color="#c41230">单个</font>Filter、Servlet的配置类<font color="#c41230">ServletContext</font><br>
它代表了ChannelPipeline和ChannelHandler之间的关联，创建于ChannelHandler被配置到ChannelPipeline的时候
每个ChannelHandler都对应一个ChannelHandlerContext
默认处理者
HeadContext
HeadContext继承AbstractChannelHandlerContext 实现了ChannelOutboundHandler, ChannelInboundHandler，所以其既可以处理inBound事件也可以处理outBound事件
TailContext
tail只是起了指引的作用，其具体处理业务逻辑都是由其父类实现，即调用下一个channelhandlerContext，其本身并没做什么实现
常用方法
关联引用方法
channel()、handler()、pipeline()、executor()
返回Channel、ChannelHandler、ChannelPipeline、EventExecutor
触发outbound事件方法
ChannelHandlerContext拥有channel所有方法
触发Inbound事件方法
fireChannelActive()、fireChannelRead()、fireChannelRegistered()<br>
返回ChannelHandlerContext
attr()
ChannelHandlerContext的自定义属性
ChannelHandler
IO事件的处理类，类似于web应用中单个Filter、Servlet配置中的实际<font color="#c41230">逻辑处理</font>类
@Sharable
该注解表示一个ChannelHandler可以属于多个ChannelPipeline，保证线程安全
@Skip
被Skip注解的方法不会被调用，直接被忽略，直接跳到下一个ChannelHandler中执行对应的方法
子类
ChannelHandlerAdapter
选择性地拦截和处理某个或者某些事件
ChannelInitializer
初始化Server端新接入的SocketChannel对象
initChannel()
Channel被注册到EventLoop的时候会被调用
ChannelInboundHandler
ChannelInboundHandlerAdapter
处理read()输入数据
ChannelOutboundHandler<br>
ChannelOutboundHandlerAdapter
处理write()输出数据
常用方法
生命周期方法
channelRegistered
当前channel注册到EventLoop
channelUnregistered
当前channel从EventLoop取消注册
channelActive
当前channel激活的时候
channelInactive
当前channel不活跃的时候，也就是当前channel到了它生命周期末
数据处理方法
channelRead
当前channel从远端读取到数据
channelReadComplete
channel read消费完读取的数据的时候被触发
userEventTriggered
用户事件触发的时候 <br>
channelWritabilityChanged
channel的写状态变化的时候触发 <br>
exceptionCaught
当发生异常时，关闭ChannelHandlerContext，释放和ChannelHandlerContext相关联的句柄等资源
常用系统ChannelHandler
ByteToMessageCodec
系统编解码框架
LengthFieldBasedFrameDecoder
通用基于长度的半包解码器
LoggingHandler
码流日志打印
SslHandler
SSL安全认证
IdleStateHandler
链路空闲检测
ChannelTrafficShapingHandler
流量整形
Base64Decoder和Base64Encoder
Base64编解码
AttributeMap
AttributeMap和Map的格式很像，key是AttributeKey，value是Attribute，我们可以根据AttributeKey找到对应的Attribute
Channel上的AttributeMap就是大家<font color="#c41230">共享</font>并且线程安全，每一个ChannelHandler都能获取到
ChannelHandlerContext上的AttributeMap是每个ChannelHandler<font color="#c41230">独有</font>的<br>
AttributeKey
Attribute
set(value)
get()
ChannelOption
内存配置&线程池配置&TCP参数配置
SO_BACKLOG
对应的是tcp/ip协议listen函数中的backlog参数，函数listen(int socketfd,int backlog)用来初始化服务端可连接队列
服务端处理客户端连接请求是顺序处理的，所以同一时间只能处理一个客户端连接，多个客户端来的时候，服务端将不能处理的客户端连接请求放在队列中等待处理，<font color="#000000">backlog参数</font><font color="#c41230">指定了队列的大小</font>
CONNECT_TIMEOUT_MILLIS
客户端<font color="#c41230">连接超时</font>设置，默认值30000毫秒即30秒
SO_SNDBUF和SO_RCVBUF
对应于套接字选项中的SO_SNDBUF和SO_RCVBUF，这两个参数用于操作<font color="#c41230">接收缓冲区和发送缓冲区的大小</font>
接收缓冲区用于保存网络协议站内收到的数据，直到应用程序读取成功，发送缓冲区用于保存发送数据，直到发送成功<br>
SO_KEEPALIVE
对应于套接字选项中的SO_KEEPALIVE，该参数用于设置TCP连接，当设置该选项以后，连接会测试链接的状态，这个选项用于可能长时间没有数据交流的连接。
当设置该选项以后，如果在<font color="#c41230">两小时</font>内没有数据的通信时，TCP会自动发送一个活动探测数据报文。
TCP_NODELAY
对应于套接字选项中的TCP_NODELAY，该参数的使用与Nagle算法有关
Nagle算法是将小的数据包组装为更大的帧然后进行发送，而不是输入一次发送一次,因此在数据包不足的时候会等待其他数据的到了，组装成大的数据包进行发送，虽然该方式有效提高网络的有效负载，但是却造成了延时
TCP_NODELAY参数的作用就是禁止使用Nagle算法，使用于小数据即时传输，于TCP_NODELAY相对应的是TCP_CORK，该选项是需要等到发送的数据量最大的时候，一次性发送
SO_REUSEADDR
对应于socket选项中的SO_REUSEADDR，这个参数表示允许重复使用本地地址和端口
如某个进程非正常退出，该程序占用的端口可能要被占用一段时间才能允许其他进程使用，而且程序死掉以后，内核一需要一定的时间才能够释放此端口，不设置SO_REUSEADDR就无法正常使用该端口
SO_LINGER
对应于套接字选项中的SO_LINGER，使用SO_LINGER可以阻塞close()的调用时间，直到数据完全发送
Linux内核默认的处理方式是当用户调用close方法的时候，函数返回，在可能的情况下，尽量发送数据，不一定保证<br>会发生剩余的数据，造成了数据的不确定性
ChannelFuture
常用方法
channel()
sync()
将当前线程阻塞等待处理结果<br>
get()、await()、cannel()<br>
addListener(GenericFutureListener)<br>
get的替代方案
removeListener(GenericFutureListener)
ChannelPromise
Promise是<font color="#c41230">可写</font>的Future，Future自身并没有写操作相关的接口，Netty通过Promise对Future进行扩展，用于设置I/O操作的结果
实现类
DefaultPromise
sync()
将当前线程阻塞等待处理结果
await()
setSuccess()、setFailure()<br>
trySuccess()、tryFailure()
ByteBuf
用法和NIO的Buffer一样
相关辅助类
ByteBufHoler
ByteBufUtil
Buffer和ByteBuf对比<br>
ByteBuffer长度固定，一旦分配完成，它的容量不能动态扩展和收缩，当我们对ByteBuffer进行 put操作的时候，如果缓冲区剩余可写空间不够，就会发生 BufferOverflowException异常。
ByteBuf进行 put操作的时候会对剩余可用空间进行校验。如果剩余空间不足，需要重新创建一个新的 ByteBuffer，并将之前的 ByteBuffer复制到新创建的 ByteBuffer中，最后释放老的 ByteBuffer，<br>
ByteBuffer只有一个标识位控的指针position,读写的时候需要手工调用flip()
ByteBuf通过两个位置指针来协助缓冲区的读写操作，读操作使用 readerIndex，写操作使用 writerIndex。随着数据的写入writerIndex会增加，读取数据会使 readerIndex增加，但是它不会超过 writerIndex。
选择Netty的理由
NIO的类库和API繁杂，使用麻烦，你需要熟练掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer等。<br>而Netty使用启动器封装了这些复杂的操作
NIO处理多条链路线程模型需要自己实现，Netty有高效的Reactor线程模型
IO线程处理多条链路，它的调试和跟踪非常麻烦，特别是生产环境我们无法进行有效的调试和跟踪，往往只能靠一些日志来辅助分析，定位难度很大
处理网络的闪断、客户端的重复接入、客户端的安全认证、消息的编解码、半包读写
功能强大，预置了多种编解码功能，支持多种主流协议； <br>
灵活的TCP参数配置能力
Netty提供了自己的Channel和其子类实现，不受JVM厂家标准限制，扩展性强
Netty为了解决ByteBuffer的缺陷，重写了一个新的数据接口ByteBuf，新增了高级和实用的特性
定制能力强，可以通过ChannelHandler对通信框架进行灵活地扩展； <br>
Netty修复了已经发现的所有JDK NIO BUG，业务开发人员不需要再为NIO的BUG而烦恼； <br>
社区活跃，版本迭代周期短，发现的BUG可以被及时修复，同时更多的新功能会加入；
网络事件
典型的网络事件
链路注册、链路激活、链路断开、链路发生异常
接收到请求消息、请求消息接收并处理完毕
发送应答消息
发生用户自定义事件
Netty事件
事实上inbound和outbound事件是Netty自身根据事件在pipeline中的<font color="#c41230">流向</font>抽象出来的术语，事件在pipeline中得到传播和处理，它是事件处理的总入口。
inbound事件
通常由<font color="#c41230">I/O线程</font>触发，例如TCP链路建立事件、链路关闭事件、读事件、异常通知事件等
Inbound 事件是通知事件, 当某件事情已经就绪后, 通知上层。
Inbound事件发起者是unsafe，默认的处理者是 TailContext, 并且其处理方法是空实现
Inbound 事件在 Pipeline 中传输方向是 headContext -> tailContext
outbound事件
通常是由<font color="#c41230">用户</font>主动发起的网络I/O操作，例如用户发起的连接操作、绑定操作、消息发送等操作
Outbound 事件是请求事件(由 Connect 发起一个请求, 并最终由 unsafe 处理这个请求)
Outbound 事件的发起者是 Channel，Outbound 事件的处理者是 unsafe
Outbound 事件在 Pipeline 中的传输方向是 tailContext -> headContext
高性能
IO线程模型<br>
2种fd
listenfd
一般情况只有一个，用来监听一个特定的端口(如8080)
connfd
每个连接都会打开一个connfd，用来收发数据
3种事件
listenfd进行accept阻塞监听，创建一个connfd
用户态内核态之间copy数据。每个connfd对应着2个应用缓冲区：readbuf和writebuf
处理connfd发来的数据，进行业务逻辑处理，准备response到writebuf
客户端请求的5个阶段
read
接收到请求，读取数据
decode
解码数据
compute
业务逻辑处理
encode
返回数据编码
send
发送数据
其中，以read和send阶段IO最为频繁
Reactor
Reactor模型基于事件驱动，来了事件我通知你，你来处理
三种角色
Reactor
事件监听和响应主线程，通过Select监控客户端请求事件，收到事件后进行dispatch分发<br>
如果是<font color="#c41230">连接</font>事件，由acceptor线程接受连接<br>
如果是<font color="#c41230">读写</font>事件，分发给事件绑定函数Handler处理
Acceptor
接受客户端新连接，创建新的SocketChannel将其注册到Reactor主线程的selecor上，并创建事件响应函数handler处理后续事件
Handler
事件响应函数，完成channel的读取数据，完成处理业务逻辑后，负责将结果写入channel发送给客户端
可用资源池来管理
三种Reactor线程模型
单Reactor单线程模型
Reactor单主线程所有事件的响应，如果是<font color="#c41230">连接事件</font>分发给Acceptor线程处理，如果是<font color="#c41230">读写</font>事件则Reactor单主线程完成整个Handler处理<br>
理论上一个Reactor主线程可以独立处理所有IO相关的操作，但一个NIO线程同时处理成百上千的链路，会导致该线程负载过重，处理速度将变慢，性能上无法支撑<br>
Redis使用单Reactor单进程的模型
单Reactor多线程模型
相对于第一种模型来说，Reactor主线程在获取到IO的读写事件之后从channel中<font color="#c41230">read</font>数据，处理业务逻辑交由<font color="#c41230">Worker线程池</font>来处理(decode-compute-encode)，handler收到Worker线程响应后通过<font color="#c41230">send</font>将响应结果返回给客户端。这样可以降低Reactor主线程的性能开销，从而更专注的做事件分发工作了，提升整个应用的吞吐。<br>
Reactor单主线程虽然只承担所有事件的监听和响应，不承担业务逻辑处理，只要是单线程可能会存在性能问题
主从Reactor多线程模型
比起第二种模型，它是将Reactor分成两部分mainReactor和subReactor
mainReactor
负责监听server socket，用来处理网络IO连接建立操作，将建立的socketChannel指定注册给subReactor
从mainReactor线程池中随机选择一个Reactor线程作为acceptor线程，用于绑定监听端口，接收客户端连接
acceptor线程接收客户端连接请求之后创建新的SocketChannel，将其注册到mainReactor线程池的其它Reactor线程上，由其负责接入认证、IP黑白名单过滤、握手等操作
业务层的链路正式建立，将SocketChannel从主线程池的Reactor线程的多路复用器上摘除，重新注册到subReactor线程池的线程上
创建一个Handler用于下面处理其它读写事件
subReactor
主要做和建立起来的socket做数据交互和事件业务处理操作，通常subReactor个数上可与CPU个数等同
当有新的事件发生时，SubReactor会调用已创建的Handler进行响应
Handler通过read从channel读取数据后，会分发给后面的Worker线程池进行业务处理
Worker线程池会分配独立的线程完成真正的业务处理，如何将响应结果返回给Handler进行处理
Handler收到响应结果后通过Send将响应结果返回给Client
Nginx、Swoole、Memcached和Netty都是采用这种实现
Proactor
来了事件我来处理，处理完了我通知你
理论上proactor比Reactor效率要高一些，异步IO能够充分利用DMA特性，让IO操作与计算重叠，但是实现真正的异步IO,操作系统需要做大量的工作<br>
目前Window下通过IOCP实现了真正的异步IO，而在Linux系统下的AIO并不完善，因此在Linux下实现高并发网络编程时都是以Reactor模式为主
多线程
无锁化的串行设计的
NioEventLoop读取到消息之后，直接调用 ChannelPipeline的 fireChannelRead（ Object msg），只要用户不主动切换线程，一直会由 NioEventLoop调用到用户的 Handler，期间不进行线程切换。这种串行化处理方式避免了多线程操作导致的锁的竞争，从性能角度看是最优
高效的并发编程
volatile的大量、正确使用
CAS和原子类的广泛使用
线程安全容器的使用
通过读写锁提升并发性能
高性能的序列化框架
Netty默认提供了对 Google Protobuf的支持，用户通过扩展 Netty的编解码接口，可以实现其他的高性能序列化框架，例如 Thrift
零拷贝
Netty的接收和发送 ByteBuffer采用 DIRECT BUFFERS，使用堆外直接内存进行 Socket读写
实现 CompositeByteBuf，它对外将多个 ByteBuf封装成一个 ByteBuf
Netty文件传输类 DefaultFileRegion通过 transferTo方法将文件发送到目标 Channel中
可靠性
网络通信类故障
客户端连接超时
创建连接超时定时任务之后，会由NioEventLoop负责执行。如果已经连接超时，但是服务端仍然没有返回 TCP握手应答，则关闭连接。
设置完连接超时之后， Netty在发起连接的时候，会根据超时时间创建 ScheduledFuture挂载在 Reactor线程上，用于定时监测是否发生连接超时。 <br>
Netty的客户端连接超时参数与其他常用的 TCP参数一起配置，使用起来非常方便，上层用户不用关心底层的超时实现机制。这既满足了用户的个性化需求，又实现了故障的分层隔离。
通信对端强制关闭
连接网络闪断、对方进程突然宕机或者其他非正常关闭链路事件时，TCP链路就会发生异常。
由于 TCP是全双工的，通信双方都需要关闭和释放 Socket句柄才不会发生句柄的泄漏。
Netty底层已经自动对该故障进行了处理，及时关闭了句柄
链路正常关闭
对于短连接协议，例如HTTP协议，通信双方数据交互完成之后，通常按照双方的约定由服务端关闭连接，客户端获得TCP连接关闭请求之后，关闭自身的 Socket连接，双方正式断开连接
在实际的NIO编程过程中，经常存在一种误区：认为只要是对方关闭连接，就会发生 IO异常，捕获 IO异常之后再关闭连接即可。实际上，连接的合法关闭不会发生 IO异常，它是一种正常场景，如果遗漏了该场景的判断和处理就会导致连接句柄泄漏。
定制I/O故障
客户端的断连重连机制
消息的缓存重发
接口日志中详细记录故障细节
运维相关功能，例如告警、触发邮件/短信等
链路有效性检测
链路有效性检测需要周期性的心跳对链路进行有效性检测，一旦发生问题，可以及时关闭链路，重建TCP连接
心跳检测机制
心跳检测的目的就是确认当前链路可用，对方活着并且能够正常接收和发送消息。做为高可靠的NIO框架， Netty也提供了心跳检测机制，下面我们一起熟悉下心跳的检测原理
三种层面的心跳
TCP层面的心跳检测，即 TCP的 Keep - Alive机制，它的作用域是整个 TCP协议栈
协议层的心跳检测，主要存在于长连接协议中。例如SMPP协议
应用层的心跳检测，它主要由各业务产品通过约定方式定时给对方发送心跳消息实现
Netty心跳机制
Netty的心跳检测实际上是利用了链路空闲检测机制实现
空闲检测机制
读空闲超时
链路持续时间t没有读取到任何消息
写空闲超时
链路持续时间t没有发送任何消息
读写空闲超时
链路持续时间t没有接收或者发送任何消息
两种心跳检测
Ping - Pong型心跳
由通信一方定时发送 Ping消息，对方接收到 Ping消息之后，立即返回 Pong应答消息给对方，属于<font color="#c41230">请求 - 响应型心跳</font>
Ping - Ping型心跳
不区分心跳请求和应答，由通信双方按照约定定时向对方发送心跳 Ping消息，它属于<font color="#c41230">双向心跳</font>
内存保护机制
链路总数的控制
每条链路都包含接收和发送缓冲区，链路个数太多容易导致内存溢出
单个缓冲区的上限控制
防止非法长度或者消息过大导致内存溢出
消息解码的时候，对消息长度进行判断，如果超过最大容量上限，则抛出解码异常，拒绝分配内存
缓冲区内存释放
防止因为缓冲区使用不当导致的内存泄露
为了防止因为用户遗漏导致内存泄漏，Netty在Pipe line的TailHandler中自动对内存进行释放
NIO消息发送队列的长度上限控制<br>
Netty的 NIO消息发送队列 ChannelOutboundBuffer并没有容量上限控制，它会随着消息的积压自动扩展，直到达到 0x7fffffff
通过启动项的ChannelOption设置发送队列的长度，或者通过 - D启动参数配置该长度
流量整形
流量整形（ Traffic Shaping）是一种主动调整流量输出速率的措施。一个典型应用是基于下游网络结点的 TP指标来控制本地流量的输出
流量整形对流量监管中需要丢弃的报文进行缓存——通常是将它们放入缓冲区或队列内，也称流量整形
流量整形原理是对每次读取到的ByteBuf可写字节数进行计算，获取当前的报文流量，然后与流量整形阈值对比。如果已经达到或者超过了阈值。则计算等待时间delay，将当前的ByteBuf放到定时任务Task中缓存，由定时任务线程池在延迟delay之后继续处理该ByteBuf
流量整形与流控的最大区别在于流控会拒绝消息，流量整形不拒绝和丢弃消息，无论接收量多大，它总能以近似恒定的速度下发消息，跟变压器的原理和功能类似
流量整形有两个作用
防止由于上下游网元性能不均衡导致下游网元被压垮，业务流程中断
防止由于通信模块接收消息过快，后端业务线程处理不及时导致的”撑死”问题
流量整形分类
全局流量整形
它的作用域针对所有的Channel
单链路流量整形
单链路流量整形与全局流量整形的最大区别就是它以单个链路为作用域，可以对不同的链路设置不同的整形策略
优雅停机接口
Java的优雅停机通常通过注册 JDK的 ShutdownHook来实现，当系统接收到退出指令后，首先标记系统处于退出状态，不再接收新的消息，然后将积压的消息处理完，最后调用资源回收接口将资源销毁，最后各线程退出执行
通常优雅退出有个时间限制，例如 30S，如果到达执行时间仍然没有完成退出前的操作，则由监控脚本直接 kill - 9 pid，强制退出
0 条评论
下一页
