Dubbo超時和重連機制

dubbo啓動時默認有重試機制和超時機制。
超時機制的規則是若是在必定的時間內，provider沒有返回，則認爲本次調用失敗，
重試機制在出現調用失敗時，會再次調用。若是在配置的調用次數內都失敗，則認爲這次請求異常，拋出異常。

若是出現超時，一般是業務處理太慢，可在服務提供方執行：jstack PID > jstack.log 分析線程都卡在哪一個方法調用上，這裏就是慢的緣由。
若是不能調優性能，請將timeout設大。

某些業務場景下，若是不注意配置超時和重試，可能會引發一些異常。

1.超時設置

DUBBO消費端設置超時時間須要根據業務實際狀況來設定，
若是設置的時間過短，一些複雜業務須要很長時間完成，致使在設定的超時時間內沒法完成正常的業務處理。
這樣消費端達到超時時間，那麼dubbo會進行重試機制，不合理的重試在一些特殊的業務場景下可能會引起不少問題，須要合理設置接口超時時間。
好比發送郵件，可能就會發出多份重複郵件，執行註冊請求時，就會插入多條重複的註冊數據。

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

1.對於核心的服務中心，去除dubbo超時重試機制，並從新評估設置超時時間。
2.業務處理代碼必須放在服務端，客戶端只作參數驗證和服務調用，不涉及業務流程處理

（2）Dubbo超時和重連配置示例

 <!-- 服務調用超時設置爲5秒,超時不重試-->  
 <dubbo:service interface="com.provider.service.DemoService" ref="demoService"  retries="0" timeout="5000"/>

2.重連機制

dubbo在調用服務不成功時，默認會重試2次。
Dubbo的路由機制，會把超時的請求路由到其餘機器上，而不是本機嘗試，因此 dubbo的重試機器也能必定程度的保證服務的質量。
可是若是不合理的配置重試次數，當失敗時會進行重試屢次，這樣在某個時間點出現性能問題，調用方再連續重複調用，
系統請求變爲正常值的retries倍，系統壓力會大增，容易引發服務雪崩，須要根據業務狀況規劃好如何進行異常處理，什麼時候進行重試。