亲宝软件园·资讯

展开

Dubbo retries 超时重试机制 Dubbo retries 超时重试机制的问题原因分析及解决方案

m0_54861649 人气:0
想了解Dubbo retries 超时重试机制的问题原因分析及解决方案的相关内容吗,m0_54861649在本文为您仔细讲解Dubbo retries 超时重试机制的相关知识和一些Code实例,欢迎阅读和指正,我们先划重点: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倍,系统压力会大增,容易引起服务雪崩,需要根据业务情况规划好如何进行异常处理,何时进行重试。

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

补充:下面介绍下dubbo RPC 不能直接传递数组类型。

今天遇到一个大坑,提供的一个RPC接口批量查Redis数据,由于数据类型不定,采用<String,Object>的map作为返回类型,查到的结果集其中有一个是数组类型,代码没报问题,但一直RPC异常,各种狗屎的尝试排查,终于定位到问题。

最简单的解决方案是将所有的value都转化成String类型。

目测是dubbo序列化不允许直接传递数组类型,后面再研究。

加载全部内容

相关教程
猜你喜欢
用户评论