一、Dubbo的线程模型概述
Dubbo 默认的底层网络通讯使用的是 Netty ,服务提供方 NettyServer 使用两级线程池,其中 EventLoopGroup(boss) 主要用来接受客户端的链接请求,并把接受的请求分发给 EventLoopGroup(worker) 来处理,boss 和 worker 线程组我们称之为 IO 线程。
如果服务提供方的逻辑能迅速完成,并且不会发起新的 IO 请求,那么直接在 IO 线程上处理会更快,因为这减少了线程池调度与上下文切换开销。
但如果处理逻辑较慢,或者需要发起新的 IO 请求,比如需要查询数据库,则 IO 线程必须派发请求到新的线程池进行处理,否则 IO 线程会被阻塞,将导致不能接收其它请求。
根据请求的消息类被 IO 线程处理还是被业务线程池处理,Dubbo 提供了下面几种线程模型:
all:(AllDispatcher 类) 所有消息都派发到业务线程池,这些消息包括请求、响应、连接事件,断开事件,心跳等,这种线程模型如下图7.1.1:
image.png
图7.1.1
direct:(DirectDispatcher 类)所有消息都不派发到业务线程池,全部在 IO 线程上直接执行,模型如下图图7.1.2:
image.png
图7.1.2
message:(MessageOnlyDispatcher)只有请求响应消息派发到业务线程池,其它连接断开事件、心跳等消息,直接在 IO 线程上执行,模型图如下图7.1.3:
image.png
图7.1.3
execution:(ExecutionDispatcher 类) 只把请求类消息派发到业务线程池处理,但是响应和其它连接断开事件,心跳等消息直接在 IO 线程上执行,模型如下图图7.1.4:
image.png
图7.1.4
connection:(ConnectionOrderedDispatcher类) 在 IO 线程上将连接、断开事件放入队列,有序逐个执行,其它消息派发到业务线程池处理,模型如下图图7.1.5:
image.png
图7.1.5
Dubbo中线程模型的扩展接口为Dispatcher,其提供的上述扩展实现都实现了该接口,其中all模型是默认的线程模型。
二、Dubbo的线程池策略概述
上面我们讲解dubbo线程模型时候提到为了尽量早的释放Netty的IO线程,某些线程模型会把请求投递到线程池进行异步处理,那么这里所谓的线程池是什么样的线程池那?其实这里的线程池ThreadPool也是一个扩展接口SPI,Dubbo提供了该扩展接口的一些实现,具体实现如下:
FixedThreadPool:创建一个复用固定个数线程的线程池。
LimitedThreadPool:创建一个线程池,这个线程池中线程个数随着需要量动态增加,但是数量不超过配置的阈值的个数,另外空闲线程不会被回收,会一直存在。
EagerThreadPool :创建一个线程池,这个线程池当所有核心线程都处于忙碌状态时候,创建新的线程来执行新任务,而不是把任务放入线程池阻塞队列。
CachedThreadPool:创建一个自适应线程池,当线程处于空闲1分钟时候,线程会被回收,当有新请求到来时候会创建新线程
三、总结
Dubbo框架提供了几种常见的线程模型以及实现原理和线程池策略,当业务需要定制线程池策略或者线程模型时候,可以基于SPI接口进行定制。
本文摘录自《深度剖析Apache Dubbo核心技术内幕》,更多关于Apache Dubbo的知识分析可以左下角 阅读原文