Dubbo线程模型设计解析

前言

Dubbo是一个支持大量并发请求的网络框架,单机TPS能够达到1w,这种并发处理请求的能力和它的线程模型是分不开的。

在提供者处理请求这一端,Dubbo通过多线程同时处理多个客户端请求。

Dubbo底层是使用netty作为通信组件的,了解Dubbo的线程模型之前我们先了解下Netty的线程模型,在Dubbo中使用的是netty的**主从 Reactor 多线程模式,**如下图:

在这种模式中,客户端的连接事件和读写数据的事件由不同的线程处理,一般连接事件使用1个线程处理,读写数据的事件交给线程池处理。在dubbo的源码中可以看出使用的是这种模式。

<span style="color:#333333"><span style="background-color:rgba(0, 0, 0, 0.03)"><code>    <span style="color:#afafaf">@Override</span></code><code>    <span style="color:#ca7d37">protected</span> <span style="color:#ca7d37">void</span> <span style="color:#dd1144">doOpen</span>() <span style="color:#ca7d37">throws</span> Throwable {</code><code>        bootstrap = <span style="color:#ca7d37">new</span> ServerBootstrap();</code><code>????????<span style="color:#afafaf"><em>//处理连接事件的线程</em></span></code><code>        bossGroup = <span style="color:#ca7d37">new</span> NioEventLoopGroup(<span style="color:#0e9ce5">1</span>, <span style="color:#ca7d37">new</span> DefaultThreadFactory(<span style="color:#dd1144">"NettyServerBoss"</span>, <span style="color:#ca7d37">true</span>));</code><code>        <span style="color:#afafaf"><em>//处理读写数据事件的线程池</em></span></code><code>        workerGroup = <span style="color:#ca7d37">new</span> NioEventLoopGroup(getUrl().getPositiveParameter(IO_THREADS_KEY, Constants.DEFAULT_IO_THREADS),</code><code>                <span style="color:#ca7d37">new</span> DefaultThreadFactory(<span style="color:#dd1144">"NettyServerWorker"</span>, <span style="color:#ca7d37">true</span>));</code><code>?</code><code>        <span style="color:#ca7d37">final</span> NettyServerHandler nettyServerHandler = <span style="color:#ca7d37">new</span> NettyServerHandler(getUrl(), <span style="color:#ca7d37">this</span>);</code><code>        channels = nettyServerHandler.getChannels();</code><code>?</code><code>        bootstrap.group(bossGroup, workerGroup)</code><code>                .channel(NioServerSocketChannel.class)</code><code>                .childOption(ChannelOption.TCP_NODELAY, Boolean.TRUE)</code><code>                .childOption(ChannelOption.SO_REUSEADDR, Boolean.TRUE)</code><code>                .childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT)</code><code>                .childHandler(<span style="color:#ca7d37">new</span> ChannelInitializer<NioSocketChannel>() {</code><code>                    <span style="color:#afafaf">@Override</span></code><code>                    <span style="color:#ca7d37">protected</span> <span style="color:#ca7d37">void</span> <span style="color:#dd1144">initChannel</span>(NioSocketChannel ch) <span style="color:#ca7d37">throws</span> Exception {</code><code>                        <span style="color:#afafaf"><em>// <span style="color:#dd1144">FIXME:</span> should we use getTimeout()?</em></span></code><code>                        <span style="color:#ca7d37">int</span> idleTimeout = UrlUtils.getIdleTimeout(getUrl());</code><code>                        NettyCodecAdapter adapter = <span style="color:#ca7d37">new</span> NettyCodecAdapter(getCodec(), getUrl(), NettyServer.<span style="color:#ca7d37">this</span>);</code><code>                        ch.pipeline()<span style="color:#afafaf"><em>//.addLast("logging",new LoggingHandler(LogLevel.INFO))//for debug</em></span></code><code>                                .addLast(<span style="color:#dd1144">"decoder"</span>, adapter.getDecoder())</code><code>                                .addLast(<span style="color:#dd1144">"encoder"</span>, adapter.getEncoder())</code><code>                                .addLast(<span style="color:#dd1144">"server-idle-handler"</span>, <span style="color:#ca7d37">new</span> IdleStateHandler(<span style="color:#0e9ce5">0</span>, <span style="color:#0e9ce5">0</span>, idleTimeout, MILLISECONDS))</code><code>                                .addLast(<span style="color:#dd1144">"handler"</span>, nettyServerHandler);</code><code>                    }</code><code>                });</code><code>        <span style="color:#afafaf"><em>// bind</em></span></code><code>        ChannelFuture channelFuture = bootstrap.bind(getBindAddress());</code><code>        channelFuture.syncUninterruptibly();</code><code>        channel = channelFuture.channel();</code><code>?</code><code>    }</code></span></span>

上面讲的是Netty的线程池模型,而在Dubbo中,Dubbo自身框架也有一套线程池模型,它和Netty的线程池模型是有一定关系的。

上图是Dubbo的线程派发模型,在Netty的线程池把请求转发到Dubbo的handler时候,会进行请求分发,这个时候就可能会通过Dubbo自身的线程来处理业务请求了。

Dubbo中的线程派发策略

dubbo总共有5类线程分发器,不同的线程分发器代表不同的线程派发策略,表示哪类消息会使用dubbo自身的线程池处理,默认使用AllDispatcher。

  • `all` 所有消息都派发到线程池,包括请求,响应,连接事件,断开事件,心跳等。默认的

  • `direct` 所有消息都不派发到线程池,全部在 IO 线程上直接执行。

  • `message` 只有请求响应消息派发到线程池,其它连接断开事件,心跳等消息,直接在 IO 线程上执行。

  • `execution` 只有请求消息派发到线程池,不含响应,响应和其它连接断开事件,心跳等消息,直接在 IO 线程上执行。

  • `connection` 在 IO 线程上,将连接断开事件放入队列,有序逐个执行,其它消息派发到线程池。

比如AllDispatcher分发器使用AllChannelHandler处理消息,这种处理器会使用dubbo自身线程池处理请求,响应,连接,端口,心态所有的和客户端交互的事件。源码如下:

<span style="color:#333333"><span style="background-color:rgba(0, 0, 0, 0.03)"><code><span style="color:#ca7d37">public</span> <span style="color:#ca7d37">class</span> <span style="color:#0e9ce5">AllChannelHandler</span> <span style="color:#ca7d37">extends</span> <span style="color:#0e9ce5">WrappedChannelHandler</span> {</code><code>?</code><code>    <span style="color:#ca7d37">public</span> <span style="color:#dd1144">AllChannelHandler</span>(ChannelHandler handler, URL url) {</code><code>        <span style="color:#ca7d37">super</span>(handler, url);</code><code>    }</code><code>    <span style="color:#afafaf"><em>//连接事件</em></span></code><code>    <span style="color:#afafaf">@Override</span></code><code>    <span style="color:#ca7d37">public</span> <span style="color:#ca7d37">void</span> <span style="color:#dd1144">connected</span>(Channel channel) <span style="color:#ca7d37">throws</span> RemotingException {</code><code>        ExecutorService executor = getExecutorService();</code><code>        <span style="color:#ca7d37">try</span> {</code><code>            executor.execute(<span style="color:#ca7d37">new</span> ChannelEventRunnable(channel, handler, ChannelState.CONNECTED));</code><code>        } <span style="color:#ca7d37">catch</span> (Throwable t) {</code><code>            <span style="color:#ca7d37">throw</span> <span style="color:#ca7d37">new</span> ExecutionException(<span style="color:#dd1144">"connect event"</span>, channel, getClass() + <span style="color:#dd1144">" error when process connected event ."</span>, t);</code><code>        }</code><code>    }</code><code>    <span style="color:#afafaf"><em>//断开事件</em></span></code><code>    <span style="color:#afafaf">@Override</span></code><code>    <span style="color:#ca7d37">public</span> <span style="color:#ca7d37">void</span> <span style="color:#dd1144">disconnected</span>(Channel channel) <span style="color:#ca7d37">throws</span> RemotingException {</code><code>        ExecutorService executor = getExecutorService();</code><code>        <span style="color:#ca7d37">try</span> {</code><code>            executor.execute(<span style="color:#ca7d37">new</span> ChannelEventRunnable(channel, handler, ChannelState.DISCONNECTED));</code><code>        } <span style="color:#ca7d37">catch</span> (Throwable t) {</code><code>            <span style="color:#ca7d37">throw</span> <span style="color:#ca7d37">new</span> ExecutionException(<span style="color:#dd1144">"disconnect event"</span>, channel, getClass() + <span style="color:#dd1144">" error when process disconnected event ."</span>, t);</code><code>        }</code><code>    }</code><code>    <span style="color:#afafaf"><em>//接收读事件</em></span></code><code>    <span style="color:#afafaf">@Override</span></code><code>    <span style="color:#ca7d37">public</span> <span style="color:#ca7d37">void</span> <span style="color:#dd1144">received</span>(Channel channel, Object message) <span style="color:#ca7d37">throws</span> RemotingException {</code><code>        ExecutorService executor = getExecutorService();</code><code>        <span style="color:#ca7d37">try</span> {</code><code>            executor.execute(<span style="color:#ca7d37">new</span> ChannelEventRunnable(channel, handler, ChannelState.RECEIVED, message));</code><code>        } <span style="color:#ca7d37">catch</span> (Throwable t) {</code><code>            <span style="color:#afafaf"><em>//TODO A temporary solution to the problem that the exception information can not be sent to the opposite end after the thread pool is full. Need a refactoring</em></span></code><code>            <span style="color:#afafaf"><em>//fix The thread pool is full, refuses to call, does not return, and causes the consumer to wait for time out</em></span></code><code>          <span style="color:#ca7d37">if</span>(message <span style="color:#ca7d37">instanceof</span> Request && t <span style="color:#ca7d37">instanceof</span> RejectedExecutionException){</code><code>            Request request = (Request)message;</code><code>            <span style="color:#ca7d37">if</span>(request.isTwoWay()){</code><code>              String msg = <span style="color:#dd1144">"Server side("</span> + url.getIp() + <span style="color:#dd1144">","</span> + url.getPort() + <span style="color:#dd1144">") threadpool is exhausted ,detail msg:"</span> + t.getMessage();</code><code>              Response response = <span style="color:#ca7d37">new</span> Response(request.getId(), request.getVersion());</code><code>              response.setStatus(Response.SERVER_THREADPOOL_EXHAUSTED_ERROR);</code><code>              response.setErrorMessage(msg);</code><code>              channel.send(response);</code><code>              <span style="color:#ca7d37">return</span>;</code><code>            }</code><code>          }</code><code>            <span style="color:#ca7d37">throw</span> <span style="color:#ca7d37">new</span> ExecutionException(message, channel, getClass() + <span style="color:#dd1144">" error when process received event ."</span>, t);</code><code>        }</code><code>    }</code><code>    <span style="color:#afafaf"><em>//异常事件</em></span></code><code>    <span style="color:#afafaf">@Override</span></code><code>    <span style="color:#ca7d37">public</span> <span style="color:#ca7d37">void</span> <span style="color:#dd1144">caught</span>(Channel channel, Throwable exception) <span style="color:#ca7d37">throws</span> RemotingException {</code><code>        ExecutorService executor = getExecutorService();</code><code>        <span style="color:#ca7d37">try</span> {</code><code>            executor.execute(<span style="color:#ca7d37">new</span> ChannelEventRunnable(channel, handler, ChannelState.CAUGHT, exception));</code><code>        } <span style="color:#ca7d37">catch</span> (Throwable t) {</code><code>            <span style="color:#ca7d37">throw</span> <span style="color:#ca7d37">new</span> ExecutionException(<span style="color:#dd1144">"caught event"</span>, channel, getClass() + <span style="color:#dd1144">" error when process caught event ."</span>, t);</code><code>        }</code><code>    }</code><code>}</code></span></span>

dubbo线程池分类

总共4种线程池,默认使用固定大小的线程池。

  • `fixed` 固定大小线程池,启动时建立线程,不关闭,一直持有。(默认)

  • `cached` 缓存线程池,空闲一分钟自动删除,需要时重建。

  • `limited` 可伸缩线程池,但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。

  • `eager` 优先创建`Worker`线程池。在任务数量大于`corePoolSize`但是小于`maximumPoolSize`时,优先创建`Worker`来处理任务。当任务数量大于`maximumPoolSize`时,将任务放入阻塞队列中。阻塞队列充满时抛出`RejectedExecutionException`。(相比`cached`:`cached`在任务数量超过`maximumPoolSize`时直接抛出异常而不是将任务放入阻塞队列)

如果线程如果满了,dubbo会抛异常,按如下提示打印日志。

总结

本文介绍了netty线程池模型和dubbo线程池模型的关系,也分析了dubbo线程池模型分发的策略,最后对dubbo线程池分类进行了分析总结。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: dubboconsumer线模型Dubbo框架中用于处理消费者请求的线模型。它采用的是线程池模型,当有请求到达时,线程池会从中选取一个线程进行处理,处理完毕后线程会返回线程池中等待下一次请求。 然而,由于线程池的大小是有限的,如果在高并发的情况下,线程池中的线程已经全部被占用,新的请求将会被阻塞,导致系统的响应时间变慢甚至出现系统崩溃的情况。因此,在使用dubboconsumer线模型时,需要合理配置线程池的大小,以及采用合适的线程池拒绝策略来避免这些问题。 ### 回答2: Dubbo是一种分布式服务框架,它采用了服务提供者和服务消费者的模式,通过RPC调用实现不同服务间的通信。在Dubbo中,consumer线模型是负责处理服务消费者请求的。然而,这个线模型也存在一些问题。 首先,dubbo consumer线模型默认采用了单一的线程池来处理所有的请求,这意味着所有的请求都依赖于一个线程来处理。当请求量较大时,这个线程池可能会出现饱和的情况,导致请求无法及时得到处理。 其次,由于单一线模型设计,当某个请求发生阻塞的情况时,整个线程池可能会被阻塞。这会导致其他请求也无法得到处理,从而降低系统的吞吐量和并发性能。 另外,单一线模型还存在资源共享的问题。由于所有的请求都依赖于同一个线程池,不同的请求可能会在同一时间访问共享的资源,这会带来并发冲突的问题,可能导致数据不一致性或者资源竞争的情况。 为了解决这些问题,Dubbo推出了可选的线模型,包括线程池和消息队列等。这些线模型可以根据实际需求来选择,以提高系统的吞吐量和并发性能。同时,也可以通过调整线程池的参数来优化系统的资源利用率和响应时间。 总之,Dubbo consumer线模型存在着单一线程池饱和、阻塞和资源共享等问题。然而,通过选择合适的线模型和优化参数,可以提高Dubbo的性能和可靠性。 ### 回答3: dubbo consumer线模型存在以下几个问题: 首先,dubbo consumer线模型采用的是单一线模型,即每个Consumer服务仅使用一个线程来处理所有的请求。这种模式在面对高并发请求时会存在性能瓶颈,请求过多时可能会造成线程无法及时处理请求,导致请求堆积或被丢弃。 其次,单一线模型也存在单点故障的风险。如果Consumer线程出现异常或崩溃,会导致整个服务不可用,无法正常提供服务。此外,由于只有一个线程在处理请求,如果这个线程发生死锁或长时间阻塞,会导致整个应用的性能下降或不可用。 此外,单一线模型也不适用于多核处理器的优势。在现代机器硬件上,多核处理器能够更好地利用并发处理能力。单一线模型无法充分发挥多核处理器的能力,导致性能无法提升。 最后,单一线模型也不便于扩展。当需要增加Consumer的处理能力时,无法简单地通过增加线程数来实现,需要重新设计和实现线模型。 为了解决这些问题,可以考虑使用多线模型,将请求分发给多个线程并行处理,提高系统的并发处理能力和性能。同时,可以引入线程池机制来复用线程资源,避免频繁地创建和销毁线程。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值