Dubbo之调度Dispatcher

一、Dispatcher介绍
    对于Dubbo集群中的Provider角色，有IO线程池和业务处理线程池（默认200）两个线程池，所以当业务的并发比较高，或者某些业务处理变慢，业务线程池就很容易被“打满”，抛出“RejectedExecutionException: Thread pool is EXHAUSTED! ”异常。

<dubbo:provider version="1.0" delay="-5000" timeout="5000" dispatcher="all" threads="400" loadbalance="leastactive" actives="400" />

二、源码分析


    dubbo默认dispatcher=all，threadpool=fix，Provider在收到请求时会调用AllChannelHandler.received方法，如果业务线程池满了会抛出RejectedExecutionException异常，异常处理会调用AllChannelHandler.catch方法，catch方法也需要线程处理，同样抛出RejectedExecutionException异常，但是没有返回信息给Consumer，Consumer会一直等待，直到timeout。我们修改源码，在异常时返回错误信息给Consumer。



三、Dubbo参数

  参数名 作用范围 默认值 说明

备注

actives	consumer	0	每服务消费者每服务每方法最大并发调用数	0表示不限制
connections	consumer		对每个提供者的最大连接数，rmi、http、hessian等短连接协议表示限制连接数，dubbo等长连接协表示建立的长连接个数	dubbo时为1，及复用单链接
accepts	provider	0	服务提供方最大可接受连接数	0表示不限制
iothreads	provider	cpu个数+1	io线程池大小(固定大小)
threads	provider	200	业务线程池大小(固定大小)
executes	provider	0	服务提供者每服务每方法最大可并行执行请求数	0表示不限制
tps	provider		指定时间内（默认60s）最大的可执行次数，注意与executes的区别	默认不开启

 

  注意表中参数与图中的对应关系：

        1、当consumer发起一个请求时，首先经过active limit(参数actives）进行方法级别的限制，其实现方式为CHM中存放计数器(AtomicInteger)，请求时加1，请求完成（包括异常）减1,如果超过actives则等待有其他请求完成后重试或者超时后失败；

        2、从多个连接(connections）中选择一个连接发送数据，对于默认的netty实现来说，由于可以复用连接，默认一个连接就可以。不过如果你在压测，且只有一个consumer,一个provider，此时适当的加大connections确实能够增强网络传输能力。但线上业务由于有多个consumer多个provider，因此不建议增加connections参数；

        3、连接到达provider时（如dubbo的初次连接），首先会判断总连接数是否超限（acceps），超过限制连接将被拒绝；

        4、连接成功后，具体的请求交给io thread处理。io threads虽然是处理数据的读写，但io部分为异步，更多的消耗的是cpu，因此iothreads默认cpu个数+1是比较合理的设置，不建议调整此参数;

        5、数据读取并反序列化以后，交给业务线程池处理，默认情况下线程池为fixed，且排队队列为0(queues)，这种情况下，最大并发等于业务线程池大小(threads)，如果希望有请求的堆积能力，可以调整queues参数。如果希望快速失败由其他节点处理（官方推荐方式），则不修改queues，只调整threads;

        6、execute limit（参数executes）是方法级别的并发限制，原理与actives类似，只是少了等待的过程，即受限后立即失败