读李林峰《netty进阶指南》于第18章有感。特此记录一下问题的现象，以及他是如何排障的，以此加深理解

事件梳理

某系统内部两个模块之间采用 HTTPS 通信。

某天：

1. 客户端某时间吞吐量为0，发送给服务端的消息失败
2. 服务端OOM

排查

1. 查看流量，并没有明显的流量变化，排除突发流量高峰导致系统过载。
2. 客户端存在大量超时以及关闭连接的日志。
3. 服务端日志发现，后台某个逻辑超时，超过了客户端的超时时间，所以这是客户端超时的原因。
4. 此时dump内存，发现服务端的NioSocketChannel占用排名第一。这是服务端OOM的原因
5. 停止压测，发现一切逐渐正常：客户端没有超时连接、服务端内存也正常。

事后分析

客户端与服务端通信架构图。客户端采用 HTTP 连接池的方式与服务端进行 RPC 调用，单个客户端连接池上限为200，客户端部署了30个实例，而服务端只部署了3个实例。

此问题出现原因是使用了HTTP1通信，高并发时，服务端瞬间涌入大量的HTTPS连接，
同时进行SSL握手，服务端处于高负载所以导致部分连接失败超时。客户端发起的重连、服务端GC受限无法及时关闭超时连接，又进一步加重服务器压力。

如何解决

功能层面：

1. 服务端可以做流控（比如窗口限流等）、动态扩容、换为Open SSL
2. 客户端也做流控、把超时时间设长同时加大tomcat线程数、减少并发请求RPC时的线程数量从200减到50（服务端用netty，网络IO不是问题，一旦出现服务端响应慢，说明服务端内部逻辑处理慢，此时再增加连接数量无意义）
   注意：在其他条件不变的情况下，只做“把超时时间设长同时加大tomcat线程数”相当于是：任务执行时间变长了，还加大线程的数量，可能把客户端也搞崩了。

架构层面：
1.客户端也使用Netty，进行多路复用。客户端使用httpclient发起RPC调用，网络IO阻塞时，CPU是空闲的。是典型的BIO模型，升级为NIO模型后：一个线程就可以轮询IO结果，有一个事件发生，就唤醒httpclient调用方。这样就增加了吞吐量。
3. 升级为HTTP2.0
3.客户端考虑异步编程，使用future来发起多个RPC调用，最后汇总结果

注意：使用netty解决了通信层面的异步问题，通信效率和可靠性提高了。
但是和服务的异步调用没有关系。
服务的异步与非异步调用，伪代码如下。远程调用RPC可以用netty，可以用BIO来实现。

	result1 = 远程调用RPC;// 同步阻塞result2	= 远程调用RPC;
和result1 = future(远程调用RPC);// 服务的异步调用result2	= future(远程调用RPC);

总结

导致NioSocketChannel泄漏的可能原因有两个。
（1）代码有缺陷，HTTPS客户端关闭连接之后，服务端没有正确关闭连接。
（2）服务端负载比较重，客户端超时之后的断连和重连速度超过服务端关闭连接速度，导致服务端的NioSocketChannel发生积压。随着积压数的增加，导致占用的内存快速增加，频繁GC使得服务端处理更慢，积压更严重，最终导致OOM异常。

在贴一个NIO的客户端、服务端的模型。不要忘了客户端也可以连接多个服务器，可以用多路复用来增加吞吐量。