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

点击上方“芋道源码”,选择“置顶公众号”

技术文章第一时间送达!

源码精品专栏

 

来源: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。

相关代码如下所示:

640

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

640


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

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

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

640

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

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

640

Netty并不反对在I/O线程中处理非I/O任务,而是需要用户必须要避免意外的I/O线程阻塞,以及过多的占用I/O任务调度,导致网络I/O处理性能下降。

2、一个超大的JDK业务线程池是不合适的,原因有两个:

1)性能问题:JDK线程池默认采用一个阻塞队列,N个work线程的模式,随着work线程数的增加、队列的争用会非常激烈,进而导致性能下降。

建议采用N组线程池,每个线程池线程数尽量少的方式增加并行处理能力,

减少锁争用。

640

2)故障隔离问题:如果后端只有一个线程池,某个服务故障将会导致整个进程不可用。采用分组处理业务服务的方式,可以降低故障的影响范围,示例如下所示:

640




如果你对 Dubbo / Netty 等等源码与原理感兴趣,欢迎加入我的知识星球一起交流。长按下方二维码噢

640?

目前在知识星球更新了《Dubbo 源码解析》目录如下:

01. 调试环境搭建
02. 项目结构一览
03. 配置 Configuration
04. 核心流程一览

05. 拓展机制 SPI

06. 线程池

07. 服务暴露 Export

08. 服务引用 Refer

09. 注册中心 Registry

10. 动态编译 Compile

11. 动态代理 Proxy

12. 服务调用 Invoke

13. 调用特性 

14. 过滤器 Filter

15. NIO 服务器

16. P2P 服务器

17. HTTP 服务器

18. 序列化 Serialization

19. 集群容错 Cluster

20. 优雅停机

21. 日志适配

22. 状态检查

23. 监控中心 Monitor

24. 管理中心 Admin

25. 运维命令 QOS

26. 链路追踪 Tracing

... 一共 69+ 篇

目前在知识星球更新了《Netty 源码解析》目录如下:

01. 调试环境搭建
02. NIO 基础
03. Netty 简介
04. 启动 Bootstrap

05. 事件轮询 EventLoop

06. 通道管道 ChannelPipeline

07. 通道 Channel

08. 字节缓冲区 ByteBuf

09. 通道处理器 ChannelHandler

10. 编解码 Codec

11. 工具类 Util

... 一共 61+ 篇


目前在知识星球更新了《数据库实体设计》目录如下:


01. 商品模块
02. 交易模块
03. 营销模块
04. 公用模块

... 一共 17+ 篇

源码不易↓↓↓

点赞支持老艿艿↓↓

  • 0
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值