Dubbo 默认的底层网络通讯使用的是 Netty ,服务提供方 NettyServer 使用两级线程池,其中 EventLoopGroup(boss) 主要用来接受客户端的链接请求,并把接受的请求分发给 EventLoopGroup(worker) 来处理,boss 和 worker 线程组我们称之为 IO 线程。
如果服务提供方的逻辑能迅速完成,并且不会发起新的 IO 请求,那么直接在 IO 线程上处理会更快,因为这减少了线程池调度与上下文切换开销。
但如果处理逻辑较慢,或者需要发起新的 IO 请求,比如需要查询数据库,则 IO 线程必须派发请求到新的线程池进行处理,否则 IO 线程会被阻塞,将导致不能接收其它请求。
根据请求的消息类被 IO 线程处理还是被业务线程池处理,Dubbo 提供了下面几种线程模型:
image.png
图7.1.1
image.png
图7.1.2
image.png
图7.1.3
image.png
图7.1.4
image.png
图7.1.5
Dubbo中线程模型的扩展接口为Dispatcher,其提供的上述扩展实现都实现了该接口,其中all模型是默认的线程模型。
上面我们讲解dubbo线程模型时候提到为了尽量早的释放Netty的IO线程,某些线程模型会把请求投递到线程池进行异步处理,那么这里所谓的线程池是什么样的线程池那?其实这里的线程池ThreadPool也是一个扩展接口SPI,Dubbo提供了该扩展接口的一些实现,具体实现如下:
Dubbo框架提供了几种常见的线程模型以及实现原理和线程池策略,当业务需要定制线程池策略或者线程模型时候,可以基于SPI接口进行定制。本章摘录自《深度剖析Apache Dubbo核心技术内幕》