netty worker线程数量_Dubbo线程模型

Dubbo中线程池的应用还是比较广泛的，按照consumer端到provider的RPC的方向来看，consumer端的应用业务线程到netty线程、consuemr端dubbo业务线程池，到provider端的netty boss线程、worker线程和dubbo业务线程池等。这些线程各司其职相互配合，共同完成dubbo RPC服务调用，理解dubbo线程模型对于学习Dubbo原理很有帮助。

dubbo线程模型包括线程模型策略和dubbo线程池策略两个方面，下面就依次进行分析。

dubbo线程模型

Dubbo默认的底层网络通信使用的是Netty，服务提供方NettyServer使用两级线程池，其中EventLoopGroup（boss）主要用来接收客户端的链接请求，并把完成TCP三次握手的连接分发给EventLoopGroup（worker）来处理，注意把boss和worker线程组称为I/O线程，前者处理IO连接事件，后者处理IO读写事件。

设想下，dubbo provider端的netty IO线程是如何处理业务逻辑呢？如果处理逻辑较为简单，并且不会发起新的I/O请求，那么直接在I/O线程上处理会更快，因为这样减少了线程池调度与上下文切换的开销，毕竟线程切换还是有一定成本的。如果逻辑较为复杂，或者需要发起网络通信，比如查询数据库，则I/O线程必须派发请求到新的线程池进行处理，否则I/O线程会被阻塞，导致处理IO请求效率降低。

那Dubbo是如何做的呢？

Dubbo中根据请求的消息类是直接被I/O线程处理还是被业务线程池处理，Dubbo提供了下面几种线程模型：

• all（AllDispatcher类）：所有消息都派发到业务线程池，这些消息包括请求、响应、连接事件、断开事件等，响应消息会优先使用对于请求所使用的线程池。
• direct（DirectDispatcher类）：所有消息都不派发到业务线程池，全部在IO线程上直接执行。
• message（MessageOnlyDispatcher类）：只有请求响应消息派发到业务线程池，其他消息如连接事件、断开事件、心跳事件等，直接在I/O线程上执行。