dubbo的线程模型

 

  


  •  

    Dubbo默认的底层网络通讯使用的是Netty,服务提供方NettyServer使用两级线程池,其中 EventLoopGroup(boss) 主要用来接受客户端的链接请求,并把接受的请求分发给 EventLoopGroup(worker) 来处理,boss和worker线程组我们称之为IO线程。

    如果服务提供方的逻辑能迅速完成,并且不会发起新的IO请求,那么直接在IO线程上处理会更快,因为这减少了线程池调度。

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

    Dubbo提供的线程模型

    根据请求的消息类被IO线程处理还是被业务线程池处理,Dubbo提供了下面几种线程模型:

  •  all : (AllDispatcher类)所有消息都派发到业务线程池,这些消息包括请求/响应/连接事件/断开事件/心跳等,这些线程模型如下图:
  • direct : (DirectDispacher类)所有消息都不派发到业务线程池,全部在IO线程上直接执行,模型如下图:
  • message : (MessageOnlyDispatcher类)只有请求响应消息派发到业务线程池,其他连接断开事件/心跳等消息,直接在IO线程上执行,模型图如下:
  • execution:(ExecutionDispatcher类)只把请求类消息派发到业务线程池处理,但是响应和其它连接断开事件,心跳等消息直接在IO线程上执行,模型如下图:
  • connection:(ConnectionOrderedDispatcher类)在IO线程上,将连接断开事件放入队列,有序逐个执行,其它消息派发到业务线程池处理,模型如下图:
  • 其中AllDispatcher对应的handler代码如下:

    public class AllChannelHandler extends WrappedChannelHandler{
        public AllChannelHandler(ChannelHandler handler , URL url){
            super(handler,url);
        }
    
        // 链接事件,交给业务线程池处理
        public void connected(Channel channel) throws RemotingExcecption{
            ExecutorService cexecutor = getExecutorService();
            try{
                cexecutor.execute(new ChannelEventRunnable(channel,handler,ChannelState.CONNECTED));
            }catch(Throwable t){
                throw new ExecutionException("connect event" , channel , getClass() + "error when process connected event.",t);
            }
        }
    
        // 链接断开事件,交给业务线程池处理
        public void disconnected(Channel channel) throws RemotingException{
            ExecutorService cexecutor = getExecutorService();
            try{
                cexecutor.execute(new ChannelEventRunnable(channel,handler,ChannelState.DISCONNECTED));
            }catch(Throwable t){
                throw new ExecutionException("disconnect event",channel,getClass()+" error when process disconnected event.",t);
            }
        }
    
        // 请求响应事件,交给业务线程池处理
        public void received(Channel channel , Object message) throws RemotingException{        
            ExecutorService cexecutor = getExecutorService();
            try{
                cexecutor.execute(new ChannelEventRunnable(channel,handler,ChannelState.RECEIVED,message));
            }catch(Throwable t){
                // TODO 临时解决线程池满后异常信息无法发送到对端的问题。待重构
                // fix 线程池满了拒绝调用不返回,导致消费者一直等待超时
                if(message instanceof Request && t instanceof RejectedExecutionException ){
                    ...
                }
                throw new ExecutionException(message , channel ,getClass() + " error when process received event.",t);
            }
        }
    
        // 异常处理事件,交给业务线程池处理
        public void caught(Channel channel , Throwable exception) throws RemotingException {
            ExecutorService cexecutor = getExecutorService();
            try{
                cexecutor.execute(new ChannelEventRunnable(channel,handler,ChannelState.CAUGHT,exception));
            }catch(Throwable t){
                throw new ExecutionException("caught event",channel,getClass() + " error when process caught event .");
            }
        }
        ...
    }
     

    可知所有事件都直接交给业务线程池进行处理了。

    Dubbo提供了常用的线程池模型,这些模型可以满足我们绝大多数的需求,但是您可以根据自己的需要进行扩展定制。在服务提供者启动线程时,我们会看到什么时候加载的线程模型的实现。

    Dubbo提供的线程池策略

    扩展接口 ThreadPool 的SPI实现有如下几种:

  • fixed:固定大小线程池,启动时建立线程,不关闭,一直持有(缺省)。
  • cached:缓存线程池,空闲一分钟自动删除,需要时重建。
  • limited:可伸缩线程池,但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然带来大流量引起性能问题。
  • 其中fixed策略对应扩展实现类是FixedThreadPool,代码如下:

    public class FixedThreadPool implements ThreadPool{
        public Executor getExecutor(URL url){
            String name = url.getParameter(Constants.THREAD_NAME_KEY,Constants.DEFAULT_THREAD_NAME);
            int threads = url.getParameter(Constants.THREADS_KEY,Constants.DEFAULT_THREADS);
            int queues = url.getParameter(Constants.QUEUES_KEY,Constants.DEFAULT_QUEUES);
            return new ThreadPoolExecutor(threads , threads , 0 , TimeUnit.MILLISECONDS , queues==0 ? new SynchronousQueue<Runnable>() : (queue < 0 ? new LinkedBlockingQueue<Runnable>(queues)) , new NamedThreadFactory(name,true) , new AbortPolicyWithReport(name,url));
        }
    }
     

    可知使用ThreadPoolExecutor创建了核心线程数=最大线程池数=threads的线程池。

### Dubbo 客户端线程模型架构与工作原理 Dubbo客户端的线程模型设计旨在高效处理远程服务调用并管理并发请求。通过自适应扩展机制,可以根据URL参数动态调整线程池配置[^1]。 #### 线程池初始化 当启动Dubbo消费者应用时,会依据配置文件或默认设置创建线程池实例。此过程涉及解析`dubbo.consumer.threadpool`属性及其关联参数,如核心线程数(`corethreads`)、最大线程数(`maxthreads`)等。这些设定直接影响后续RPC调用期间资源分配策略。 ```properties # 配置示例 dubbo.consumer.threadpool=fixed dubbo.consumer.corethreads=200 dubbo.consumer.maxthreads=1000 ``` #### 请求提交流程 每当发起一次远端方法调用(DemoService.sayHello()),实际执行路径如下: - **代理对象**接收到API接口调用后封装成Invocation对象; - 调度器根据负载均衡算法挑选合适的服务提供方节点; - 将准备好的消息体发送至目标地址前,先经过过滤链(Filter Chain)做预处理操作; - 最终由Transporter负责建立物理连接并向对方传递二进制流数据; 在此过程中,所有异步任务均交予预先构建好的ExecutorService来承担,确保主线程不会因等待响应而阻塞过久。 #### 响应回调机制 一旦网络层确认已成功送达指令包,则立即触发监听事件通知业务逻辑继续推进。此时如果启用了Future模式,则允许应用程序提前返回临时结果给前端展示,待真正完成后再更新最终状态。 对于同步场景,默认情况下将一直挂起直到获得确切答复为止。不过得益于灵活可配的超时控制选项,可以有效防止长时间无回应造成的死锁现象发生。 ```java // Java代码片段示意如何使用CompletableFuture优雅地处理异步回调 public CompletableFuture<String> asyncSayHello(String name){ return RpcContext.getContext().getCompletableFuture(); } ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

武汉红喜

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值