Netty 1. 领域知识点

最新推荐文章于 2024-07-11 03:29:05 发布

FINYIE

最新推荐文章于 2024-07-11 03:29:05 发布

阅读量209

点赞数

分类专栏：网络文章标签：网络 tcp/ip java

本文链接：https://blog.csdn.net/finyie/article/details/125428864

版权

网络专栏收录该内容

4 篇文章 0 订阅

订阅专栏

1.1 如何切换三种I/O模式

阻塞与非阻塞：
数据就绪前是否等待：
阻塞：没有数据传过来时，读会阻塞知道有数据；缓冲区满时，写操作也会阻塞，非阻塞遇到上述情况都是直接返回
同步与异步：
数据就绪后，数据操作谁完成：
数据就绪后自己读是同步，数据就绪直接读好在回调给程序是异步
netty对三种I/O模式的支持：
NioEventLoopGroup EpollEventLoopGroup
NioEventLoop EpollEventLoop
NioServerSocketChannel EpollServerSocketChannel 工厂模式+泛型+反射
NioSocketChannel EpollSocketChannel
为什么服务器开发不需要切换客户端对应NioSocketChannel
SeverSocketChannel负责创建对应的SocketChannel

1.2 如何支持三种Reactor

Reactor 是一种开发模式，模式的核心流程：注册感兴趣的事件->扫描是否有感兴趣的事件发生->事件发生后做出相应的处理
clent/Server -> SocketChannel/ServerSocketChannel -> OP_ACCEPT/OP_CONNECT/OP_WRITE/OP_READ
client socketChannel y y y
server ServerSocketChannel y
server SocketChannel y y
三种版本：
Thread-Per-Connection模式：
单线程 EventLoopGroup eventGroup = new NioEventLoopGroup(1)
多线程 EventLoopGroup eventGroup = new NioEventLoopGroup()
主从多线程 EventLoopGroup bossGroup = new NioEventLoopGroup()
EventLoopGroup workerGroup = new NioEventLoopGroup()
Netty 如何支持主从Reactor模式：
Netty的main reator大多并不能用到一个线程组
Netty给Channel分配NIO event loop的规则是什么
通用模式的NIO实现多路复用器怎么跨平台

1.3 TCP 粘包/半包

什么时粘包和半包
发送:ABC DEF
接收：ABCDEF AB CD EF
- 粘包的主要原因：
  发送方每次写入数据 < 套接字缓冲区大小
  接收方读取套接字缓冲区数据不够及时
- 半包：
  发送方写入数据 > 套接字缓冲区大小
  发送的数据大于协议的MTU(Maximum Transmission Unit, 最大传输单元) 必须拆包
- 收发：一个发送可能被多次接收，多个发送可能被一次接收
- 传输：一个发送可能占用多个传输包，多个发送可能公用一个传输包
- 根本原因：TCP是流式协议，消息无边界
  UDP像邮寄的包裹，虽然一次运输多个，但每个包裹都有“界限”，一个一签收，所以无粘包，半包问题
- 解决问题：
  找出消息的边界：
  tcp 改成短连接，一个请求一个短连接：
  封装成帧：固定长度满足固定长度即可空间浪费
  分割符之间空间不浪费内容本省出现分隔符时需要转义，所以需要扫描内容
  精确定位用户数据长度理论上有限制，需提前预知可能的最大长度，从而定义长度占用字节数
  Netty对三种封帧的支持：
  固定长度 FixedLengthFrameDecoder
  分割符 DelimiterBasedFrameDecoder
  固定长度字段内存内容的长度信息 LengthFieldBasedFrameDecoder 解码：LengthFieldPrepender
源码解析：
解码核心工作流程：
解码中两种数据积累器(Cumulator)的区别：
三种解码器的常用额外控制参数

1.4 常用的“二次”编解码方式

为什么需要二次编解码
解决粘包，半包问题的编解码器位一次编解码，结果是字节，需要和项目中所使用的对象做转化，称为二次编解码
一次解码器：ByteToMessageDecodre io.netty.buffer.ByteBuf(原始数据流) -> io.netty.buffer.ByteBuf(用户数据)
二次解码器：MessageToMessageDecoder io.netty.buffer.ByteBuf(用户数据) -> Java Object
常用的二次编解码方式
一步到位：耦合性高，不容易置换方案
Java序列化 Marshaling XML JSON MessagePack Protobuf
选择编解码方式的要点
空间：编码后占用空间
时间：编解码速度
是否追求可读性多语言支持
Protobuf简介与使用
Protobuf是一个灵活的，高效的用于序列化数据的协议
相比较XML和JSON格式，Protobuf更小，更快，更便捷
Netty对二次编解码的支持
Protobuf编解码如何使用及原理
自带那些编解码
io.netty.handler.codec.base64/bytes/compression/json/marshalling/protoburf/serialization/string/xml

1.5 keepalive 与 idle 监测

为什么需要keepalive和Idle
服务器应用问题：
对端异常“崩溃”
对端在，但处理不过来
对端在，但不可达
后果：连接已坏，但是还在浪费资源维持，下次直接用会报错
如何设计keepalive，以TCP keepalive为例：
TCP keepalive核心参数：
#sysctl -a | grep tcp_keepalive
net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75
net.ipv4.tcp_keepalive_probes=9
注释：当启用(默认关闭)keepalive时，TCP在连接没有数据通过的7200秒后发送keepalive消息，当探测没有确认时，按75秒的重试频率重发，一直发9个探测包都没有确认，就认定连接失效
总耗时：7200秒 + 75秒 * 9次
为什么需要应用层keepalive：
协议分层，各层关注点不同：
传输层关注是否“通”，应用层关注是否可服务
TCP层的keepalive默认关闭，且经过路由等中转设备keepalive包可能会被丢弃
TCP层的keepalive事件太长，默认>2小时，虽然可改，但属于系统参数，改动影响所有应用
http属于应用层，http keep-alive指的是堆长连接和短连接的选择
Idle监测，只是负责诊断，诊断后做出不同的行为，决定Idle监测的最终用途：
发送keepalive：一般用来配合keepalive，减少keepalive消息
keepalive设计：V1定时keepalive消息 -> V2 空闲监测 + 判定位Idle时才发keepalive
直接关闭连接
快速释放损坏的，恶意的，很久不用的连接，让系统时刻保持最好的状态
简单粗暴，客户端可能需要重连
结合使用，按需keepalive，保证不会空闲，如果空闲，关闭连接

1.6 Netty 的 “锁”

分析同步问题的核心三要素：
原子性可见性有序性
锁的分类
对竞争的态度：
乐观锁(java.util.concurrent包中的原子类) 与悲观锁(Synchronized)
等待锁是否公平：公平锁(new ReentrantLock(true)) 与非公平锁new ReentrantLock()
是否可以共享：共享锁与独享锁：ReadWriteLock，其读锁是共享锁，其写锁是独享锁
Netty锁的5个关键点
- 1.在意锁的对象和范围 ->减少粒度
  初始化channel(io.netty.bootstrap.ServerBootstrap#init)
  Synchronized method -> Synchronized block
- 2.注意锁的对象本身大小 ->减少空间占用
  统计待发送的字节数(io.netty.channel.ChannelOutboundBuffer
  AtomicLong -> Volatile long + AtomicLongFieldUpdater)
  AtomicLong & Long：
  前者是一个对象，包含对象头(object header)以用来保存hashcode lock等信息，32位系统占用8字节 64位系统占16字节
- 3.注意锁的速度 ->提高速度
  记录内存分配字节数等功能用到的LongCounter(io.netty.util.internal.PlatformDependent#newLongCountre())
  高并发时:java.util.concurrent.atomic.AtomicLong -> java.util.concurrent.atomic.LongAdder
  ConcurrentHashMap
- 4.不同场景选择不同的并发类 ->因需而变
  关闭和等待关闭事件执行器(Event Executor)
  Object.wait/notify -> CountDownLatch
  io.netty.util.concurrent.SingleThreadEventExecutor#threadLock
  Nio Event loop中负责存储task的Queue
  Jdk’s LinkedBlockingQueue(MPMC) -> jctool’s MPSC
  io.netty.util.internal.PlatformDependent.Mpsc$newMpscQueue(int):
- 5.衡量好锁的价值 ->能不用则不用
  局部串行：Channel的I/O请求处理Pipeline是串行的
  整体并行：多个串行化的线程NioEventLoop
  Netty应用场景下：局部串行+整体并行 > 一个队列+多个线程模式
  降低开发难度，逻辑简单，提升处理性能
  避免锁带来的上下文切换和并发保护等额外开销
  避免用锁：用ThreadLocal来避免资源争用，Netty轻量级线程池实现
  io.netty.util.Recycler#threadLocal

1.7 Netty 内存使用

内存使用技巧的目标
内存占用少
应用速度快
对Java而言减少Full GC 的STW(Stop the world)
减小对象本省大小
用基本类型就不用包装类
应该定义成类变量就不要定义成实例变量
io.netty.channel.ChannelOutboundBuffer 统计待写的请求的字节数
对分配内存进行预估
对于已经可以预知固定size的HashMap避免扩容可以提前计算好初始size或者直接使用：
com.google.common.collect.Maps#newHashMapWithExpectedSize
Netty根据接收到的数据动态调整(guess)下个要分配的Buffer的大小
io.netty.channel.AdaptiveRevcByteBufAllocator
Zero-Copy
使用逻辑组合，代替实际复制
COmpositeByteBuf
io.netty.handler.codec.ByteToMessageDecoder#COMPOSITE_CUMULATOR
使用包装，代替实际复制
byte[] bytes = data.getBytes();
ByteBuf byteBuf = Unpolled.wrappedBuffer(bytes)
调用JDK的zero-copy接口：
Netty中也通过在DefaultFileRegion中包装了NIO的FileChannel.transferTo()方法实现了零拷贝
io.netty.channel.DefaultFileRegion#transferTo
堆外内存
JVM内部 -> 堆(heap) + 非堆(non heap)
JVM外部 -> 堆外(off heap)
优点：更广阔的空间破除堆空间限制，减轻GC压力
减少冗余细节避免复制
缺点：创建速度慢
堆外内存收操作系统管理
内存池
为什么引入:
创建对象开销大
对象高频创建且可复用
支持并发又能保护系统
维护共享有限的资源
如何实现：
Apache Commons Pool
Netty轻量级对象池实现 io.netty.util.Recycler
源码解读：
怎么从堆外存切换到堆内使用
参数设置：io.netty.noPreferDirect = true;
传入构造参数：new UnpolledByteBufAllocator(false);
堆外存的分配本质
ByteBuffer.allocateDirect(initialCapacity)
内存池/非内存池的默认选择及切换方式
io.netty.channel.DefaultChannelConfi#allocator
内存池实现 (以PooledDirectByteBuf为例)
io.netty.buffer.PooledDirectByteBuf