Dubbo的线程模型

Dubbo中的线程模型

 

整体步骤：（受限于派发策略，以默认的all为例, 以netty4为例）

1、客户端的主线程调用一个RPC方法，客户端的worker线程发出请求，等待响应；

2、客户端的主线程尝试获取future，在执行get时进行阻塞等待；

3、服务端使用worker线程（netty通信模型）接收到请求后，将请求提交到server线程池中进行处理；

4、server线程处理完成之后，将相应结果返回worker线程，响应请求给客户端的worker线程池（netty通信模型）；

5、最后，worker线程将响应结果提交到client线程池进行处理；

6、client线程将响应结果填充到future中，然后唤醒等待的主线程，主线程获取结果，返回给客户端。

配置 Dubbo 中的线程模型

如果事件处理的逻辑能迅速完成，并且不会发起新的 IO 请求，比如只是在内存中记个标识，则直接在 IO 线程上处理更快，因为减少了线程池调度。

但如果事件处理逻辑较慢，或者需要发起新的 IO 请求，比如需要查询数据库，则必须派发到线程池，否则 IO 线程阻塞，将导致不能接收其它请求。

如果用 IO 线程处理事件，又在事件处理过程中发起新的 IO 请求，比如在连接事件中发起登录请求，会报“可能引发死锁”异常，但不会真死锁。

因此，需要通过不同的派发策略和不同的线程池配置的组合来应对不同的场景:

<dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" />

Dispatcher

• all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
• direct 所有消息都不派发到线程池，全部在 IO 线程上直接执行。
• message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
• execution 只有请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
• connection 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。

ThreadPool

• fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
• cached 缓存线程池，空闲一分钟自动删除，需要时重建。
• limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
• eager 优先创建Worker线程池。在任务数量大于corePoolSize但是小于maximumPoolSize时，优先创建Worker来处理任务。当任务数量大于maximumPoolSize时，将任务放入阻塞队列中。阻塞队列充满时抛出RejectedExecutionException。(相比于cached:cached在任务数量超过maximumPoolSize时直接抛出异常而不是将任务放入阻塞队列)

参考：

dubbo——线程模型_七月流星-CSDN博客_dubbo线程模型

Dubbo线程模型 - 简书

线程模型 | Apache Dubbo