Netty 使用教程

https://www.cnblogs.com/hellozjf/p/15704443.html

参考教程

尚硅谷Netty视频教程（B站超火，好评如潮）

002.Netty是什么

1. Netty 是由 JBOSS 提供的一个 Java 开源框架，现为 Github 上的独立项目
2. Netty 是一个异步的、基于事件驱动的网络应用框架，用以快速开发高性能、高可靠性的网络 IO 程序。
3. Netty 主要针对在 TCP 协议下，面向 Clients 端的高并发应用，或者 Peer to Peer 场景下的大量数据持续传输的应用。
4. Netty 本质是一个 NIO 框架，适用于服务器通讯相关的多种应用场景
5. 要彻底理解 Netty，需要先学习 NIO，这样我们才能阅读 Netty 的源码

同步

如上图所示，浏览器执行了请求1，只有响应2到来之后，才能进行后续的操作3

异步

浏览器发送请求之后，指定消息来到时的回调方法，这样即使消息没有返回也能去做其它的事情了

体系图

003.Netty的应用场景

互联网行业

1. 互联网行业：在分布式系统中，各个节点之间需要远程服务调用，高性能的 RPC 框架必不可少，Netty 作为异步高性能的通信框架，往往作为基础通信组件被这些 RPC 框架使用
2. 典型的应用有：阿里分布式服务框架 Dubbo 的 RPC 框架使用 Dubbo 协议进行节点间通信，Dubbo 协议默认使用 Netty 作为基础通信组件，用于实现各进程节点之间的内部通信

游戏行业

1. 无论是手游服务器还是大型的网络游戏，Java 语言得到了越来越广泛的应用
2. Netty 作为高性能的基础通信组件，提供了 TCP/UDP 和 HTTP 协议栈，方便定制和开发私有协议栈，账号登录服务器
3. 地图服务器之间可以方便的通过 Netty 进行高性能的通信

大数据领域

1. 经典的 Hadoop 的高性能通信和序列化组件（AVRO 实现数据文件共享）的 RPC 框架，默认采用 Netty 进行跨界点通信
2. 它的 Netty Service 基于 Netty 框架二次封装实现

其它

https://netty.io/wiki/related-projects.html

推荐书籍

《Netty In Action》

《Netty 权威指南》

004.IO模型

I/O 模型基本说明

1. I/O 模型简单的理解：就是用什么样的通道进行数据的发送和接收，很大程度上决定了程序通信的性能
2. Java 共支持 3种网络编程模型/IO 模式：BIO、NIO、AIO
3. Java BIO：同步并阻塞（传统阻塞型），服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，如果这个连接不做任何事情会造成不必要的线程开销
4. Java NIO：同步非阻塞，服务器实现模式为一个线程处理多个请求（连接），即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有 I/O 请求就进行处理
5. Java AIO（NIO.2）：异步非阻塞，AIO 引入异步通道的概念，采用了 Proactor 模式，简化了程序编写，有效的请求才启动线程，它的特点是先由操作系统完成后才通知服务端程序启动线程去处理，一般适用于连接数较多且连接时间较长的应用

使用场景分析

1. BIO 方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK 1.4 以前的唯一选择，但程序简单易理解
2. NIO 方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，弹幕系统，服务器间通讯等。编程比较复杂，JDK 1.4 开始支持。
3. AIO 方式适用于*连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用 OS 参与并发操作，编程比较复杂，JDK7 开始支持

005.BIO基本介绍

基本介绍

1. Java BIO 就是传统的 java io 编程，其相关的类和接口在 java.io
2. BIO（blocking I/O）：同步阻塞，服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，如果这个连接不做任何事情会造成不必要的线程开销，可以通过线程池机制改善（实现多个客户连接服务器）
3. BIO 方式适用于连接数目比较小且固定的架构，这种方式对服务器资源比较高，并发局限于应用中，JDK 1.4 以前的唯一选择，程序简单易理解

工作原理图

BIO 编程简单流程

1. 服务器端启动一个 ServerSocket
2. 客户端启动一个 Socket 对服务器进行通信，默认情况下服务器端需要对每个客户建立一个线程与之通讯
3. 客户端发出请求后，先咨询服务器是否有线程响应，如果没有则会等待，或者被拒绝
4. 如果有响应，客户端线程会等待请求结束后，才继续执行

应用实例

实例说明：

1. 使用 BIO 模型编写一个服务器端，监听 6666 端口，当有客户端连接时，就启动一个线程与之通讯
2. 要求使用线程池机制改善，可以连接多个客户端
3. 服务器端可以接收客户端发送的数据（telnet 方式即可）

代码示例：

com.hellozjf.project.study.netty.bio.BIOServer

问题分析

1. 每个请求都需要创建独立的线程，与对应的客户端进行数据 read，业务处理，数据 write
2. 当并发较大时，需要创建大量线程来处理连接，系统资源占用较大
3. 连接建立后，如果当前线程暂时没有数据可读，则线程就阻塞在 read 操作上，造成资源浪费

007. NIO基本介绍

基本介绍

1. Java NIO 全称 java non-blocking IO，是指 JDK 提供的新 API。从 JDK 1.4 开始，Java 提供了一系列改进的输入/输出的新特性，被统称为 NIO（即 New IO），是同步非阻塞的
2. NIO 相关类都被放在 java.nio 包及子包下，并且对原 java.io 包中的很多类进行改写
3. NIO 有三大核心部分：Channel（通道），Buffer（缓冲区），Selector（选择器）
4. NIO 是面向缓冲区，或者面向块编程的。数据读取到一个它稍后处理的缓冲区，需要时可在缓冲区中前后移动，这就增加了处理过程中的灵活性，使用它可以提供非阻塞的高伸缩性网络
5. Java NIO 的非阻塞模式，使一个线程从某通道发送请求或者读取数据，但是它仅能得到目前可用的数据，如果目前没有数据可用时，就什么都不会获取，而不是保持数据阻塞，所以直至数据变的可以读取之前，该线程可以继续做其他的事情。非阻塞写也是如此，一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情
6. 通俗理解：NIO 是可以做到用一个线程来处理多个操作的。假设有 10000 个请求过来，根据实际情况，可以分配 50 或者 100 个线程来处理。不像之前的阻塞 IO 那样，非得分配 10000 个
7. HTTP 2.0 使用多路复用的技术，做到同一个连接并发请求处理多个请求，而且并发请求的数量比 HTTP 1.1 大了好几个数量级

Buffer 介绍

参考代码

com.hellozjf.project.study.netty.nio.BasicBuffer

NIO 和 BIO 的比较

1. BIO 以流的方式处理数据，而 NIO 以块的方式处理数据，块 I/O 的效率比流 I/O 高很多
2. BIO 是阻塞的，NIO 是非阻塞的
3. BIO 基于字节流和字符流进行操作，而 NIO 基于 Channel（通道）和 Buffer（缓冲区）进行操作，数据总是从通道读取到缓冲区中，或者从缓冲区写入到通道中。Selector（选择器）用于监听多个通道的事件（比如：连接请求，数据到达等），因此使用单个线程就可以监听多个客户端通道

NIO 三大核心原理示意图

Selector、Channel、Buffer的关系

关系图的说明：

1. 每个 Channel 都会对应一个 Buffer
2. Selector 会对应一个线程，一个线程对应多个 Channel（连接）
3. 该图反应了有三个 Channel 注册到了该 Selector
4. 程序切换到哪个 Channel 是由事件决定，Event 就是一个重要的概念
5. Selector 会根据不同的事件，在各个通道上切换
6. Buffer 就是一个内存块，底层是有一个数组
7. 数据的读取写入是通过 Buffer，这个和 BIO 是由本质不同的，BIO 中那么是输入流，或者是输出流，不能双向。但是 NIO 的 Buffer 是可以读也可以写，需要 flip 方法切换
8. Channel 是双向的，可以反应底层操作系统的情况，比如 Linux，底层的操作系统通道就是双向的

缓冲区（Buffer）

基本介绍

缓冲区（Buffer）：缓冲区本质上是一个可以读写数据的内存块，可以理解是一个容器对象（含数组），该对象提供了一组方法，可以更轻松地使用内存块，缓冲区对象内置了一些机制，能够跟踪和记录缓冲区的状态变化情况。Channel 提供从文件、网络读取数据的渠道，但是读取或写入的数据必须经由 Buffer，如图：

Buffer 类及其子类

1. 在 NIO 中，Buffer 是一个顶层父类，它是一个抽象类，累的层级关系图
2. Buffer 类定义了所有的缓冲区都具有的四个属性，来提供关于其所包含的数据元素的信息
3. Buffer 类相关方法一览

ByteBuffer

从前面可以看出对于 Java 中的基本数据类型（boolean 除外），都有一个 Buffer 类型与之相对应，最常用的自然是 ByteBuffer 类（二进制数据），该类的主要方法如下：

通道（Channel）

基本介绍

1. NIO 的通道类似于流，但有些区别如下：

   • 通道可以同时进行读写，而流只能读或者只能写
   • 通道可以实现异步读写数据
   • 通道可以从缓冲读数据，也可以写数据到缓冲

2. BIO 中的 stream 是单向的，例如 FileInputStream 对象只能进行读取数据的操作，而 NIO 中的通道（Channel）是双向的，可以读操作，也可以写操作

3. Channel 在 NIO 中是一个接口

   public interface Channel extends Closeable
   

4. 常用的 Channel 类有：FileChannel、DatagramChannel、ServerSocketChannel（类似 ServerSocket） 和 SocketChannel（类似 Socket）

5. FileChannel 用于文件的数据读写，DatagramChannel 用于 UDP 的数据读写，ServerSocketChannel 和 SocketChannel 用于 TCP 的数据读写

FileChannel 类

FileChannel 主要用来对本地文件进行 IO 操作，常见的方法有

1. public int read(ByteBuffer dst)，从通道读取数据，并放到缓冲区中
2. public int write(ByteBuffer src)，把缓冲区的数据写到通道中
3. public long transferFrom(ReadableByteChannel src, long position, long count)，从目标通道中复制数据到当前通道
4. public long transferTo(long position, long count, WritableByteChannel target)，把数据从当前通道复制到目标通道

参考代码

com.hellozjf.project.study.netty.nio.NIOFileChannel01
com.hellozjf.project.study.netty.nio.NIOFileChannel02
com.hellozjf.project.study.netty.nio.NIOFileChannel03
com.hellozjf.project.study.netty.nio.NIOFileChannel04

关于 Buffer 和 Channel 的注意事项和细节

1. ByteBuffer 支持类型化的 put 和 get，put 放入的是什么数据类型，get 就应该使用相应的数据类型来取出，否则可能会有 BufferUnderflowException 异常。参考代码com.hellozjf.project.study.netty.nio.NIOByteBufferPutGet
2. 可以将一个普通 Buffer 转成只读 Buffer。参考代码com.hellozjf.project.study.netty.nio.ReadOnlyBuffer
3. NIO 还提供了 MappedByteBuffer，可以让文件直接在内存（堆外的内存）中进行修改，而如何同步到文件由 NIO 来完成。参考代码com.hellozjf.project.study.netty.nio.MappedByteBufferTest
4. 前面我们讲的读写操作，都是通过一个 Buffer 完成的，NIO 还支持 通过多个 Buffer（即 Buffer 数组）完成读写操作，即 Scattering 和 Gatering。参考代码com.hellozjf.project.study.netty.nio.ScatteringAndGatheringTest

Selector（选择器）

基本介绍

1. Java 的 NIO，用非阻塞的 IO 方式。可以用一个线程，处理多个的客户端连接，就会使用Selector（选择器）
2. Selector 能够检测多个注册的通道上是否有事件发生（注意：多个 Channel 以事件的方式可以注册到同一个 Selector），如果有事件发生，便获取事件然后针对每个事件进行相应的处理。这样就可以只用一个单线程去管理多个通道，也就是管理多个连接和请求
3. 只有在连接真正有读写事件发生时，才会进行读写，就大大地减少了系统开销，并且不必为每个连接都创建一个线程，不用去维护多个线程
4. 避免了多线程之间的上下文切换导致的开销

特点说明

1. Netty 的 IO 线程 NioEventLoop 聚合了 Selector （选择器，也叫多路复用器），可以同时并发处理成百上千个客户端连接
2. 当线程从某客户端 Socket 通道进行读写数据时，若没有数据可用时，该线程可以进行其他任务
3. 线程通常将非阻塞 IO 的空闲时间用于在其它通道上执行 IO 操作，所以单独的线程可以管理多个输入和输出通道
4. 由于读写操作都是非阻塞的，这就可以充分提升 IO 线程的运行效率，避免由于频繁 I/O 阻塞导致的线程挂起
5. 一个 I/O 线程可以并发处理 N 个客户端连接和读写操作，这从根本上解决了传统同步阻塞 I/O —— 连接 —— 线程模型，架构的性能、弹性伸缩能力和可靠性都得到了极大的提升

类相关方法

Selector 类是一个抽象类，常用方法和说明如下：

注意事项

1. NIO 中的 ServerSocketChannel 功能类似于 ServerSocket，SocketChannel 功能类似于 Socket

2. selector 相关方法说明

   selector.select();    // 阻塞
   selector.select(1000);    // 阻塞1000毫秒，在1000毫秒后返回
   selector.wakeup();    // 唤醒selector
   selector.selectNow();    // 不阻塞，立马返回
   

NIO 非阻塞网络编程原理分析图

说明：

1. 当客户端连接时，会通过 ServerSocketChannel 得到对应的 SocketChannel
2. Selector 进行监听，select 方法，返回有事件发生的通道的个数
3. 将 SocketChannel 注册到 Selector 上，registor(Selector sel, int ops)，一个 Selector 上可以注册多个 SocketChannel
4. 注册后返回一个 SelectionKey，会和该 Selector 关联（集合）
5. 进一步得到各个 SelectionKey（有事件发生）
6. 再通过 SelectionKey 反向获取 SocketChannel channel()
7. 可以通过得到的 channel，完成业务处理
8. 代码撑腰

NIO 非阻塞网络编程快速入门

案例要求：

1. 编写一个 NIO 入门案例，实现服务器端和客户端之间的数据简单通讯（非阻塞）
2. 目的：理解 NIO 非阻塞网络编程机制

参考代码

com.hellozjf.project.study.netty.nio.NIOServer
com.hellozjf.project.study.netty.nio.NIOClient   

SelectionKey

1. SelectionKey，表示 Selector 和网络通道的注册关系，共四种：

   int OP_ACCEPT：有新的网络连接可以 accept，值为16
   int OP_CONNECT：代表连接已经建立，值为8
   int OP_READ：代表读操作，值为1
   int OP_WRITE：代表写操作，值为4
   源码中
   public static final int OP_READ = 1 << 0;
   public static final int OP_WRITE = 1 << 2;
   public static final int OP_CONNECT = 1 << 3;
   public static final int OP_ACCEPT = 1 << 4;
   

2. SelectionKey 相关方法

ServerSocketChannel

1. ServerSocketChannel 在服务器端监听新的客户端 Socket 连接
2. 相关方法如下

SocketChannel

1. SocketChannel，网络 IO 通道，具体负责进行读写操作。NIO 把缓冲区的数据写入通道，或者把通道里的数据读到缓冲区

2. 相关方法如下：

029.NIO群聊系统

实例要求

1. 编写一个 NIO 群聊系统，实现服务器端和客户端之间的数据简单通讯（非阻塞）
2. 实现多人群聊
3. 服务器端：可以监测用户上线，离线，并实现消息转发功能
4. 客户端：通过 channel 可以无阻塞发送消息给其它所有用户，同时可以接受其它用户发送的消息（由服务器转发得到）
5. 目的：进一步理解 NIO 非阻塞网络编程机制

步骤

1. 先编写服务器端
   1. 服务器启动并监听 6667
   2. 服务器接收客户端信息，并实现转发【处理上线和离线】
2. 编写客户端
   1. 连接服务器
   2. 发送消息
   3. 接收服务器端消息

033.NIO与零拷贝

零拷贝基本介绍

1. 零拷贝是网络编程的关键，很多性能优化都离不开
2. 在 Java 程序中，常用的零拷贝有 mmap（内存映射）和 sendFile。那么，它们在 OS 里，到底是怎么样的一个设计？我们分析 mmap 和 sendFile 这两个零拷贝
3. 另外我们看下 NIO 中如何使用零拷贝

提示，零拷贝从操作系统角度看，是没有 CPU 拷贝

传统 IO 数据读写

1. Java 传统 IO 和网络编程的一段代码

   File file = new File("test.txt");
   RandomAccessFile raf = new RandomAccessFile(file, "rw");
   
   byte[] arr = new byte[(int) file.length()];
   raf.read(arr);
   
   Socket socket = new ServerSocket(8080).accept();
   socket.getOutputStream().write(arr);
   

2. IO 示意图，蓝线是用户态，红线是内核态。
   其中 DMA（direct memory access），直接内存拷贝，不使用CPU。

   经过四次拷贝，三次状态切换

mmap优化

1. mmap 通过内存映射，将文件映射到内核缓冲区，同时，用户空间可以共享内核空间的数据。这样，在进行网络传输时，就可以减少内核空间到用户空间的拷贝次数

2. mmap示意图

   经过3次拷贝，3次状态切换

sendFile 优化

1. Linux 2.1 版本提供了 sendFile 函数，其基本原理如下：数据根本不经过用户态，直接从内核缓冲区进入到 SocketBuffer ，同时，由于和用户态完全无关，就减少了一次上下文切换

2. 示意图和小结
   经过3次拷贝，2次状态切换

3. Linux 在 2.4 版本中，做了一些修改，避免了从内核缓冲区拷贝到 Socket Buffer 的操作，直接拷贝到协议栈，从而再一次减少了数据拷贝。具体如下图和小结：
   这里其实还是有一次 CPU 拷贝的，kernel buffer -> socket buffer。但是拷贝的信息很少，比如 length，offset，消耗少，可以忽略
   经过2次拷贝，2次状态切换

零拷贝的再次理解

1. 我们说零拷贝，是从操作系统的角度来说的。因为内核缓冲区之间，没有数据是重复的（只有 kernel buffer 有一份数据）
2. 零拷贝不仅仅带来更少的数据复制，还能带来其他的性能优势，例如更少的上下文切换，更少的 CPU 缓存伪共享以及无 CPU 校验和计算

mmap 和 sendFile 的区别

1. mmap 适合小数据量读写，sendFile 适合大文件传输
2. mmap 需要 3 次上下文切换，3 次数据拷贝；sendFile 需要 2 次上下文切换，最少 2 次数据拷贝
3. sendFile 可以利用 DMA 方式，减少 CPU 拷贝，mmap 则不能（必须从内核拷贝到 Socket 缓冲区）

NIO 零拷贝案例

案例要求：

1. 使用传统的 IO 方式传递一个大文件
2. 使用 NIO 零拷贝方式传递（transferTo）一个大文件
3. 看看两种传递方式耗时时间分别是多少

035.零拷贝AIO内容梳理

Java AIO 基本介绍

1. JDK 7 引入了 Asynchronous I/O，即 AIO。在进行 I/O 编程中，常用到的两种模式：Reactor 和 Proactor。Java 的 NIO 就是 Reactor，当有事件触发时，服务器端得到通知，进行相应的处理
2. AIO 即 NIO 2.0，叫做异步不阻塞的 IO。AIO 引入异步通道的概念，采用了 Proactor 模式，简化了程序编写，有效的请求才启动线程，它的特点是先由操作系统完成后才通知服务端程序启动线程去处理，一般适用于连接数较多且连接时间较长的应用
3. 目前 AIO 还没有广泛应用，Netty 也是基于 NIO，而不是 AIO，因此我们就不详解 AIO 了，有兴趣的同学可以参考《Java 新一代网络编程模型 AIO 原理及 Linux 系统 AIO 介绍》Java新一代网络编程模型AIO原理及Linux系统AIO介绍-网络编程/专项技术区 - 即时通讯开发者社区!

BIO、NIO、AIO 对比表

	BIO	NIO	AIO
IO 模型	同步阻塞	同步非阻塞（多路复用）	异步非阻塞
编程难度	简单	复杂	复杂
可靠性	差	好	好
吞吐量	低	高	高

举例说明

1. 同步阻塞：到理发店理发，就一直等理发师，直到轮到自己理发
2. 同步非阻塞：到理发店理发，发现前面有其它人理发，给理发师说下，先干其它事情，一会过来看是否轮到自己
3. 异步非阻塞：给理发师打电话，让理发师上门服务，自己干其它事情，理发师自己来家里给你理发

036.Netty概述

原生 NIO 存在的问题

1. NIO 的类库和 API 繁杂，使用麻烦：需要熟练掌握 Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等
2. 需要具备其它的额外技能：要熟悉 Java 多线程编程，因为 NIO 编程涉及到 Reactor 模式，你必须对多线程和网络编程非常熟悉，才能编写高质量的 NIO 程序
3. 开发工作量和难度都非常大：例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络阻塞和异常流的处理等等
4. JDK NIO 的 Bug：例如臭名昭著的Epoll Bug，它会导致 Selector 空轮询，最终导致 CPU 100%。直到 JDK 1.7 版本该问题依旧存在，没有被根本解决。

Netty 官网说明

官网：Netty: Home

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients

1. Netty 是由 JBOSS 提供的一个 Java 开源框架。Netty 提供异步的、基于事件驱动的网络应用程序框架，用以快速开发高性能、高可靠性的网络 IO 程序
2. Netty 可以帮助你快速、简单的开发出一个网络应用，相当于简化和流程化了 NIO 的开发过程
3. Netty 是目前最流行的 NIO 框架，Netty 在互联网领域、大数据分布式领域、游戏行业、通信行业等获得了广泛的应用，知名的 Elasticsearch、Dubbo 框架内部都采用了 Netty

Netty 的优点

Netty 对 JDK 自带的 NIO 的 API 进行了封装，解决了上述问题

1. 设计优雅：适用于各种传输类型的统一 API 阻塞和非阻塞 Socket；基于灵活且可扩展的事件模型，可以清晰地分离关注点；高度可定制的线程模型 - 单线程，一个或多个线程池
2. 使用方便：详细记录的 JavaDoc，用户指南和示例；没有其他依赖项，JDK 5（Netty 3.x）或 6（Netty 4.x）就足够了
3. 高性能、吞吐量更高：延迟更低；减少资源消耗；最小化不必要的内存复制
4. 安全：完整的 SSL/TLS 和 StartTLS 支持
5. 社区活跃、不断更新：社区活跃，版本迭代周期短，发现的 Bug 可以被及时修复，同时，更多的新功能会被加入

Netty 版本说明

1. Netty 版本分为 netty 3.x 、netty 4.x 、netty 5.x
2. 因为 Netty 5 出现重大 bug，已经被官网废弃了，目前推荐使用的是 Netty 4.x 的稳定版本
3. 目前在官网可下载的版本 netty 3.x、netty 4.0.x 和 netty 4.1.x
4. 在本套课程中，我们讲解 Netty 4.1.x 版本
5. Netty 下载地址：Netty: Downloads

037.线程模型概述

线程模型基本介绍

1. 不同的线程模式，对程序的性能有很大影响，为了搞清 Netty 线程模式，我们来系统地讲解下各个线程模式，最后看看 Netty 线程模式有什么优越性
2. 目前存在的线程模型有：传统阻塞 I/O 服务模型，Reactor 模式
3. 根据 Reactor 的数量和处理资源池线程的数量不同，有 3 种典型的实现
   • 单 Reactor 单线程
   • 单 Reactor 多线程
   • 主从 Reactor 多线程
4. Netty 线程模式（Netty 主要基于主从 Reactor 多线程模型做了一定的改进，其中主从 Reactor 多线程模型有多个 Reactor）

传统阻塞 I/O 服务模型

工作原理图

黄色框表示对象，蓝色的框表示线程，白色的框表示方法（API）

模型特点

1. 采用阻塞 IO 模式获取输入的数据
2. 每个连接都需要独立的线程完成数据的输入，业务处理，数据返回

问题分析

1. 当并发数很大，就会创建大量的线程，占用很大的系统资源
2. 连接创建后，如果当前线程暂时没有数据可读，该线程会阻塞在 read 操作上，造成线程资源浪费

Reactor 模式

针对传统阻塞 I/O 服务模型的 2 个缺点，解决方案：

1. 基于 I/O 复用模型：多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象等待，无需阻塞等待所有连接。当某个连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理
   Reactor 对应的叫法：1. 反应器模式，2. 分发者模式（Dispatcher），3. 通知者模式（notifier）
2. 基于线程池复用线程资源：不必再为每个连接创建线程，将连接完成后的业务处理任务分配给线程进行处理，一个线程可以处理多个连接的业务

I/O 复用结合线程池，就是 Reactor 模式，基本设计思想，如图：

说明：

1. Reactor 模式，通过一个或多个输入同时传递给服务处理器的模式（基于事件驱动）
2. 服务器端程序处理传入的多个请求，并将它们同步分派到相应的处理线程，因此 Reactor 模式也叫 Dispatcher 模式
3. Reactor 模式使用 IO 复用监听事件，收到事件后，分发给某个线程（进程），这点就是网络服务器高并发处理的关键

核心组成

1. Reactor：Reactor 在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对 IO 事件做出反应。它就像公司的电话接线员，它接听来自客户的电话并将线路转移到适当的联系人
2. Handlers：处理程序执行 I/O 事件要完成的实际事件，类似于客户想要与之交谈的公司中的实际官员。Reactor 通过调度适当的处理程序来响应 I/O 事件，处理程序执行非阻塞操作

模式分类

根据 Reactor 的数量和处理资源池线程的数量不同，有 3 种典型的实现

1. 单 Reactor 单线程
2. 单 Reactor 多线程
3. 主从 Reactor 多线程

单 Reactor 单线程

工作原理示意图

方案说明

1. Select 是前面 I/O 复用模型介绍的标准网络编程 API，可以实现应用程序通过一个阻塞对象监听多路连接请求
2. Reactor 对象通过 Select 监听客户端请求事件，收到事件后通过 Dispatch 进行分发
3. 如果是建立连接请求事件，则由 Acceptor 通过 Accept 处理连接请求，然后创建一个 Handler 对象处理连接完成后的后续业务处理
4. 如果不是建立连接事件，则 Reactor 会分发调用连接对应的 Handler 来响应
5. Handler 会完成 Read -> 业务处理 -> Send 的完整业务流程

综合实例：服务器端用一个线程通过多路复用搞定所有的 IO 操作（包括连接，读、写等），编码简单，清晰明了，但是如果客户端连接数量较多，将无法支撑，前面的 NIO 案例就属于这种模型

方案优缺点分析

1. 优点：模型简单，没有多线程、进程通信、竞争的问题，全部都在一个线程中完成
2. 缺点：性能问题，只有一个线程，无法完全发挥多核 CPU 的性能。Handler 在处理某个连接上的业务时，整个进程无法处理其他连接事件，很容易导致性能瓶颈
3. 缺点：可靠性问题，线程意外终止，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障
4. 适用场景：客户端的数量有限，业务处理非常快速，比如 Redis 在业务处理的时间复杂度 O(1) 的情况

单 Reactor 多线程

工作原理示意图

方案说明

1. Reactor 对象通过 select 监控客户端请求事件，收到事件后，通过 dispatch 进行分发
2. 如果建立连接请求，则由 Acceptor 通过 accept 处理连接请求，然后创建一个 Handler 对象处理完成连接后的各种事件
3. 如果不是连接请求，则由 reactor 分发调用连接对应的 handler 来处理
4. handler 只负责响应事件，不做具体的业务处理，通过 read 读取数据后，会分发给后面的 worker 线程池的某个线程处理业务
5. worker 线程池会分配独立线程完成真正的业务，并将结果返回给 handler
6. handler 收到响应后，通过 send 将结果返回给 client

优点

可以充分的利用多核 CPU 的处理能力

缺点

多线程数据共享和访问比较复杂，reactor 处理所有的事件的监听和响应，在单线程运行，在高并发场景容易出现性能瓶颈

主从 Reactor 多线程

工作原理示意图

针对单 Reactor 多线程模型中，Reactor 在单线程中运行，高并发场景下容易成为性能瓶颈，可以让 Reactor 在多线程中运行

方案说明

1. Reactor 主线程，MainReactor 对象通过 select 监听连接事件，收到事件后，通过 Acceptor 处理连接事件
2. 当 Acceptor 处理连接事件后，MainReactor 将连接分配给 SubReactor
3. SubReactor 将连接加入到连接队列进行监听，并创建 Handler 进行各种事件处理
4. 当有新事件发生时，SubReactor 就会调用对应的 Handler 处理
5. Handler 通过 Read 读取数据，分发给后面的 Worker 线程处理
6. Worker 线程池分配独立的 Worker 线程进行业务处理，并返回结果
7. Handler 收到响应的结果后，再通过 send 方法，将结果返回给 client
8. Reactor 主线程可以对应多个 Reactor 子线程，即 MainReactor 可以关联多个 SubReactor

Scalable IO in Java 对 Multiple Reactors 的原理图解

优缺点说明

1. 优点：父线程与子线程的数据交互简单职责明确，父线程只需要接收新连接，子线程完成后续的业务处理
2. 优点：父线程与子线程的数据交互简单，Reactor 主线程只需要把新连接传给子线程，子线程无需返回数据
3. 缺点：编程复杂度较高

结合实例：这种模型在许多项目中广泛使用，包括 Nginx 主从 Reactor 多进程模型，Memcached 主从多线程，Netty 主从多线程模型的支持

Reactor 模式小结

3 种模式用生活案例来理解

1. 单 Reactor 单线程，前台接待员和服务员是同一个人，全程为顾客服务
2. 单 Reactor 多线程，1 个前台接待员，多个服务员，接待员只负责接待
3. 主从 Reactor 多线程，多个前台接待员，多个服务员

我觉得这个解释不对，应该要这样理解

1. 单 Reactor 单线程，前台接待员、服务员、厨师是同一个人，全程为顾客服务。这个人会忙死，同时客户也要等死。
2. 单 Reactor 多线程，前台接待员、服务员是同一个人，厨师是多个人，接待员、服务员只负责接待和下单，由厨师执行具体的做菜操作，厨师做好的菜再交给服务员。这个接待员、服务员要忙死，但是客户的体验比第一种要稍微好一点
3. 主从 Reactor 多线程，前台接待员是一个人，服务员是多个人，厨师也是多个人。接待员只负责接待，由服务员负责下单给厨师，厨师负责做菜，做好的菜返回给服务员，服务员进行上菜。这样接待员、服务员、厨师的工作都比较轻松，客户的体验也更好

优点

1. 响应快，不必为单个同步时间所阻塞，虽然 Reactor 本身依然是同步的
2. 可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销
3. 扩展性好，可以方便的通过增加 Reactor 实例个数来充分利用 CPU 资源
4. 复用性好，Reactor 模型本身与具体事件处理逻辑无关，具有很高的复用性

042.Netty模型

简单版

Netty 主要基于主从 Reactor 多线程模型（如图）做了一定的改进，其中主从 Reactor 多线程模型有多个 Reactor

1. BossGroup 线程维护 Selector，只关注 accept 事件
2. 当接收到 accept 事件后，获取到对应的 SocketChannel，封装成 NIOSocketChannel，并注册到 Worker 线程（事件循环），并进行维护
3. 当 Worker 线程监听到 selector 中的通道发生自己感兴趣的事件后，就进行处理（就由 Handler），注意 Handler 已经加入到通道

进阶版

Netty 抓哟基于主从 Reactors 多线程模型（如图）做了一定的改进，其中主从 Reactor 多线程模型有多个 Reactor

详细版

1. Netty 抽象出两组线程池 BossGroup 专门负责接收客户端的连接，WorkerGroup 专门负责网络读写
2. BossGroup 和 WorkerGroup 类型都是 NioEventLoopGroup
3. NioEventLoopGroup 相当于一个事件循环组，这个组中含有多个事件循环，每一个事件循环是 NioEventLoop
4. NioEventLoop 表示一个不断循环的执行处理任务的线程，每个 NioEventLoop 都有一个 selector，用于监听绑定在其上的 socket 的网络通讯
5. NioEventLoopGroup 可以有多个线程，即可以含有多个 NioEventLoop
6. 每个 Boss NioEventLoop 循环执行的步骤有 3 步
   1. 轮询 accept 事件
   2. 处理 accept 事件，与 client 建立连接，生成 NioSocketChannel，并将其注册到某个 Worker NioEventLoop 上的 selector
   3. 处理任务队列的任务，即 runAllTasks
7. 每个 Worker NioEventLoop 循环执行的步骤有 3 步
   1. 轮询 read、write 事件
   2. 处理 I/O 事件，即 read ，write 事件，在对应的 NioSocketChannel 读写
   3. 处理任务队列的任务，即 runAllTasks
8. 每个 Worker NioEventLoop 处理业务时，会使用 pipeline（管道），pipeline 中包含了 channel，即通过 pipeline 可以获取到对应的通道，管道中维护了很多的处理器

044.Netty入门

Netty 快速入门实例 - TCP 服务

1. 实例要求：使用 IDEA 创建 Netty 项目
2. Netty 服务器在 6668 端口监听，客户端能发送消息给服务器 "hello, 服务器~"
3. 服务器可以回复消息给客户端 "hello, 客户端~"
4. 目的：对 Netty 线程模型 有一个初步认识，便于理解 Netty 模型理论
5. 看老师代码演示
   1. 编写服务端
   2. 编写客户端
   3. 对 netty 程序进行分析，看看 netty 模型的特点

049.taskQueue自定义任务

任务队列中的 Task 有 3 种典型使用场景

1. 用户程序自定义的普通任务
2. 用户自定义定时任务
3. 非当前 Reactor 线程调用 Channel 的各种方法

例如在推送系统的业务线程里面，根据用户的标识，找到对应的 Channel 引用，然后调用 Write 类方法向该用户推送消息，就会进入到这种场景。最终的 Write 会提交到任务队列中被异步消费

异步模型原理剖析

基本介绍

1. 异步的概念和同步相对。当一个异步过程调用发出后，调用者不能立刻得到结果。实际处理这个调用的组件在完成后，通过状态、通知和回调来通知调用者
2. Netty 中的 I/O 操作是异步的，包括 Bind、Write、Connect 等操作会简单的返回一个 ChannelFuture
3. 调用者并不能立刻获得结果，而是通过 Future-Listener 机制，用户可以方便的主动获取或者通过通知机制获得 IO 操作结果
4. Netty 的异步模型是建立在 future 和 callback 之上的。callback 就是回调。重点说 Future，它的核心思想是：假设一个方法 fun，计算过程可能非常耗时，等待 fun 返回显然不合适。那么可以在调用 fun 的时候，立马返回一个 Future，后续可以通过 Future 去监控方法 fun 的处理过程（即：Future-Listener 机制）

Future 说明

1. 表示异步的执行结果，可以通过它提供的方法来检查执行是否完成，比如检索计算等
2. ChannelFuture 是一个接口：public interface ChannelFuture extends Future<Void>，我们可以添加监听器，当监听的事件发生时，就会通知到监听器

工作原理示意图

说明：

1. 在使用 Netty 进行编程时，拦截操作和转换出入站数据只需要您提供 callback 或利用 future 即可。这使得链式操作简单、高效，并有利于编写可重用的、通用的代码
2. Netty 框架的目标就是让你的业务逻辑从网络基础应用编码中分离出来、解脱出来

Future-Listener 机制

1. 当 Future 对象刚刚创建时，处于非完成状态，调用者可以通过返回 ChannelFuture 来获取操作执行的状态，注册监听函数来执行完成后的操作

2. 常见有如下操作：

   • 通过isDone方法来判断当前操作是否完成
   • 通过isSuccess方法来判断已完成的当前操作是否成功
   • 通过getCause方法来获取已完成的当前操作失败的原因
   • 通过isCancelled方法来判断已完成的当前操作是否被取消
   • 通过addListener方法来注册监听器，当操作已完成（isDone 方法返回完成），将会通知指定的监听器；如果 Future 对象已完成，则通知指定的监听器

3. 举例说明
   演示：绑定端口是异步操作，当绑定操作处理完，将会调用相应的监听器处理逻辑

   serverBootstrap.bind(port).addListener(future -> {
       if (future.isSuccess()) {
           System.out.println(new Date() + ":端口[" + port + "]绑定成功!");
       } else {
           System.err.println("端口[" + port + "]绑定失败!");
       }
   });
   

小结：相比传统阻塞 I/O，执行 I/O 操作后线程会被阻塞住，直到操作完成；异步处理的好处是不会造成线程阻塞，线程在 I/O 操作期间可以执行别的程序，在高并发情形下会更稳定和更高的吞吐量

053.Http服务程序实例

HTTP服务

1. 实例要求：使用 IDEA 创建 Netty 项目
2. Netty 服务器在 6668 端口监听，浏览器发出请求http://localhost:6668/
3. 服务器可以回复消息给客户端Hello!我是服务器5，并对特定请求资源进行过滤
4. 目的：Netty 可以做 Http 服务开发，并且理解 Handler 实例和客户端及其请求的关系

056.Netty核心组件

Bootstrap、ServerBootstrap

1. Bootstrap 意思是引导，一个 Netty 应用通常由一个 Bootstrap 开始，主要作用是配置整个 Netty 程序，串联各个组件，Netty 中 Bootstrap 类是客户端程序的启动引导类，ServerBootstrap 是服务端启动引导类

2. 常见的方法有

Future、ChannelFuture

1. Netty 中所有的 IO 操作都是异步的，不能立刻得知消息是否被正确处理。但是可以过一会等它执行完成或者直接注册一个监听，具体的实现就是通过 Future 和 ChannelFuture，他们可以注册一个监听，当操作执行成功或失败时监听会自动触发注册的监听事件
2. 常见的方法有
   • Channel channel()，返回当前正在进行 IO 操作的通道
   • ChannelFuture sync()，等待异步操作执行完毕

Channel

1. Netty 网络通信的组件，能够用于执行网络 I/O 操作
2. 通过 Channel 可获得当前网络连接的通道的状态
3. 通过 Channel 可获得网络连接的配置参数（例如接收缓冲区大小）
4. Channel 提供异步的网络 I/O 操作（如建立连接，读写，绑定端口），异步调用意味着任何 I/O 调用都将立即返回，并且不保证在调用结束时所请求的 I/O 操作已完成
5. 调用立即返回一个 ChannelFuture 实例，通过注册监听器到 ChannelFuture 上，可以直到 I/O 操作成功、失败或取消时通知调用方
6. 支持关联 I/O 操作与对应的处理程序
7. 不同协议、不同的阻塞类型的连接都有不同的 Channel 类型与之对应，常用的Channel 类型

Selector

1. Netty 基于 Selector 对象实现 I/O 多路复用，通过 Selector 一个线程可以监听多个连接的 Channel 事件
2. 当向一个 Selector 中注册 Channel 后，Selector 内部的机制就可以自动不断地查询（Select）这些注册的 Channel 是否有已就绪的 I/O 事件（例如可读，可写，网络连接完成等），这样程序就可以很简单地使用一个线程高效地管理多个 Channel

ChannelHandler 及其实现类

1. ChannelHandler 是一个接口，处理 I/O 事件或拦截 I/O 操作，并将其转发到其 ChannelPipeline（业务处理链）中的下一个处理程序
2. ChannelHandler 本身并没有提供很多方法，因为这个接口有许多的方法需要实现，为了方便使用，可以继承它的子类
3. ChannelHandler 及其实现类一览图
   • ChannelInboundHandler 用于处理入站 I/O 事件
   • ChannelOutboundHandler 用于处理出站 I/O 操作
   • ChannelInboundHandlerAdaptor 用于处理入站 I/O 事件
   • ChannelOutboundHandlerAdaptor 用于处理出站 I/O 操作
   • ChannelDuplexHandler 用于处理入站和出站事件
4. 我们经常需要自定义一个 Handler 类去继承 ChannelInboundHandlerAdapter，然后通过重写相应方法实现业务逻辑，我们接下来看看一般都需要重写哪些方法
    

Pipeline 和 ChannelPipeline

ChannelPipeline 是一个重点

1. ChannelPipeline 是一个 Handler 的集合，它负责处理和拦截 inbound 或者 outbound 的事件和操作，相当于一个贯穿 Netty 的链。（也可以这样理解：ChannelPipeline 是保存 ChannelHandler 的 List，用于处理或拦截 Channel 的入站事件和出站事件）

2. ChannelPipeline 实现了一种高级形式的拦截过滤器模式，使用户可以完全控制事件的处理方式，以及 Channel 中各个的 ChannelHandler 如何相互交互

3. 在 Netty 中每个 Channel 都有且仅有一个 ChannelPipeline 与之对应，它们的组成关系如下

   • 一个 Channel 包含了一个ChannelPipeline，而 ChannelPipeline 中又维护了一个由 ChannelHandlerContext 组成的双向链表，并且每个 ChannelHandlerContext 中又关联着一个 ChannelHandler
   • 入站事件和出站事件在一个双向链表中，入站事件会从链表 head 往后传递到最后一个入站的 handler，出站事件会从链表 tail 往前传递到最前一个出站的handler，两种类型的 handler 互不干扰

4. 常用方法

ChannelHandlerContext

1. 保存 Channel 相关的所有上下文信息，同时关联一个 ChannelHandler 对象
2. 即 ChannelHandlerContext 中包含一个具体的事件处理器 ChannelHandler，同时 ChannelHandlerContext 中也绑定了对应的 pipeline 和 Channel 的信息，方便对 ChannelHandler 进行调用
3. 常用方法

ChannelOption

1. Netty 在创建 Channel 实例后，一般都需要设置 ChannelOption 参数
2. ChannelOption 参数如下

EventLoopGroup 和其实现类 NioEventLoopGroup

1. EventLoopGroup 是一组 EventLoop 的抽象，Netty 为了更好的利用多核 CPU 资源，一般会有多个 EventLoop 同时工作，每个 EventLoop 维护着一个 Selector 实例
2. EventLoopGroup 提供 next 接口，可以从组里面按照一定规则获取其中一个 EventLoop 来处理任务。在 Netty 服务器端编程中，我们一般都需要提供两个 EventLoopGroup，例如：BossEventLoopGroup 和 WorkerEventLoopGroup
3. 通常一个服务端口，即一个 ServerSocketChannel 对应一个 Selector 和一个 EventLoop 线程。BossEventLoop 负责接收客户端的连接并将 SocketChannel 交给 WorkerEventLoopGroup 来进行 IO 处理，如下图所示
4. 常用方法

Unpooled 类

1. Netty 提供一个专门用来操作缓冲区（即 Netty 的数据容器）的工具类

2. 常用方法如下所示

   // 通过给定的数据和字符编码返回一个 ByteBuf 对象（类似于 NIO 中的 ByteBuffer 但有区别）
   public static ByteBuf copiedBuffer(CharSequence string, Charset charset)
   

3. 举例说明 Unpooled 获取 Netty 的数据容器 ByteBuf 的基本使用

063.Netty群聊系统

实例要求：

1. 编写一个 Netty 群聊系统，实现服务器端和客户端之间的数据简单通讯（非阻塞）
2. 实现多人群聊
3. 服务器端：可以监测用户上线，离线，并实现消息转发功能
4. 客户端：通过 channel 可以无阻塞发送消息给其它所有用户，同时可以接受其它用户发送的消息（由服务器转发得到）
5. 目的：进一步理解 Netty 非阻塞网络编程机制
6. 代码演示

单聊思路

066.Netty心跳机制实例

实例要求

1. 编写一个 Netty 心跳检测机制案例，当服务器超过 3 秒没有读时，就提示读空闲
2. 当服务器超过 5 秒没有写操作时，就提示写空闲
3. 实现当服务器超过 7 秒没有读或者写操作时，就提示读写空闲

068.WebSocket长连接开发

实例要求

1. Http 协议是无状态的，浏览器和服务器间的请求响应一次，下一次会重新创建连接
2. 要求：实现基于 websocket 的长连接的全双工的交互
3. 改变 http 协议多次请求的约束，实现长连接，服务器可以发送消息给浏览器
4. 客户端浏览器和服务器端会相互感知，比如服务器关闭了，浏览器会感知，同样浏览器关闭了，服务器会感知

073.netty编解码器机制

编码和解码的基本介绍

1. 编写网络应用程序时，因为数据在网络中传输的都是二进制字节码数据，在发送数据时就需要编码，接收数据时就需要解码
2. codec（编码器）的组成部分有两个：decoder（解码器）和encoder（编码器）。encoder 负责把业务数据转换成字节码数据，decoder 负责把字节码数据转换成业务数据

Netty 本身的编码解码的机制和问题分析

1. Netty 自身提供了一些 codec（编解码器）
2. Netty 提供的编码器
   • StringEncoder，对字符串数据进行编码
   • ObjectEncoder，对 Java 对象进行编码
3. Netty 提供的解码器
   • StringDecoder，对字符串数据进行解码
   • ObjectDecoder，对 Java 对象进行解码
4. Netty 自身自带的 ObjectDecoder 和 ObjectEncoder 可以用来实现 POJO 对象或各种业务对象的编码和解码，底层使用的仍是 Java 序列化技术，而 Java 序列化技术本身效率就不高，存在如下问题
   • 无法跨语言
   • 序列化后的体积太大，是二进制编码的 5 倍多
   • 序列化性能太低
   • 引出新的解决方案 [ Google 的 Protobuf ]

074.ProtoBuf

Protobuf 基本介绍和使用示意图

1. Protobuf 是 Google 发布的开源项目，全称 Google Protocol Buffers，是一种轻便高效的结构化数据存储格式，可以用于结构化数据串行化，或者说序列化。它很适合做数据存储或RPC[远程过程调用 remote procedure call]数据交换格式
   目前很多公司 http + json => tcp + protobuf
2. 参考文档：https://developers.google.com/protocol-buffers/docs/proto，语言指南
3. Protobuf 是以 message 的方式来管理数据的
4. 支持跨平台、跨语言，即[客户端和服务器端可以是不同的语言编写的]（支持目前绝大多数的语言，例如 C++、C#、Java、python 等）
5. 高性能，高可靠性
6. 使用 protobuf 编译器能自动生成代码，Protobuf 是将类的定义使用 .proto 文件进行描述。说明，在 idea 中编写 .proto 文件时，会自动提示是否下载 .proto 编写插件，可以让语法高亮
7. 然后通过 protoc.exe 编译器根据 .proto 自动生成 .java 文件
8. protobuf 使用示意图

Protobuf 快速入门实例

编写程序，使用 Protobuf 完成如下功能

1. 客户端可以发送一个 Student PoJo 对象到服务器（通过 Protobuf 编码）
2. 服务端能接收 Student PoJo 对象，并显示信息（通过 Protobuf 解码）

编写流程如下：

1. 在 maven 项目中引入 protobuf 坐标，下载相关的 jar 包

   <dependencies>
       <dependency>
           <groupId>com.google.protobuf</groupId>
           <artifactId>protobuf-java</artifactId>
           <version>3.6.1</version>
       </dependency>
   </dependencies>
   

2. 第2步：编写 proto 文件 Student.proto

   syntax = "proto3";  // 协议的版本
   option java_outer_classname = "StudentPOJO";  // 生成的外部类名，同时也是文件名
   // protobuf 使用 message 管理数据
   message Student { // 会在 StudentPOJO 外部类生成内部类 Student，它是真正发送的 POJO 对象
     int32 id = 1; // Student 类中有一个属性，名字为 id，类型为 int32(protobuf类型) 1表示属性序号，不是值
     string name = 2;
   }
   

   或者编写 proto 文件 Student.proto

   syntax = "proto3";  // 协议的版本
   option optimize_for = SPEED;  // 加快解析
   option java_package = "com.atguigu.netty.codec2";  // 指定生成到哪个包下
   option java_outer_classname = "MyDataInfo"; // 外部类名
    
   // protobuf 可以使用 message 管理其它的 message
   message MyMessage {
     // 定义一个枚举类型
     enum DataType {
       StudentType = 0;  // 在 proto3 要求 enum 的编号从 0 开始
       WorkerType = 1;
     }
    
     // 用 data_type 来标识传的是哪一个枚举类型
     DataType data_type = 1;
    
     // 表示每次枚举类型最多只能出现其中的一个，节省空间
     oneof dataBody {
       Student student = 2;
       Worker worker = 3;
     }
   }
    
   // protobuf 使用 message 管理数据
   message Student { // 会在 StudentPOJO 外部类生成内部类 Student，它是真正发送的 POJO 对象
     int32 id = 1; // Student 类中有一个属性，名字为 id，类型为 int32(protobuf类型) 1表示属性序号，不是值
     string name = 2;  //
   }
   message Worker {
     string name = 1;
     int32 age = 2;
   }
   

3. 从 https://github.com/protocolbuffers/protobuf/releases 下载 protobuf 程序，使用protoc --java_out=. Student.proto

Protobuf 快速入门实例2

编写程序，使用 Protobuf 完成如下功能

1. 客户端可以随机发送 Student Pojo / Worker Projo 对象到服务器（通过 Protobuf 编码）
2. 服务端能接收 Student Pojo / Worker Pojo 对象（需要判断是哪种类型），并显示信息（通过 Protobuf 解码）

079. Netty入站和出站机制

基本说明

1. netty 的组件设计：Netty 的主要组件有 Channel、EventLoop、ChannelFuture、ChannelHandler、ChannelPipe 等
2. ChannelHandler 充当了处理入站和出站数据的应用程序逻辑的容器。例如，实现 ChannelInboundHandler 接口（或 ChannelInboundHandlerAdaptor），你就可以接收入站事件和数据，这些数据会被业务逻辑处理。当要给客户端发送响应时，也可以从 ChannelInboundHandler 冲刷数据。业务逻辑通常写在一个或者多个 ChannelInboundHandler 中。ChannelOutboundHandler 原理一样，只不过它是用来处理出站数据的
3. ChannelPipeline 提供了 ChannelHandler 链的容器。以客户端应用程序为例，如果事件的运动方向是从客户端到服务端的，那么我们称这些事件为出站的，即客户端发送给服务端的数据会通过 pipeline 中的一系列 ChannelOutboundHandler，并被这些 Handler 处理，反之则称为入站的

编码解码器

1. 当 Netty 发送或者接收一个消息的时候，就将会发生一次数据转换。入站消息会被解码：从字节转换为另一种格式（比如 Java 对象）；如果是出站消息，它会被编码成字节
2. Netty 提供一系列实用的编解码器，它们都实现了 ChannelInboundHandler 或者 ChannelOutboundHandler 接口。在这些类中，channelRead 方法已经被重写了。以入站为例，对于每个从入站 Channel 读取的消息，这个方法会被调用。随后，它将调用由编码器所提供的 decode() 方法进行编码，并将已经解码的字节转发给 ChannelPipeline 中的下一个 ChannelInboundHandler

解码器-ByteToMessageDecoder

1. 关系继承图
2. 由于不可能知道远程节点是否会一次性发送一个完整的信息，tcp 有可能出现粘包拆包的问题，这个类会对入站数据进行缓冲，知道它准备好被处理

1. 一个关于 ByteToMessageDecoder 实例分析
    

080.Handler链调用机制实例

实例要求

1. 使用自定义的编码器和解码器来说明 Netty 的 handler 调用机制
   客户端发送 long -> 服务器
   服务端发送 long -> 客户端

结论

1. 不论编码器 handler 还是解码器 handler 即接收的消息类型必须与待处理的消息类型一致，否则该 handler 不会被执行
2. 在解码器进行数据解码时，需要判断缓存取（ByteBuf）的数据是否足够，否则接收到的结果会和期望结果可能不一样

Netty其它常用编解码器

解码器 - ReplayingDecoder

1. public abstract class ReplayingDecoder<S> extends ByteToMessageDecoder
2. ReplayingDecoder 扩展了 ByteToMessageDecoder 类，使用这个类，我们不必调用 readableBytes() 方法。参数 S 指定了用户状态管理的类型，其中 Void 代表不需要状态管理
3. 应用实例：使用 ReplayingDecoder 编写解码器，对前面的案例进行简化
4. ReplayingDecoder 使用方便，但它也有一些局限性
   • 并不是所有的 ByteBuf 操作都被支持，如果调用了一个不被支持的方法，将会抛出一个 UnsupportedOperationException
   • ReplayingDecoder 在某些情况下可能稍慢于 ByteToMessageDecoder，例如 网络缓慢并且消息格式复杂时，消息会被拆成多个碎片，速度变慢

其它解码器

1. LineBasedFrameDecoder：这个类在 Netty 内部也有使用，它使用行尾控制字符（\n 或者 \r\n）作为分隔符来解析数据
2. DelimiterBasedFrameDecoder：使用自定义的特殊字符作为消息的分隔符
3. HttpObjectDecoder：一个 HTTP 数据的解码器
4. LengthFieldBasedFrameDecoder：通过指定长度来标识整包消息，这样就可以自动的处理黏包和半包消息

其它编码器

085.Log4j整合到Netty

1. 在 Maven 中添加对 Log4j 的依赖，在 pom.xml
2. 配置 Log4j，在 resources/log4j.properties

087.Tcp粘包拆包原理

TCP粘包和拆包基本介绍

1. TCP是面向连接的，面向流的，提供高可靠服务。收发两端（客户端和服务器端）都要有一一成对的 socket，因此，发送端为了将多个发给接收端的包，更有效的发给对方，使用了优化方法（Nagle 算法），将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。这样做虽然提高了效率，但是接收端就难于分辨出完整的数据包了，因为面向流的通信是无消息保护边界的
2. 由于TCP无消息保护边界，需要在接收端处理消息边界问题，也就是我们所说的粘包、拆包问题
3. TCP粘包、拆包图解
   
   假设客户端分别发送了两个数据包D1和D2给服务端，由于服务端一次读取到字节数是不确定的，故可能存在以下四种情况：
   1. 服务端分两次读取到了两个独立的数据包，分别是D1和D2，没有粘包和拆包
   2. 服务端一次接受到了两个数据包，D1和D2粘合在一起，称之为TCP粘包
   3. 服务端分两次读取到了数据包，第一次读取到了完整的D1包和D2包的部分内容，第二次读取到了D2包的剩余内容，这称之为TCP拆包
   4. 服务端分两次读取到了数据包，第一次读取到了D1包的部分内容D1_1，第二次读取到了D1包的剩余部分内容D1_2和完整的D2包

TCP粘包和拆包现象实例

在编写 Netty 程序时，如果没有做处理，就会发生粘包和拆包的问题

TCP粘包和拆包解决方案

1. 使用自定义协议 + 编解码器 来解决
2. 关键就是要解决 服务器端每次读取数据长度的问题，这个问题解决，就不会出现服务器多读或少读数据的问题，从而避免TCP的粘包、拆包

看一个具体的实例：

1. 要求客户端发送5个Message对象，客户端每次发送一个Message对象
2. 服务器端每次接收一个Message，分5次进行解码，每读取到一个Message，会回复一个Message对象给客户端