dubbo retries 超时重试机制的问题原因分析及mile米乐体育的解决方案-mile米乐体育
目录
- 异常日志
- 异常原因
- mile米乐体育的解决方案
- dubbo超时重试机制
异常日志
[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次调用.
mile米乐体育的解决方案
修改dubbo服务提供方.将timeout超时设为20000ms.或者设置retries=“0”.禁用超时重试机制.
xml方式(消费方):
注解方式(提供方):
@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消费端设置超时时间需要根据业务实际情况来设定，
如果设置的时间http://www.cppcns.com太短，一些复杂业务需要很长时间完成，导致在设定的超时时间内无法完成正常的业务处理。
这样消费端达到超时时间，那么dubbo会进行重试机制，不合理的重试在一些特殊的业务场景下可能会引发很多问题，需要合理设置接口超时时间。
比如发送邮件，可能就会发出多份重复邮件，执行注册请求时，就会插入多条重复的注册数据。
（1）合理配置超时和重连的思路
1.对于核心的服务中心，去除dubbo超时重试机制，并重新评估设置超时时间。
2.业务处理代码必须放在服务端，客户端只做参数验证和服务调用，不涉及业务流程处理
（2）dubbo超时和重连配置示例
2.重连机制
dubbo在调用服务不成功时，默认会重试2次。
dubbo的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以 dubbo的重试机器也能一定程度的保证服务的质量。
但是如果不合理的配置重试次数，当失败时会进行重试多次，这样在某个时间点出现性能问题，调用方再连续重复调用，
系统请求变为正常值的retries倍，系统压力会大增，容易引起服务雪崩，需要根据业务情况规划好如何进行异常处理，何时进行重试。
参考:https://mip.qiaqa.com/uploads/article/2022/04/22/582.html
补充：下面介绍下dubbo rpc 不能直接传递数组类型。
今天遇到一个大坑，提供的一个rpc接口批量查redis数据，由于数据类型不定，采用
最简单的mile米乐体育的解决方案是将所有的value都转化成string类型。
目测是dubbo序列化不允许直接传递数组类型，后面再研究。
到此这篇关于dubboretries超时重试机制的问题的文章就介绍到这了,更多相关dubboretries超时重试内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！