[07] 案例&优化

通信框架承载了业务内部各模块之间的消息交互和服务调用，它的主要功能如下：

【备注】需要指出的是，协议通信双方链路建立成功之后，双方可以进行全双工通信，无论客户端还是服务端，都可以主动发送请求消息给对方，通信方式可以是 TWO WAY 或者 ONE WAY。双方之间的心跳采用 Ping-Pong 机制，当链路处于空闲状态时，客户端主动发送 Ping 消息给服务端，服务端接收到 Ping 消息后发送应答消息 Pong 给客户端，如果客户端连续发送 N 条 Ping 消息都没有接收到服务端返回的 Pong 消息，说明链路已经挂死或者对方处于异常状态，客户端主动关闭连接，间隔周期 T 后发起重连操作，直到重连成功。

消息定义包含两部分：消息头、消息体

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

消息体则支持 Java 对象类型的消息内容。

如果 A 节点需要调用 B 节点的服务，但是 A 和 B 之间还没有建立物理链路，则有调用方主动发起连接，此时，调用方为客户端，被调用方为服务端。

考虑到安全，链路建立需要通过基于 IP 地址或者号段的黑白名单安全认证机制，作为样例，本协议使用基于 IP 地址的安全认证，如果有多个 IP，通过逗号进行分割。在实际的商用项目中，安全认证机制会更加严格，例如通过密钥对用户名和密码进行安全认证。

客户端与服务端链路建立成功之后，由客户端发送业务握手请求的认证消息，服务端接收到客户端的握手请求消息之后，如果 IP 校验通过，返回握手成功应答消息给客户端，应用层链路建立成功。握手应答消息中消息体为 byte 类型的结果：0 认证成功，-1 认证失败，服务端关闭连接。

链路建立成功之后，客户端和服务端就可以互相发送业务消息了，在客户端和服务端的消息通信过程中，业务消息体的内容需要通过 MD5 进行摘要防篡改。

在凌晨等业务低谷时段，如果发生网络闪断、连接被 HangUp 等问题时，由于没有业务消息，应用程序很难发现。到了白天业务高峰期时，会发生大量的网络通信失败，严重的会导致一段时间进程内无法处理业务消息。为了解决这个问题，在网络空闲时采用心跳机制来检测链路的互通性，一旦发现网络故障，立即关闭链路，主动重连。

当读或者写心跳消息发生 I/O 异常的时候，说明已经中断，此时需要立即关闭连接，如果是客户端，需要重新发起连接。如果是服务端，需要清空缓存的半包信息，等到客户端重连。

检测空闲连接以及超时对于及时释放资源来说是至关重要的。由于这是一项常见的任务，Netty 特地为它提供了几个ChannelHandler 实现。

如果链路中断，等到 INTEVAL 时间后，由客户端发起重连操作，如果重连失败，间隔周期 INTERVAL 后再次发起重连，直到重连成功。

为了保持服务端能够有充足的时间释放句柄资源，在首次断连时客户端需要等待 INTERVAL 时间之后再发起重连，而不是失败后立即重连。

为了保证句柄资源能够及时释放，无论什么场景下重连失败，客户端必须保证自身的资源被及时释放，包括但不限于 SocketChannel、Socket 等。

重连失败后，可以打印异常堆栈信息，方便后续的问题定位。

当客户端握手成功之后，在链路处于正常状态下，不允许客户端重复登录，以防止客户端在异常状态下反复重连导致句柄资源被耗尽。

服务端接收到客户端的握手请求消息之后，对 IP 地址进行合法性校验，如果校验成功，在缓存的地址表中查看客户端是否已经登录，如果登录，则拒绝重复登录，同时关闭TCP链路，并在服务端的日志中打印握手失败的原因。

客户端接收到握手失败的应答消息之后，关闭客户端的 TCP 连接，等待 INTERVAL 时间之后，再次发起 TCP 连接，直到认证成功。

Netty 是如何解决 JDK 中的 Selector BUG 的？

这是 JDK NIO 的 BUG，它会导致 Selector 空轮询，最终导致 CPU 100%。官方声称在 JDK1.6 版本的 update18 修复了该问题，但是直到 JDK1.7 版本该问题仍旧存在，只不过该 BUG 发生概率降低了一些而已，它并没有被根本解决，甚至 JDK1.8 的 131 版本中依然存在。

（1）JDK 官方认为这是 Linux Kernel 版本的 bug

简单来说，JDK 认为 Linux 的 epoll 告诉我事件来了，但是 JDK 没有拿到任何事件（READ、WRITE、CONNECT、ACCPET），但此时 select() 不再选择阻塞了，而是选择返回了 0，于是就会进入一种无限循环，最终导致 CPU 100%。

（2）该问题的具体原因

在部分 Linux 2.6 的内核中，poll 和 epoll 对于突然中断的连接 socket 会对返回的 eventSet 事件集合置为 POLLHUP 或 POLLERR，eventSet 事件集合发生了变化，这就可能导致 Selector 会被唤醒。但是这个时候 selector 的 select() 返回 numKeys 是 0，所以下面本应该对 key 值进行遍历的事件处理根本执行不了，又回到最上面的 while(true) 循环，循环往复，不断的轮询，直到 Linux 系统出现 100% 的 CPU 情况，最终导致程序崩溃。

（3）Netty 解决办法

对 Selector 的 select 操作周期进行统计，每完成一次空的 select 操作进行一次计数，若在某个周期内连续发生 N 次空轮询，则表明触发了 epoll 死循环 bug。重建 Selector，判断是否是其他线程发起的重建请求，若不是则将原 SocketChannel 从旧的 Selector 上去除注册，重新注册到新的 Selector 上，并将原来的 Selector 关闭。

具体代码在 NioEventLoop#select() 中：

如何让单机下 Netty 支持百万长连接？

首先就是要突破操作系统的限制。

在 Linux 平台上，无论编写客户端程序还是服务端程序，在进行高并发 TCP 连接处理时，最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制（这是因为系统为每个 TCP 连接都要创建一个 socket 句柄，每个 socket 句柄同时也是一个文件句柄）。

可使用 ulimit 命令查看系统允许当前用户进程打开的句柄数限制：ulimit -n，默认 1024 个。

这表示当前用户的每个进程最多允许同时打开 1024 个句柄，这 1024 个句柄中还得除去每个进程必然打开的标准输入、标准输出、标准错误、服务器监听 socket、进程间通讯的 unix 域 socket 等文件，那么剩下的可用于客户端 socket 连接的文件数就只有大概 1024-10=1014 个左右。也就是说缺省情况下，基于 Linux 的通讯程序最多允许同时 1014 个 TCP 并发连接。

对于想支持更高数量的 TCP 并发连接的通讯处理程序，就必须修改 Linux 对当前用户的进程同时打开的文件数量。

修改单个进程打开最大文件数限制的最简单的办法就是使用 ulimit 命令：ulimit –n 1000000。

如果系统回显类似于“Operation not permitted”之类的话，说明上述限制修改失败，实际上是因为在中指定的数值超过了 Linux 系统对该用户打开文件数的软限制或硬限制。因此，就需要修改 Linux 系统对用户的关于打开文件数的软限制和硬限制。

（1）修改 /etc/security/limits.conf 文件，在文件中添加如下行：

soft 和 hard 为两种限制方式，其中 soft 表示警告的限制，hard 表示真正限制，nofile 表示打开的最大文件数。1000000 则指定了想要修改的新的限制值，即最大打开文件数（请注意软限制值要小于或等于硬限制）。

（2）修改 /etc/pam.d/login 文件，在文件中添加如下行：

这是告诉 Linux 在用户完成系统登录后，应该调用 pam_limits.so 模块来设置系统对该用户可使用的各种资源数量的最大限制（包括用户可打开的最大文件数限制），而 pam_limits.so 模块就会从 /etc/security/limits.conf 文件中读取配置来设置这些限制值。

查看 Linux 系统级的最大打开文件数限制，使用如下命令：cat /proc/sys/fs/file-max。

这表明这台 Linux 系统最多允许同时打开（即包含所有用户打开文件数总和）12158 个文件，是 Linux 系统级硬限制，所有用户级的打开文件数限制都不应超过这个数值。如果没有特殊需要，不应该修改此限制，除非想为用户级打开文件数限制设置超过此限制的值。

（3）如何修改这个系统最大文件描述符的限制呢？

（1）设置合理的线程数

对于线程池的调优，主要集中在用于接收海量设备 TCP 连接、TLS 握手的 Acceptor 线程池（Boss NioEventLoop Group）上，以及用于处理网络数据读写、心跳发送的 IO 工作线程池（Work NioEventLoop Group）上。

对于服务端，通常只需要启动一个监听端口用于端侧设备接入即可，但是如果服务端集群实例比较少，甚至是单机（或者双机冷备）部署，在端侧设备在短时间内大量接入时，需要对服务端的监听方式和线程模型做优化，以满足短时间内（例如 30s）百万级的端侧设备接入的需要。

服务端可以监听多个端口，利用主从 Reactor 线程模型做接入优化，前端通过 SLB 做 4 层门 7 层负载均衡。

主从 Reactor 线程模型特点如下：服务端用于接收客户端连接的不再是一个单独的 NIO 线程，而是一个独立的 NIO 线程池；Acceptor 接收到客户端 TCP 连接请求并处理后（可能包含接入认证等），将新创建的 SocketChannel 注册到 I/O 线程池（SubReactor 线程池）的某个 IO 线程，由它负责 SocketChannel 的读写和编解码工作。Acceptor 线程池仅用于客户端的登录、握手和安全认证等，一旦链路建立成功，就将链路注册到后端 SubReactor 线程池的 IO 线程，由 IO 线程负责后续的 IO 操作。

对于 IO 工作线程池的优化，可以先采用系统默认值（即 CPU 内核数 ×2）进行性能测试，在性能测试过程中采集 IO 线程的 CPU 占用大小，看是否存在瓶颈， 具体可以观察线程堆栈，如果连续采集几次进行对比，发现线程堆栈都停留在 Selectorlmpl#lockAndDoSelect()，则说明 IO 线程比较空闲，无须对工作线程数做调整。

如果发现 IO 线程的热点停留在读或者写操作或者停留在 ChannelHandler 的执行处，则可以通过适当调大 NioEventLoop 线程的个数来提升网络的读写性能。

（2）心跳优化

针对海量设备接入的服务端，心跳优化策略如下。

当设备突然掉电、连接被防火墙挡住、长时间 GC 或者通信线程发生非预期异常时，会导致链路不可用且不易被及时发现。特别是如果异常发生在凌晨业务低谷期间，当早晨业务高峰期到来时，由于链路不可用会导致瞬间大批量业务失败或者超时，这将对系统的可靠性产生重大的威胁。

从技术层面看，要解决链路的可靠性问题，必须周期性地对链路进行有效性检测。目前最流行和通用的做法就是心跳检测。心跳检测机制分为三个层面：

心跳检测的目的就是确认当前链路是否可用，对方是否活着并且能够正常接收和发送消息。作为高可靠的NIO框架，Nety也提供了心跳检测机制。

一般的心跳检测策略如下。

Netty 提供了 3 种链路空闲检测机制，利用该机制可以轻松地实现心跳检测：

对于百万级的服务器，一般不建议很长的心跳周期和超时时长。

（3）接收和发送缓冲区调优

在一些场景下，端侧设备会周期性地上报数据和发送心跳，单个链路的消息收发量并不大，针对此类场景，可以通过调小 TCP 的接收和发送缓冲区来降低单个 TCP 连接的资源占用率。

当然对于不同的应用场景，收发缓冲区的最优值可能不同，用户需要根据实际场景，结合性能测试数据进行针对性的调优。

（4）合理使用内存池

随着 JVM 虚拟机和 JIT 即时编译技术的发展，对象的分配和回收是一个非常轻量级的工作。但是对于缓冲区 Buffer，情况却稍有不同，特别是堆外直接内存的分配和回收，是一个耗时的操作。

为了尽量重用缓冲区，Netty 提供了基于内存池的缓冲区重用机制。

在百万级的情况下，需要为每个接入的端侧设备至少分配一个接收和发送 ByteBuf 缓冲区对象，采用传统的非池模式，每次消息读写都需要创建和释放 ByteBuf 对象，如果有 100 万个连接，每秒上报一次数据或者心跳，就会有 100 万次/s 的 ByteBuf 对象申请和释放，即便服务端的内存可以满足要求，GC 的压力也会非常大。

以上问题最有效的解决方法就是使用内存池，每个 NioEventLoop 线程处理 N 个链路，在线程内部，链路的处理是串行的。假如 A 链路首先被处理，它会创建接收缓冲区等对象，待解码完成，构造的 POJO 对象被封装成任务后投递到后台的线程池中执行，然后接收缓冲区会被释放，每条消息的接收和处理都会重复接收缓冲区的创建和释放。如果使用内存池，则当 A 链路接收到新的数据报时，从 NioEventLoop 的内存池中申请空闲的 ByteBuf，解码后调用 release 将 ByteBuf 释放到内存池中，供后续的 B 链路使用。

Netty 内存池从实现上可以分为两类：堆外直接内存和堆内存。由于 ByteBuf 主要用于网络 IO 读写，因此采用堆外直接内存会减少一次从用户堆内存到内核态的字节数组拷贝，所以性能更高。由于 DirectByteBuf 的创建成本比较高，因此如果使用 DirectByteBuf，则需要配合内存池使用，否则性价比可能还不如 Heap Byte。

Netty 默认的 IO 读写操作采用的都是内存池的堆外直接内存模式，如果用户需要额外使用 ByteBuf，建议也采用内存池方式；如果不涉及网络 IO 操作（只是纯粹的内存操作），可以使用堆内存池，这样内存的创建效率会更高一些。

（5）IO 线程和业务线程分离

如果服务端不做复杂的业务逻辑操作，仅是简单的内存操作和消息转发，则可以通过调大 NioEventLoop工作线程池的方式，直接在 IO 线程中执行业务 ChannelHandler，这样便减少了一次线程上下文切换，性能反而更高。

如果有复杂的业务逻辑操作，则建议 IO 线程和业务线程分离，对于 IO 线程，由于互相之间不存在锁竞争，可以创建一个大的 NioEventLoopGroup线程组，所有 Channel 都共享同一个线程池。

对于后端的业务线程池，则建议创建多个小的业务线程池，线程池可以与 IO 线程绑定，这样既减少了锁竞争，又提升了后端的处理性能。

（6）针对端侧并发连接数的流控

无论服务端的性能优化到多少，都需要考虑流控功能。当资源成为瓶颈，或者遇到端侧设备的大量接入，需要通过流控对系统做保护。

流控的策略有很多种，比如针对端侧连接数的流控：新增一个 FlowControlChannelHandler，然后添加到 ChannelPipeline 靠前的位置，覆盖 channelActive() 方法，创建 TCP 链路后，执行流控逻辑，如果达到流控阈值，则拒绝该连接，调用 ChannelHandlerContext#close() 方法关闭连接。

当客户端的并发连接数达到数十万或者数百万时，系统一个较小的抖动就会导致很严重的后果，例如服务端的 GC，导致应用暂停（STW）的 GC 持续几秒，就会导致海量的客户端设备掉线或者消息积压，一旦系统恢复，会有海量的设备接入或者海量的数据发送很可能瞬间就把服务端冲垮。

JVM 层面的调优主要涉及 GC 参数优化，GC 参数设置不当会导致频繁 GC，甚至 OOM 异常，对服务端的稳定运行产生重大影响。

（1）确定 GC 优化目标

GC（垃圾收集）有三个主要指标：

JVM GC 调优的三个基本原则如下：

（2）确定服务端内存占用

在优化 GC 之前，需要确定应用程序的内存占用大小，以便为应用程序设置合适的内存，提升 GC 效率。内存占用与活跃数据有关，活跃数据指的是应用程序稳定运行时长时间存活的 Java 对象。

活跃数据的计算方式：通过 GC 日志采集 GC 数据，获取应用程序稳定时老年代占用的 Java 堆大小，以及永久代（元数据区）占用的 Java 堆大小，两者之和就是活跃数据的内存占用大小。

（3）GC 优化过程

什么是水平触发（LT）和边缘触发（ET）？

select()、poll() 模型都是水平触发模式，信号驱动 IO 是边缘触发模式，epoll() 模型既支持水平触发，也支持边缘触发，默认是水平触发。JDK 中的 select 实现是水平触发，而 Netty 提供的 epoll 的实现中是边缘触发。