dubbo超时时间的配置问题

问题

线上一个超时时间设置不合理引起的血案

解决方案

配置超时时间的时候，有两个地方，一个是provider提供的超时参数，一个是consumer提供的超时参数

provider的超时时间就是本系统向外提供的facade的请求超时时间，默认1000ms。consumer是指调用外部的系统接口的超时时间，默认1000ms。

provider的超时时间设置主要是为分析日志提供一些系统运行的情况，并不影响实际的调用过程，因为provider接受到一个请求时，会一直把整个处理逻辑走完，并不会管你是否设置了时间，dubbo只会在方法执行完，判断下

是否超时，如果超时，记一个warn日志。

dubbo的源码如下：

public class TimeoutFilter implements Filter {

    private static final Logger logger = LoggerFactory.getLogger(TimeoutFilter.class);

    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        long start = System.currentTimeMillis();

        Result result = invoker.invoke(invocation);//实际的dubbo接口业务处理

        long elapsed = System.currentTimeMillis() - start;
        if (invoker.getUrl() != null
 && elapsed > invoker.getUrl().getMethodParameter(invocation.getMethodName(),
                        "timeout", Integer.MAX_VALUE)) {
            if (logger.isWarnEnabled()) {
                logger.warn("invoke time out. method: " + invocation.getMethodName()
                        + "arguments: " + Arrays.toString(invocation.getArguments()) + " , url is "
 + invoker.getUrl() + ", invoke elapsed " + elapsed + " ms.");
            }
        }
        return result;
    }
    
}

consumer的超时时间就完全不一样了，当一个请求发出去，当前的请求线程处于锁等待的阻塞状态，而这个condition的唤醒条件1、超时，2、接收到provider的返回。

如果此时我们的provider在升级，又假使jenkins的升级脚本配置的是 kill -9（和运维确认过，是通过kill -9的方式关闭tomcat进程），那条件2是满足不了了，就只能寄希望于条件1即超时。如果此时我们的超时时间设置过大，那整个线程就处于假死状态，直至消耗完整个超时时间。

条件1、等待结果返回

private final Lock lock = new ReentrantLock();

private final Condition done = lock.newCondition();

done.await(timeout, TimeUnit.MILLISECONDS);

条件2、判断超时

private static class RemotingInvocationTimeoutScan implements Runnable {

    public void run() {
        while (true) {
            try {
                for (DefaultFuture future : FUTURES.values()) {
                    if (future == null || future.isDone()) {
                        continue;
                    }
                    if (System.currentTimeMillis() - future.getStartTimestamp() > future.getTimeout()) {
                        // create exception response.
  Response timeoutResponse = new Response(future.getId());
                        // set timeout status.
  timeoutResponse.setStatus(future.isSent() ? Response.SERVER_TIMEOUT : Response.CLIENT_TIMEOUT);
                        timeoutResponse.setErrorMessage(future.getTimeoutMessage(true));
                        // handle response.
  DefaultFuture.received(future.getChannel(), timeoutResponse);
                    }
                }
                Thread.sleep(30);
            } catch (Throwable e) {
                logger.error("Exception when scan the timeout invocation of remoting.", e);
            }
        }
    }
}

综上：

<dubbo:provider timeout="" >尽量设置下，log4j的日志级别需要warn级别，定期到线上去查看warn的日志（如果系统有监控最好了，比如cat，就有比较直观的统计信息），实时关注自己的系统调用情况

<dubbo:consumer timeout="" >如果设（尽量设置下，因为默认是1s，考虑的系统的调用链，1s并不是一个非常适合我们现在系统的设置），一定要设置一个合理的区间（1-5s），不要太大，不要太大，不要太大！！！
如果provider和consumer都设置了超时时间，dubbo会默认优先使用provider的配置。所以作为服务提供者，应该对自己的服务响应时间有所评估。尽量设置为合理的区间