通俗易懂的 Dubbo 教程（四）：超时

问题引入

有时远程调用的服务执行时间太慢，消费端不想等待，这该怎么办？没事，Dubbo 给我们提供了一个超时机制，超过指定的时间，直接返回一个超时异常即可。

测试

下面我们来测试一下，在提供者中我们让其睡眠两秒再返回，消费者一切设置正常。

@Component
@Service
public class NameServiceImpl implements NameService {

    @Override
    public String updateName(String name) {
        try {
            Thread.sleep(2000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "修改后的名称:" + name;
    }
}

然后我们在浏览器输入 http://localhost:8081/change/HelloDubbo，让消费者远程调用提供者提供的服务。

提供者显示正常，而消费者报错：

咦，有的同学可能会奇怪了，我都还没设置超时呢，怎么就直接报错了？事实上，Dubbo 对超时的缺省配置为1s，即每个接口的返回时间不得超过1s，否则会抛出异常。

下面我们改一下需求，这个接口的返回时间在3s之内都可以被容忍（天天报错，受不了了!），那么我们的设置应该怎么改？

在消费者中添加如下配置即可。

#设置全局超时控制为3s
dubbo.consumer.timeout=3000

现在我们再远程调用提供者提供的服务，发现可以返回了，说明我们配置的超时设置生效了。

超时针对提供者还是针对消费者

我们接下来考虑一个问题，超时是针对提供者呢，还是针对消费者呢？

超时是针对消费者的，其实 Dubbo 使用的是 NIO 模式，消费端发起请求后会得到一个 ResponseFuture，然后消费端一直轮询这个 ResponseFuture 直至超时或者收到服务端的返回结果。在上面我们的测试中大家也能发现，在超时之后，消费者直接抛出异常，但提供者照样没事似地继续运行，所以显然超时是针对消费者的。

超时需要在哪里设置？

有读者可能会说，咦，博主你之前不是说超时是针对消费者的吗，那肯定得在消费者上设置了！这话说对也不对，说不对也对。为什么呢？

Dubbo 在提供者和消费者中都可以进行相应的设置，但是如果两者都进行设置了，那么就以消费者中的设置为准。

但是我们最好还是在提供者进行相应的配置，为啥？

首先，作为服务的提供者，肯定要比消费者更清楚服务性能参数。再者，如果我们没有配置消费者，会使用提供者的设置作为缺省值。

超时设置的优先级

针对控制的粒度，Dubbo 既支持了接口级别也支持方法级别，还支持全局级别，我们可以根据实际情况精确控制每个方法的超时时间。这里对超时设置的优先级做个总结，最终的优先级如下，从上往下优先级递减。

1. 客户端方法级
2. 服务端方法级
3. 客户端接口级
4. 服务端接口级
5. 客户端全局级
6. 服务端全局级