Dubbo?retries超時重試機制的問題怎么解決

本篇內容主要講解“Dubbo retries超時重試機制的問題怎么解決”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“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倍，系統壓力會大增，容易引起服務雪崩，需要根據業務情況規劃好如何進行異常處理，何時進行重試。

補充：下面介紹下dubbo RPC 不能直接傳遞數組類型。

今天遇到一個大坑，提供的一個RPC接口批量查Redis數據，由于數據類型不定，采用<String,Object>的map作為返回類型，查到的結果集其中有一個是數組類型，代碼沒報問題，但一直RPC異常，各種狗屎的嘗試排查，終于定位到問題。

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

目測是dubbo序列化不允許直接傳遞數組類型，后面再研究。

到此，相信大家對“Dubbo retries超時重試機制的問題怎么解決”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！