为什么建议 Netty 的 I/O 线程与业务线程分离

xkl135 2018-10-10

展开全文

技术文章第一时间送达！

源码精品专栏

来源：Netty 之家

问题背景：

某互联网同学咨询一个Netty使用问题：最近在研究公司内部的RPC框架，发现底层通信框架使用的是Netty，而且Netty的I/O线程与处理业务的线程分离。具体如下：

1、负责服务端监听的是Accept NioEventLoopGroup线程组

2、负责链路读写操作的是Work NioEventLoopGroup线程组

3、消息解码完成之后，投递到后端的一个业务线程池中处理，线程池使用的是JDK自带的线程池

该同学的疑问：为什么业务的处理不能放到Work NioEventLoopGroup中？

1、如果业务线程处理比较慢，即便I/O线程处理再快，业务端到端响应还是不会缩短

2、I/O线程到业务线程存在线程上下文切换，增加了额外的开销

想法：

构造一个线程数较大（例如1024）的NioEventLoopGroup，同时处理链路的读写和业务处理。即业务处理和消息读写统一使用Netty的I/O线程池（实质自定义的线程组）。

问题答复

Netty I/O线程和业务处理线程分离原因：

1、充分利用多核的并行处理能力：I/O线程和业务线程分离，双方可以并行的处理网络I/O和业务逻辑，充分利用多核的并行计算能力，提升性能。

2、故障隔离：后端的业务线程池处理各种类型的业务消息，有些是I/O密集型、有些是CPU密集型、有些是纯内存计算型，不同的业务处理时延，以及发生故障的概率都是不同的。如果把业务线程和I/O线程合并，就会存在如下问题：

1）某类业务处理较慢，阻塞I/O线程，导致其它处理较快的业务消息的响应无法及时发送出去。

2）即便是同类业务，如果使用同一个I/O线程同时处理业务逻辑和I/O读写，如果请求消息的业务逻辑处理较慢，同样会导致响应消息无法及时发送出去。

3、可维护性：I/O线程和业务线程分离之后，双方职责单一，有利于代码维护和问题定位。如果合设在一起，当RPC调用时延增大之后，到底是网络问题、还是I/O线程问题、还是业务逻辑问题导致的时延大，纠缠在一起，问题定位难度非常大。例如业务线程中访问缓存或者数据库偶尔时延增大，就会导致I/O线程被阻塞，时延出现毛刺，这些时延毛刺的定位，难度非常大。

4、资源代价：NioEventLoopGroup的创建并不是廉价的，它会聚合Selector，Selector本身就会消耗句柄资源。

Netty的NioEventLoop设计理念就是通过有限的I/O线程，通过多路复用和非阻塞的方式，一个线程同时处理成百上千个链路，来解决传统一连接一线程的同步阻塞模型。

因此，它的创建成本也较高，一个进程中不宜创建过多NioEventLoop。

相关代码如下所示：

5、线程切换的代价：如果不是追求极致的性能，线程切换只要不过于频繁，它的代价还是可以接受的。在一个复杂的系统中，当你集成第三方SDK时，例如Redis Client，通常都包含着隐式的线程切换。一些场景下，为了实现系统的高可用性，例如基于Hystrix做故障隔离，同样会存在线程切换：Hystrix基于线程做故障隔离

该问题引申的其它几个问题

1、Netty的I/O线程 NioEventLoop是否可以处理非I/O任务？

答案是肯定的，通过它提供的接口就可以看出这点：

它的execute方法参数是Runnable，与JDK的线程池execute方法是等价的（异常处理策略存在差异）。

开了这个口子之后，就会存在风险，例如用户为了简化线程处理模型，把所有的业务任务封装成Task，丢到Nett用的I/O线程NioEventLoop中执行。为了防止过多的业务任务阻塞I/O线程的网络读写操作，NioEventLoop提供了设置I/O任务和非I/O任务的处理比例，通过合理的调整处理比例，来保证更合理的资源调度。