Dubbo超时配置

问题陈述：

工作中遇到一个问题，服务一通过dubbo调用服务2，问题是最终结果是服务一最终成功了，但是服务二被执行了两次。

问题分析

通过分析报文可以发现，服务二被调用了两次，两次访问时间间隔为3秒，并且都成功了。

而在服务一这边的日志显示，有一个dubbo服务调用超时的异常，然后虽然超时了，但在3秒多的时候又返回了结果，提示warn，然后按照正常的流程走了下去。

最终就是服务一成功执行一次，虽然中间报了超时异常，服务二被调用了两次。

问题解决原理-dubbo超时重连机制

dubbo有这样几个机制

1、如果超时，但是最终返回了正确结果，只是warn，依旧按照正常流程走下去。

2、dubbo:provider 可以设置超时时间 timout，以及如果超时允许被重连的次数 retries

3、dubbo:reference 可以设置超时时间，以及如果超时 timout，允许重连服务的次数 retries

4、dubbo:reference retries 的默认值和consumer一样，而consumer默认为2次

<dubbo:consumer>

retries

default.retries

int

可选

5、说明客户端的配置优先级高于服务端的优先级。

问题解决实践-自己重新配置

1、我的dubbo:provider timeout 是3000 即3秒，而实际调用时3秒多一些，所以把这个延长到60000，当然更长也可以，retries="0"，保持不变。

2、我的dubbo:reference timeout 没有配置，retries也没有配置，现在这两个属性也配置为 timout=“60000” retries="0"

Dubbo是阿里开源的分布式远程调用方案(RPC)，由于网络或服务端不可靠，会导致调用出现一种不确定的中间状态（超时）。为了避免超时导致客户端资源（线程）挂起耗尽，必须设置超时时间。

Provider可以配置的Consumer端主要属性有timeout、retries、loadbalance、actives和cluster。Provider上应尽量多配置些Consumer端的属性，让Provider实现者一开始就思考Provider的服务特点与服务质量。配置之间存在着覆盖，具体规则如下：
1. 方法级配置别优于接口级别，即小Scope优先
2. Consumer端配置优于Provider配置，优于全局配置
3. Dubbo Hard Code的配置值（默认）

根据规则2，纵使消费端配置优于服务端配置，但消费端配置超时时间不能随心所欲，需要根据业务实际情况来设定。如果超时时间设置得太短，复杂业务本来就需要很长时间完成，服务端无法在设定的超时时间内完成业务处理；如果超时时间设置太长，会由于服务端或者网络问题导致客户端资源大量线程挂起。

超时配置

Dubbo消费端
全局超时配置

<dubbo:consumer timeout="5000" />

指定接口以及特定方法超时配置

<dubbo:reference interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:reference>

Dubbo服务端
全局超时配置

<dubbo:provider timeout="5000" />

指定接口以及特定方法超时配置

<dubbo:provider interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:provider>

Dubbo协议超时实现

Dubbo协议超时实现使用了Future模式，主要涉及类DubboInvoker，ResponseFuture,DefaultFuture。
ResponseFuture.get()在请求还未处理完或未到超时前一直是wait状态；响应达到后，设置请求状态，并进行notify唤醒。

    public Object get() throws RemotingException {
        return get(timeout);
    }

    public Object get(int timeout) throws RemotingException {
        if (timeout <= 0) {
            timeout = Constants.DEFAULT_TIMEOUT;
        }
        if (! isDone()) {
            long start = System.currentTimeMillis();
            lock.lock();
            try {
                while (! isDone()) {
                    done.await(timeout,TimeUnit.MILLISECONDS);
                    if (isDone() || System.currentTimeMillis() - start > timeout) {
                        break;
                    }
                }
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            } finally {
                lock.unlock();
            }
            if (! isDone()) {
                throw new TimeoutException(sent > 0,channel,getTimeoutMessage(false));
            }
        }
        return returnFromResponse();
    }

    public static void received(Channel channel,Response response) {
        try {
            DefaultFuture future = FUTURES.remove(response.getId());
            if (future != null) {
                future.doReceived(response);
            } else {
                logger.warn("The timeout response finally returned at " 
                            + (new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS").format(new Date())) 
                            + ",response " + response 
                            + (channel == null ? "" : ",channel: " + channel.getLocalAddress() 
                                + " -> " + channel.getRemoteAddress()));
            }
        } finally {
            CHANNELS.remove(response.getId());
        }
    }

    private void doReceived(Response res) {
        lock.lock();
        try {
            response = res;
            if (done != null) {
                done.signal();
            }
        } finally {
            lock.unlock();
        }
        if (callback != null) {
            invokeCallback(callback);
        }
    }

参考文章：http://blog.csdn.net/bestcxx/article/details/72782981；

http://blog.csdn.net/peerless_hero/article/details/68922880

原文地址：https://blog.csdn.net/guo13313