dubbo线程模型

dubbo的provider有2种线程池: 

  • IO处理线程池。(直接通过netty等来配置)
  • 服务调用线程池。

 

  如果事件处理的逻辑能迅速完成,并且不会发起新的 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时直接抛出异常而不是将任务放入阻塞队列)

 

  上面是摘自官方的解释,下面进行研究:

producer.xml

<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:dubbo="http://dubbo.apache.org/schema/dubbo" xmlns="http://www.springframework.org/schema/beans"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
       http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">

    <!-- 提供方应用信息,用于计算依赖关系 -->
    <dubbo:application name="hello-world-app">
        <!-- 关闭QOS:Quality of Service -->
        <dubbo:parameter key="qos.enable" value="false" />
        <dubbo:parameter key="qos.accept.foreign.ip" value="true" />
        <dubbo:parameter key="qos.port" value="2222" />
    </dubbo:application>

    <dubbo:registry address="zookeeper://127.0.0.1:2181"
        subscribe="false" dynamic="false" />

    <!-- 用dubbo协议在20880端口暴露服务 -->
    <dubbo:protocol name="dubbo" port="20880"/>

    <!-- 声明需要暴露的服务接口 -->
    <dubbo:service interface="dubbo.DubboService" ref="demoService"
        timeout="500000" />

    <!-- 和本地bean一样实现服务 -->
    <bean id="demoService" class="dubbo.DubboServiceImpl" />
</beans>

 

consumer.xml

<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:dubbo="http://dubbo.apache.org/schema/dubbo" xmlns="http://www.springframework.org/schema/beans"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
       http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">

    <!-- 消费方应用名,用于计算依赖关系,不是匹配条件,不要与提供方一样 -->
    <dubbo:application name="consumer-of-helloworld-app">
        <!-- 关闭QOS:Quality of Service -->
        <dubbo:parameter key="qos.enable" value="false" />
    </dubbo:application>

    <!-- 使用multicast广播注册中心暴露发现服务地址 -->
    <dubbo:registry address="zookeeper://127.0.0.1:2181" />

    <!-- 生成远程服务代理,可以和本地bean一样使用demoService -->
    <dubbo:reference id="dubboService" interface="dubbo.DubboService" />
</beans>

Consumer.java开启20个线程消费服务

package dubbo;

import java.util.concurrent.CountDownLatch;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class Consumer {

    private static final Logger LOGGER = LoggerFactory.getLogger(Consumer.class);

    public static void main(String[] args) throws InterruptedException {
        final ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
                new String[] { "consumer.xml" });
        context.start();
        for (int i = 0; i < 20; i++) {
            new Thread(new Runnable() {

                @Override
                public void run() {
                    DubboService service = (DubboService) context.getBean("dubboService");
                    LOGGER.info(service.sayHello(" china "));
                }
            }).start();
        }

        CountDownLatch countDownLatch = new CountDownLatch(1);
        countDownLatch.await();
    }
}

多次访问之后,消费者线程数量会一直增加,并且消费完成之后线程并不会结束,并且每次访问结束都会增加20个线程。如下:

(1)测试  direct  所有消息都不派发到线程池,全部在 IO 线程上直接执行。(多个线程同时请求是一种同步执行的方式,服务端始终只有一条线程处理请求),如下:

    <!-- 用dubbo协议在20880端口暴露服务 -->
    <dubbo:protocol name="dubbo" port="20880" dispatcher="direct"/>

 

查看线程信息:

(2)使用固定fixed线程池处理并且大小定为20

    <!-- 用dubbo协议在20880端口暴露服务 -->
    <dubbo:protocol name="dubbo" port="20880" dispatcher="all"
        threadpool="fixed" threads="20" />

 

多次访问线程数量仍然定在最高的20,不会增加。(这种情况适用于最大并发量是20的请求)

如果同时访问超过20个,会报下面错误:

Exception in thread "Thread-0" com.alibaba.dubbo.rpc.RpcException: Failed to invoke the method sayHello in the service dubbo.DubboService. Tried 3 times of the providers [192.168.0.232:20880] (1/13) from the registry 127.0.0.1:2181 on the consumer 192.168.0.232 using the dubbo version 2.6.6. Last error is: Failed to invoke remote method: sayHello, provider: dubbo://192.168.0.232:20880/dubbo.DubboService?anyhost=true&application=consumer-of-helloworld-app&bean.name=dubbo.DubboService&check=false&dubbo=2.0.2&dynamic=false&generic=false&interface=dubbo.DubboService&methods=sayHello&pid=5132&qos.enable=false&register.ip=192.168.0.232&remote.timestamp=1554373603443&side=consumer&timeout=500000&timestamp=1554374765210, cause: Server side(192.168.0.232,20880) threadpool is exhausted ,detail msg:Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-192.168.0.232:20880, Pool Size: 20 (active: 20, core: 20, max: 20, largest: 20), Task: 67 (completed: 47), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in dubbo://192.168.0.232:20880!
at com.alibaba.dubbo.rpc.cluster.support.FailoverClusterInvoker.doInvoke(FailoverClusterInvoker.java:102)
(3)limited  在同时访问超过线程数的时候多余请求被拒绝

  并且在生产者控制台打印如下信息

18:54:22 [com.alibaba.dubbo.common.threadpool.support.AbortPolicyWithReport]-[WARN]  [DUBBO] Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-192.168.0.232:20880, Pool Size: 20 (active: 20, core: 0, max: 20, largest: 20), Task: 21 (completed: 1), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in dubbo://192.168.0.232:20880!, dubbo version: 2.6.6, current host: 192.168.0.232

 

  多余的客户端请求报错同上面一样,

Server side(192.168.0.232,20880) threadpool is exhausted ,detail msg:Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-192.168.0.232:20880, Pool Size: 20 (active: 20, core: 0, max: 20, largest: 20), Task: 21 (completed: 1), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in dubbo://192.168.0.232:20880!

 

转载于:https://www.cnblogs.com/qlqwjy/p/10656585.html

### 回答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、付费专栏及课程。

余额充值