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

有時遠端呼叫的服務執行時間太慢，消費端不想等待，這該怎麼辦？沒事，dubbo 給我們提供了乙個超時機制，超過指定的時間，直接返回乙個超時異常即可。

下面我們來測試一下，在提供者中我們讓其睡眠兩秒再返回，消費者一切設定正常。

@component
@service
public
class
nameserviceimpl
implements
nameservice
catch
(interruptedexception e)
return
"修改後的名稱:"
+ name;
}}

然後我們在瀏覽器輸入 http://localhost:8081/change/hellodubbo，讓消費者遠端呼叫提供者提供的服務。

提供者顯示正常，而消費者報錯：

咦，有的同學可能會奇怪了，我都還沒設定超時呢，怎麼就直接報錯了？事實上，dubbo 對超時的預設配置為1s，即每個介面的返回時間不得超過1s，否則會丟擲異常。

下面我們改一下需求，這個介面的返回時間在3s之內都可以被容忍（天天報錯，受不了了!），那麼我們的設定應該怎麼改？

在消費者中新增如下配置即可。

#設定全域性超時控制為3s dubbo.consumer.timeout= 3000

現在我們再遠端呼叫提供者提供的服務，發現可以返回了，說明我們配置的超時設定生效了。

我們接下來考慮乙個問題，超時是針對提供者呢，還是針對消費者呢？

超時是針對消費者的，其實 dubbo 使用的是 nio 模式，消費端發起請求後會得到乙個 responsefuture，然後消費端一直輪詢這個 responsefuture 直至超時或者收到服務端的返回結果。在上面我們的測試中大家也能發現，在超時之後，消費者直接丟擲異常，但提供者照樣沒事似地繼續執行，所以顯然超時是針對消費者的。

有讀者可能會說，咦，博主你之前不是說超時是針對消費者的嗎，那肯定得在消費者上設定了！這話說對也不對，說不對也對。為什麼呢？

dubbo 在提供者和消費者中都可以進行相應的設定，但是如果兩者都進行設定了，那麼就以消費者中的設定為準。

但是我們最好還是在提供者進行相應的配置，為啥？

首先，作為服務的提供者，肯定要比消費者更清楚服務效能引數。再者，如果我們沒有配置消費者，會使用提供者的設定作為預設值。

針對控制的粒度，dubbo 既支援了介面級別也支援方法級別，還支援全域性級別，我們可以根據實際情況精確控制每個方法的超時時間。這裡對超時設定的優先順序做個總結，最終的優先順序如下，從上往下優先順序遞減。

客戶端方法級

服務端方法級

客戶端介面級

服務端介面級

客戶端全域性級

服務端全域性級

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

通俗易懂的 Dubbo 教程（六）多版本

通俗易懂的 Dubbo 教程（九）服務降級

C 通俗易懂談反射（四）

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

通俗易懂的 Dubbo 教程（六） 多版本

通俗易懂的 Dubbo 教程（九） 服務降級

C 通俗易懂談反射（四）

相關推薦

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

通俗易懂的 Dubbo 教程（六）多版本

通俗易懂的 Dubbo 教程（九）服務降級