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核心技术内幕》,更多关于Apache Dubbo的知识分析可以左下角 阅读原文 

  • 2
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值