Dubbo retries 超時重試機制的問題原因分析及解決方案

異常紀錄檔

[com.alibaba.dubbo.rpc.filter.TimeoutFilter] -  [DUBBO] invoke time out. method: sendMessagearguments: [{****內容****}] , url is dubbo://*.*.*.*:20882/cn.demo.api.IDemoProviderApi?anyhost=true&application=demo&dubbo=2.8.4&generic=false&interface=cn.demo.api.IDemoProviderApi&methods=sendMessage,resetSendCount&pid=13008&revision=0.0.1-SNAPSHOT&side=provider&timeout=6000×tamp=1521449123489&version=1.0, invoke elapsed 10863 ms., dubbo version: 2.8.4, current host: 127.0.0.1 

異常原因

dubbo服務提供方,通過註解方式暴露的,引數設定如下:

@Service(version = "1.0", timeout = 6000)

消費方呼叫dubbo服務,請求超時,dubbo服務有超時重試機制,所以對於提交的業務,會有3次呼叫.

解決方案

修改dubbo服務提供方.將timeout超時設為20000ms.或者設定retries=“0”.禁用超時重試機制.

xml方式(消費方):

<!-- 需要消費的api --> 
 <dubbo:consumer check="false" id="dubboConsumerConfig" retries="0"/>

註解方式(提供方):

@Service(version = "1.0", timeout = 20000)

Dubbo超時重試機制

1、請求服務超時，但是最終程式執行了3次,對於提交訂單的業務,只能是新增一個訂單,這樣是不可以的.

2、dubbo:provider 可以設定超時時間 timout，以及如果超時允許被重連的次數 retries.

3、dubbo:reference 可以設定超時時間，以及如果超時 timout，允許重連服務的次數 retries;如果服務方有設定retries,消費方可以不設定該引數.

4、dubbo:reference retries 的預設值和consumer一樣，而consumer預設為2次

dubbo:consumer

retries

default.retries

int

可選

2

#--------以下為轉載--------

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倍，系統壓力會大增，容易引起服務雪崩，需要根據業務情況規劃好如何進行例外處理，何時進行重試。

參考:https://www.cnblogs.com/binyue/p/5380322.html

補充：下面介紹下dubbo RPC 不能直接傳遞陣列型別。

今天遇到一個大坑，提供的一個RPC介面批次查Redis資料，由於資料型別不定，採用<String,Object>的map作為返回型別，查到的結果集其中有一個是陣列型別，程式碼沒報問題，但一直RPC異常，各種狗屎的嘗試排查，終於定位到問題。

最簡單的解決方案是將所有的value都轉化成String型別。

目測是dubbo序列化不允許直接傳遞陣列型別，後面再研究。

到此這篇關於Dubbo retries 超時重試機制的問題的文章就介紹到這了,更多相關Dubbo retries 超時重試內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！