读李林峰《netty进阶指南》于第18章有感。特此记录一下问题的现象,以及他是如何排障的,以此加深理解
事件梳理
某系统内部两个模块之间采用 HTTPS 通信。
某天:
- 客户端某时间吞吐量为0,发送给服务端的消息失败
- 服务端OOM
排查
- 查看流量,并没有明显的流量变化,排除突发流量高峰导致系统过载。
- 客户端存在大量超时以及关闭连接的日志。
- 服务端日志发现,后台某个逻辑超时,超过了客户端的超时时间,所以这是客户端超时的原因。
- 此时dump内存,发现服务端的NioSocketChannel占用排名第一。这是服务端OOM的原因
- 停止压测,发现一切逐渐正常:客户端没有超时连接、服务端内存也正常。
事后分析
客户端与服务端通信架构图。客户端采用 HTTP 连接池的方式与服务端进行 RPC 调用,单个客户端连接池上限为200,客户端部署了30个实例,而服务端只部署了3个实例。
此问题出现原因是使用了HTTP1通信,高并发时,服务端瞬间涌入大量的HTTPS连接,
同时进行SSL握手,服务端处于高负载所以导致部分连接失败超时。客户端发起的重连、服务端GC受限无法及时关闭超时连接,又进一步加重服务器压力。
如何解决
功能层面:
- 服务端可以做流控(比如窗口限流等)、动态扩容、换为Open SSL
- 客户端也做流控、把超时时间设长同时加大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的客户端、服务端的模型。不要忘了客户端也可以连接多个服务器,可以用多路复用来增加吞吐量。