異常日志

[com.alibaba.dubbo.rpc.filter.TimeoutFilter] -  [DUBBO] invoke time out. method: sendMessagearguments: [{****內(nèi)容****}] , 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服務(wù)提供方,通過注解方式暴露的,參數(shù)設(shè)置如下:

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

消費方調(diào)用dubbo服務(wù),請求超時,dubbo服務(wù)有超時重試機制,所以對于提交的業(yè)務(wù),會有3次調(diào)用.

解決方案

修改dubbo服務(wù)提供方.將timeout超時設(shè)為20000ms.或者設(shè)置retries=“0”.禁用超時重試機制.

xml方式(消費方):

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

注解方式(提供方):

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

Dubbo超時重試機制

1、請求服務(wù)超時，但是最終程序執(zhí)行了3次,對于提交訂單的業(yè)務(wù),只能是新增一個訂單,這樣是不可以的.

2、dubbo:provider 可以設(shè)置超時時間 timout，以及如果超時允許被重連的次數(shù) retries.

3、dubbo:reference 可以設(shè)置超時時間，以及如果超時 timout，允許重連服務(wù)的次數(shù) retries;如果服務(wù)方有設(shè)置retries,消費方可以不設(shè)置該參數(shù).

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

dubbo:consumer

retries

default.retries

int

可選

2

#--------以下為轉(zhuǎn)載--------

1.超時設(shè)置

DUBBO消費端設(shè)置超時時間需要根據(jù)業(yè)務(wù)實際情況來設(shè)定，
如果設(shè)置的時間太短，一些復(fù)雜業(yè)務(wù)需要很長時間完成，導(dǎo)致在設(shè)定的超時時間內(nèi)無法完成正常的業(yè)務(wù)處理。
這樣消費端達到超時時間，那么dubbo會進行重試機制，不合理的重試在一些特殊的業(yè)務(wù)場景下可能會引發(fā)很多問題，需要合理設(shè)置接口超時時間。
比如發(fā)送郵件，可能就會發(fā)出多份重復(fù)郵件，執(zhí)行注冊請求時，就會插入多條重復(fù)的注冊數(shù)據(jù)。

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

1.對于核心的服務(wù)中心，去除dubbo超時重試機制，并重新評估設(shè)置超時時間。
2.業(yè)務(wù)處理代碼必須放在服務(wù)端，客戶端只做參數(shù)驗證和服務(wù)調(diào)用，不涉及業(yè)務(wù)流程處理

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

<!-- 服務(wù)調(diào)用超時設(shè)置為5秒,超時不重試--> 
<dubbo:service interface="com.provider.service.DemoService" ref="demoService"  retries="0" timeout="5000"/>

2.重連機制

dubbo在調(diào)用服務(wù)不成功時，默認會重試2次。
Dubbo的路由機制，會把超時的請求路由到其他機器上，而不是本機嘗試，所以 dubbo的重試機器也能一定程度的保證服務(wù)的質(zhì)量。
但是如果不合理的配置重試次數(shù)，當(dāng)失敗時會進行重試多次，這樣在某個時間點出現(xiàn)性能問題，調(diào)用方再連續(xù)重復(fù)調(diào)用，
系統(tǒng)請求變?yōu)檎Ｖ档膔etries倍，系統(tǒng)壓力會大增，容易引起服務(wù)雪崩，需要根據(jù)業(yè)務(wù)情況規(guī)劃好如何進行異常處理，何時進行重試。

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

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

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

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

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

到此這篇關(guān)于Dubbo retries 超時重試機制的問題的文章就介紹到這了,更多相關(guān)Dubbo retries 超時重試內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論