Dubbo线程模型与线程池策略

一、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核心技术内幕》