Dubbo 并发调优的几个参数，dubbo并发调优参数

文章由LinuxBoy分享于2019-03-27 08:03:42热评（187）

Dubbo 并发调优的几个参数，dubbo并发调优参数

欢迎加入DUBBO交流群：259566260
消费端调优：
一、connections
这个参数可以在服务提供端发布服务的时候配置，也可以在消费端引用服务的时候配置，但是这个值是只对消费端生效的，所以一般是服务提供端不建议配置，如果配置，请斟酌一下，详情请查看《对connections参数的设置》。不管是在消费端或者服务提供端，如果对某个服务配置了connections参数，并且该参数大于1，那么就会导致消费端在创建该服务的远程socketclient的时候（如果是dubbo协议的话）将会给该服务初始化一个私有的socketclient。所以一般不建议对这个值进行调整。
服务端优化调整：
相对余消费端，服务端调优的参数相对多一些，但是配置的时候也需要谨慎。
一、executes
这个参数是可以精确到方法级别的参数，就是可以指定调用远程接口某个方法的是该参数的值。具体是怎么配置的可以到官方文档里面去看看那，这里只是描述这个参数实际意义以及使用的时候应该注意点。

要说这个参数，就要所介绍ExecuteLimitFilter，他是这个参数使用者，看到Filter大家就应该懂了，就是在每个方法请求前后加上业务逻辑。下面贴出里面的代码：

@Activate(group = Constants.PROVIDER, value = Constants.EXECUTES_KEY)
public class ExecuteLimitFilter implements Filter {
     
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        URL url = invoker.getUrl();
        String methodName = invocation.getMethodName();
        int max = url.getMethodParameter(methodName, Constants.EXECUTES_KEY, 0);
        if (max > 0) {
            RpcStatus count = RpcStatus.getStatus(url, invocation.getMethodName());
            if (count.getActive() >= max) {
                throw new RpcException("Failed to invoke method " + invocation.getMethodName() + " in provider " + url + ", cause: The service using threads greater than <dubbo:service executes=\"" + max + "\" /> limited.");
            }
        }
        long begin = System.currentTimeMillis();
        boolean isException = false;
        RpcStatus.beginCount(url, methodName);
        try {
            Result result = invoker.invoke(invocation);
            return result;
        } catch (Throwable t) {
            isException = true;
            if(t instanceof RuntimeException) {
                throw (RuntimeException) t;
            }
            else {
                throw new RpcException("unexpected exception when ExecuteLimitFilter", t);
            }
        }
        finally {
            RpcStatus.endCount(url, methodName, System.currentTimeMillis() - begin, isException);
        }
    }
     
}

上面这段代码主要是看两个地方，分别是第7行和第10行，第7行是获取配置的executes的值，是一个int类型的，描述数量，然后第10行是获取当前请求方法当前的状态，里面既有一个active属性(该属性是AtomacInteger类型的，大家应该懂了为什么用这个类型)，表示当前请求的方法处于执行状态的线程数量，如果这个值大于或者等于配置的值那么直接抛出异常，那么消费端就会收到一个RPC的异常导致调用服务失败，这是这个参数最终导致的效果。
二、actives
这个参数基本上和excetes一样，但是有一点不同，在说这不同之前，还是看看另一个Filter,看名字你们应该就知道它是做什么的了—— ActiveLimitFilter，下面同样贴出代码：

@Activate(group = Constants.CONSUMER, value = Constants.ACTIVES_KEY)
public class ActiveLimitFilter implements Filter {
     
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        URL url = invoker.getUrl();
        String methodName = invocation.getMethodName();
        int max = invoker.getUrl().getMethodParameter(methodName, Constants.ACTIVES_KEY, 0);
        RpcStatus count = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName());
        if (max > 0) {
            long timeout = invoker.getUrl().getMethodParameter(invocation.getMethodName(), Constants.TIMEOUT_KEY, 0);
            long start = System.currentTimeMillis();
            long remain = timeout;
            int active = count.getActive();
            if (active >= max) {
                synchronized (count) {
                    while ((active = count.getActive()) >= max) {
                        try {
                            count.wait(remain);
                        } catch (InterruptedException e) {
                        }
                        long elapsed = System.currentTimeMillis() - start;
                        remain = timeout - elapsed;
                        if (remain <= 0) {
                            throw new RpcException("Waiting concurrent invoke timeout in client-side for service:  "
                                                   + invoker.getInterface().getName() + ", method: "
                                                   + invocation.getMethodName() + ", elapsed: " + elapsed
                                                   + ", timeout: " + timeout + ". concurrent invokes: " + active
                                                   + ". max concurrent invoke limit: " + max);
                        }
                    }
                }
            }
        }
        try {
            long begin = System.currentTimeMillis();
            RpcStatus.beginCount(url, methodName);
            try {
                Result result = invoker.invoke(invocation);
                RpcStatus.endCount(url, methodName, System.currentTimeMillis() - begin, true);
                return result;
            } catch (RuntimeException t) {
                RpcStatus.endCount(url, methodName, System.currentTimeMillis() - begin, false);
                throw t;
            }
        } finally {
            if(max>0){
                synchronized (count) {
                    count.notify();
                }
            }
        }
    }
     
}

上面代码大致上和executes一样，唯一不同的就是多了一个等待时间，当当前执行该方法的线程超出了最大限制，那么可以等待一个timeout时间，如果时间过了还是超出了最大限制，那么就抛出异常。这个相对余executes来说温柔那么点。这就是那点不同！
三、accepts
在看代码之前先看看这个参数的意思，这个参数是告知服务提供端能接收多少个消费端连接该服务提供方。下面接着上代码，这个参数的体现是在类AbstractServer中。代码如下：

@Override
    public void connected(Channel ch) throws RemotingException {
        Collection<Channel> channels = getChannels();
        if (accepts > 0 && channels.size() > accepts) {
            logger.error("Close channel " + ch + ", cause: The server " + ch.getLocalAddress() + " connections greater than max config " + accepts);
            ch.close();
            return;
        }
        super.connected(ch);
    }

这个方法是每个消费端向服务提供端创建一个socket连接的时候都会触发，上面可以清晰看到如果连接当前服务端的消费端数量超出了配置的值，那么将会关闭当前消费端连接的请求。这个只是对socket连接的数量限制，而不是像上面两个参数对调用线程的配置。

以上归纳出的几个参数建议服务端生效的在服务端配置，消费端生效的在消费端配置，不然会导致一些不可控的现象出现。这也叫改哪里的东西就应该在哪里，而不能乱放。

推荐文章：

Dubbo 并发调优的几个参数，dubbo并发调优参数