Dubbo逾時和重連機制

dubbo啟動時預設有重試機制和逾時機制。

逾時機制的規則是如果在一定的時間内，provider沒有傳回，則認為本次調用失敗，

重試機制在出現調用失敗時，會再次調用。如果在配置的調用次數内都失敗，則認為此次請求異常，抛出異常。

如果出現逾時，通常是業務處理太慢，可在服務提供方執行：jstack pid > jstack.log 分析線程都卡在哪個方法調用上，這裡就是慢的原因。

如果不能調優性能，請将timeout設大。

某些業務場景下，如果不注意配置逾時和重試，可能會引起一些異常。

dubbo消費端設定逾時時間需要根據業務實際情況來設定，

如果設定的時間太短，一些複雜業務需要很長時間完成，導緻在設定的逾時時間内無法完成正常的業務處理。

這樣消費端達到逾時時間，那麼dubbo會進行重試機制，不合理的重試在一些特殊的業務場景下可能會引發很多問題，需要合理設定接口逾時時間。

比如發送郵件，可能就會發出多份重複郵件，執行注冊請求時，就會插入多條重複的注冊資料。

（1）合理配置逾時和重連的思路

1.對于核心的服務中心，去除dubbo逾時重試機制，并重新評估設定逾時時間。

2.業務處理代碼必須放在服務端，用戶端隻做參數驗證和服務調用，不涉及業務流程處理

（2）dubbo逾時和重連配置示例

1

2

<code>&lt;!-- 服務調用逾時設定為5秒,逾時不重試--&gt;</code> 

<code>&lt;</code><code>dubbo:service</code> <code>interface="com.provider.service.demoservice" ref="demoservice"  retries="0" timeout="5000"/&gt;</code>

dubbo在調用服務不成功時，預設會重試2次。

dubbo的路由機制，會把逾時的請求路由到其他機器上，而不是本機嘗試，是以 dubbo的重試機器也能一定程度的保證服務的品質。

但是如果不合理的配置重試次數，當失敗時會進行重試多次，這樣在某個時間點出現性能問題，調用方再連續重複調用，

系統請求變為正常值的retries倍，系統壓力會大增，容易引起服務雪崩，需要根據業務情況規劃好如何進行異常處理，何時進行重試。