Dubbo 并发调优的几个参数

时间 2019-11-12

标签 dubbo 并发几个参数栏目 Dubbo 繁體版

原文原文链接

欢迎加入DUBBO交流群：259566260

消费端调优：
1、connections
这个参数能够在服务提供端发布服务的时候配置，也能够在消费端引用服务的时候配置，可是这个值是只对消费端生效的，因此通常是服务提供端不建议配置，若是配置，请斟酌一下，详情请查看《对connections参数的设置》。无论是在消费端或者服务提供端，若是对某个服务配置了connections参数，而且该参数大于1，那么就会致使消费端在建立该服务的远程socketclient的时候（若是是dubbo协议的话）将会给该服务初始化一个私有的socketclient。因此通常不建议对这个值进行调整。
服务端优化调整：
相对余消费端，服务端调优的参数相对多一些，可是配置的时候也须要谨慎。
1、executes
这个参数是能够精确到方法级别的参数，就是能够指定调用远程接口某个方法的是该参数的值。具体是怎么配置的能够到官方文档里面去看看那，这里只是描述这个参数实际意义以及使用的时候应该注意点。
要说这个参数，就要所介绍ExecuteLimitFilter，他是这个参数使用者，看到Filter你们就应该懂了，就是在每一个方法请求先后加上业务逻辑。下面贴出里面的代码： php

@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的异常致使调用服务失败，这是这个参数最终致使的效果。
2、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来讲温柔那么点。这就是那点不一样！
3、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链接的数量限制，而不是像上面两个参数对调用线程的配置。

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