Cover_sky的博客

LT(level_triggered,水平触发):当被监控的文件描述符上有可读写事件发生时，epoll_wait()会通知处理程序去读写。如果这次没有把数据一次性全部读写完，那么下次调用epoll_wait()时，它还会通知你在上一个没读写完的文件描述符上继续读写，当然如果你一直不去读写，它会一直通知你ET(Edge_triggered,边缘触发):当被监控的文件描述符上有可读写事件发生时，epoll_wait()会通知处理程序去读写。

PooledByteBuf是池化的ByteBuf，提高了内存分配与释放的速度，它本身是一个抽象泛型类，有三个子类:PooledDirectByteBuf、PooledHeapByteBuf、PooledUnsafeDirectByteBuf.

如果要支持百万长连接，需要有很多的工作要做。

对Selector的select操作周期进行统计，每完成一次空的select操作进行一次技术，若在某个周期内连续发生N次空轮询，则触发了epoll死循环bug.重建Selector,判断是否是其他线程发起的重建请求，若不是则将原SocketChannel从旧的Selector上去除注册，重新注册到新的Selector上，并将原来的Selector关闭，NioEventLoop的select方法中。例如臭名昭著的epoll bug，它会导致Selector空轮询，最终导致CPU 100%,

消息定义包含两部分：消息头+消息体。在消息的定义上，因为是同步处理模式，不考虑应答消息需要填入请求消息ID,所以消息头中只有一个消息的ID,如果要支持异步模式，则请求消息头和应答消息头最好分开设计，应答消息头中除了包含本消息的ID外，好应该包括请求消息ID,以方便请求消息的发送方,根据请求消息ID做对应的业务处理Netty消息定义表消息头定义(Header)

引导一个客户端只需要一个EventLoopGroup，但是一个ServerBootstrap则需要两个(也可以是同一个实例)，因为服务器需要两组不同的Channel，第一组将只包含一个ServerChannel,代表服务器自身的已绑定到某个本地端口的正在监听的套接字。而第二组将包含所有已创建的用来传入客户端连接(对于每个服务器已经接受的连接都有一个)的Channel.与ServerChannel相关联的EventLoopGroup将分配一个负责为传入连接请求创建Channel的EventLoop。

有一些适配器类可以将编写自定义的ChannelHandler所需要的工作降到最低限度，因为它们提供了定义在对应接口中的所有方法的默认实现。因为有时会忽略那些不感兴趣的事件，所以Netty提供了抽象积累ChannelInboundHandlerAdapter(处理入站)和ChannelOutboundHandlerAdapter(处理出站)的基本实现，通过扩展抽象类ChannelHandlerAdapter，

ChannelHandlerContext有很多的方法，其中一些方法也存在于Channel和ChannelPipeline本身上，但是有一点重要的不同，如果调用Channel或者ChannelPipeline上的这些方法，它们将沿着整个。而调用位于ChannelHandlerContext上的相同的方法，则将从当前所关联的ChannelHandler开始，并且只会传播给位于该ChannelPipeline中的下一个(入站下一个，出站上一个)能够处理该事件的ChannelHandler。

Netty能区分入站事件的Handler和出站的Handler，并确保数据只会在具有相同定向的两个ChannelHandler之间传递在编写Netty应用程序时要注意，分属出站和入站不同的Handler，在业务没有特殊要求的情况下是无所谓顺序的，比如压缩(出)Handler可以放在解压(入)Handler和解密(入)Handler中间，也可以放在解密(入)Handler和授权之间。而同属一个方向的Handler则是有顺序的，因为上一个Handler处理的结果往往是下一个Handler的要求的输入。

ChannelOption.SO_BACKLOG对应的是tcp/ip协议listen函数中的backlog参数，服务端处理客户端连接请求是顺序处理的，所以同一时间只能处理一个客户端连接，多个客户端来的时候，服务端将不能处理的客户端连接请求放在队列中等待处理。所以操作系统里一般有两个队列，一个是ACCEPT队列，保存着已经完成了TCP的三次握手的连接，一个SYN队列，服务器正在等待TCP的三次握手完成的队列。

EventLoop–控制流、多线程处理、并发ChannelFuture–异步通知Channel和EventLoop关系如图:我们可以看出Channel需要被注册到某个EventLoop上，在Channel整个声明周期内部都由这个EventLoop处理IO事件，也就是说一个Channel和一个EventLoop进行了绑定，但是一个EventLoop可以同时被多个Channel绑定。

Bootstrap是Netty框架的启动类和主入口类，发呢为客户端类Bootstrap和服务器类ServerBootstrap两种。

前言前面我们已经介绍了，使用JDK原生自带的Socket门面模式手写了注册中心、远程客户端、远程服务端三个模块来构成一个RPC框架，但是性能不是很高，远远无法支撑起大型的分布式系统之间的调用，于是我们今天来分享下如何用Netty来手写RPC框架，并用它来支撑起百万并发，为了便于理解，暂时先不实现注册中心。在该项目中还跟Spring进行了整合。结构示意图核心组件LengthFieldBasedFrameDecoder:解决网络传输中的粘包半包问题KryoEncoder/Decoder:负责网络数

1.我们在当前项目中的序列化框架选择是JDK自带的序列化，注意，你这个时候不能给上面提到的实体类添加唯一的serialId，否则通信过程中则将视为不一样的对象，导致序列化失败，还有就是要注意自己的目录结构，因为如果客户端和服务端中的实体类目录结构不一样，也是不行的，在实际业务中，往往会抽成一个公共的服务来使用，这里为了简洁2.网络通信模型采用的也是JDK自带的Socket模式，它是阻塞式的，它式无法支撑高并发的网络连接的如果需要这个项目源码的，可以在下方评论。

早期的网络编程中，需要花费大量的事件取学习复杂的C语言套接字库，去兼容不同的操作系统。假如你的系统要支撑高并发的用户场景，你可能会进行搜索如何搭建高性能的Java网络编程，你可能会看到Netty是一款异步的事件驱动的网络应用程序框架，支持快速地开发可维护的高性能的面向协议的服务器和客户端。高性能系统不仅要求超一流的编程技巧，还需要几个复杂领域(网络编程、多线程处理和并发)的专业知识，Netty优雅地处理了这些领域的知识，使得我们可以将精力放在业务处理上，而不是关注网络编程方便的非业务逻辑。

说到网络通信就会牵涉到数据的序列化与反序列化，现如今序列化框架也是层出不穷，比如FST、Kryo、ProtoBuffer、Thrift、Hessian、Avro、MsgPack等等，有的人可能会有疑问，为什么市面上有这么多框架，JDK不是已经有自带的Serializable序列化接口吗?很遗憾地说出这个事实，作为JDK自带地序列化机制，无论是在时间还是空间上的性能不尽人意，但凡时间或者空间上性能优越一点，也不至于让人诟病这么久。

首先安装好Protocol Buffer的编译器Protocol Buffer:version:2.6.1link: 链接直达根据电脑环境进行下载，Widnwos 32/64位就选择win32是没问题的，楼主亲测1.proto文件编写Person.protopublic class Person { String name; int id; String email;}syntax = "proto2";option java_outer_classname

我们直到在网络通信中客户端和服务端之间除了要传输数据外，还会进行简单的心跳应答通信，使得客户端和服务端的连接处于一种活跃状态，那么客户端可以发送ONE_WAY和TWO_WAY两种方式的处理，而服务端在处理这两种类型的数据时会做出不同的应答，对于ONE_WAY形式的应答，有可能会交由异步线程池来执行，而对于TWO_WAY形式的消息，则是立刻做出回应，除了这些，还会牵扯到序列化和反序列化、数据加密验证的问题，因为网络通信中数据是二进制流的形式传输的，这其中会牵扯到粘包/半包的问题，以及序列化和反序列性能问题。

如果你想实现http请求，需要把HttpServer中的SSL置为false，结果如下如果你想实现Https的请求，则将SSL的变量置为true,目前的代码中是没有支持客户端的SSL请求的，我们可以在postman或者chrome浏览器中查看由于我们的证书是自己设置的，所以chrome浏览器认为这个证书不是有效的，需要我们手动点击IDEA中会出现红色证书错误，暂时可以不用管，你还可以在postman的GET请求中添加body到此http的简易服务器就搭建好了。

对Netty中的粘包半包问题还不了解的童鞋，可以看看之前的Netty通信中的粘包半包问题(一到五)系列，以免产生不适如果你对Netty中的粘包半包问题已经熟悉了，可以直接阅读本文，本文主要介绍了消息头+消息体去解决粘包半包问题。

这期我们来分析下消息头+消息体的这种方式来实现完美的解决方案，当然这也是最复杂的一种实现，因为在大多数场景中，性能和复杂度始终不能兼得。代码中使用了MessagePack的第三方序列化，因为我们要传输的实体类对象在客户端和服务端之间要经过序列化和反序列化</</</</

前面我们介绍了特殊分隔符、以及固定长度，今天来介绍一下换行符分割，这种换行符是兼容了Windows和Linux的转义的，前提你的报文中没有换行符或者对换行符做特殊处理。

之前我们介绍了用特殊分隔符来分割每个报文，但是如果传输的数据中恰好有个特殊分隔符，它将会被拆分成多个，于是，为了进一步避免这个问题，还有一种解决方案是在两端的中用一个固定长度来区分，这样也可以解决粘包半包的问题。

我们在日常开发过程中，客户端和服务端的连接大多使用的是TCP协议,因为我们要保证数据的可靠传输，当网络中出现丢包时要求，要求数据包的发送端重传给接收端。而TCP是一种面向连接的传输层协议，当使用TCP进行传输时，客户端和服务端会各自维护两个缓冲区，它们分别是发送缓冲区、接收缓冲区，如图所示在网络传输过程中，虽然对要发送的数据包大小没有要求，但是TCP又不可能一次性的把数据全部加载到发送缓冲区中，这样会有可能撑爆TCP的发送缓冲区，比如说你要发送个1G的数据给服务端，TCP本身是不会。

在前面我们已经分析过Netty会出现的粘包半包问题，还没看过前面的博客的，可以先去看下之前写的博客解放方式:特殊分隔符解决,在每个报文后面加上一个特殊分隔符，以此来告诉服务端每个报文的数据结界是什么。