異常日志

[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ù)提供方,通過(guò)注解方式暴露的,參數(shù)設(shè)置如下:

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

消費(fèi)方調(diào)用dubbo服務(wù),請(qǐng)求超時(shí),dubbo服務(wù)有超時(shí)重試機(jī)制,所以對(duì)于提交的業(yè)務(wù),會(huì)有3次調(diào)用.

解決方案

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

xml方式(消費(fèi)方):

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

注解方式(提供方):

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

Dubbo超時(shí)重試機(jī)制

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

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

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

4、dubbo:reference retries 的默認(rèn)值和consumer一樣，而consumer默認(rèn)為2次

dubbo:consumer

retries

default.retries

int

可選

2

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

1.超時(shí)設(shè)置

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

（1）合理配置超時(shí)和重連的思路

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

（2）Dubbo超時(shí)和重連配置示例

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

2.重連機(jī)制

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

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

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

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

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

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

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

最新評(píng)論