关于dubbo的超时处理及重试原则
由于网络或服务端不可靠,会导致调用出现一种不确定的中间状态(超时)。
为了避免超时导致客户端资源(线程)挂起耗尽,必须设置超时时间。
超时时间可以使用 timeout="超时次数"
来设置当消费者请求一个服务时出现错误,会重试连接其他的服务器,但重试会带来更多的延迟。
重试次数可以使用 retries=重试次数
来设置。
1. 注解配置如下
- 在提供者中,reties的值设置在@Service中
- 在消费者中,reties的值设置在@Reference中
- 为模拟连接失败,可以采用超时连接;
具体步骤:
- 1.在提供者分服务中添加一个睡眠时间为5秒
- 2.设置消费者访问服务的超时时间为3秒,当服务在3秒后还没有得到结果就会连接失败,并设置次数为2次,虽然设置的次数是2,但是方法会执行3次,第一次是本来就会连的,第二次开始就算入了重试次数
- 3.如果消费者配置了重试次数,提供者也配置了重试次数,则以消费者为准;
消费者的配置
@Service public class OrderServiceImpl implements OrderService { @Reference(timeout=3000, retries=2) private UserService userService; @Override public List<Address> getAddress(String userId) { return userService.getAddress(); } }
提供者的配置
@Service(retries=5) public class UserServiceImpl implements UserService{ private static List<Address> address = new ArrayList<>(); static { address.add(new Address(1, "武汉", "young")); address.add(new Address(2, "河源", "xian")); } @Override public List<Address> getAddress() { System.out.println("provider---1"); return address; } }
2. 在xml文件中配置
在xml文件中配置有多个级别,一个是全局级配置,一个是接口级配置,一个是方法级配置;
在提供者中的配置
方法一,全局级配置:
<dubbo:provider timeout="超时时间" retries="2"></dubbo:provider>
方法二,接口级配置:
<dubbo:service interface="com.young.service.UserService" ref="userServiceImpl" timeout="超时时间" retries="重试次数"> <dubbo:method name="getAddress"></dubbo:method> </dubbo:service>
方法三,方法级配置:
<dubbo:service interface="com.young.service.UserService" ref="userServiceImpl" > <dubbo:method name="getAddress" timeout="超时时间" retries="重试次数"></dubbo:method> </dubbo:service>
其中方法级的配置的优先级>接口级配置的优先级>全局级配置的优先级
在消费者中的配置
方法一,全局级配置:
<dubbo:consumer timeout="超时时间" retries="重试次数"></dubbo:consumer>
方法二,接口级配置
<dubbo:reference interface="com.young.service.UserService" id="userService" timeout="超时时间" retries="重试次数"> <dubbo:method name="getAddress" timeout="3000" retries="2"></dubbo:method> </dubbo:reference>
方法三,方法级配置:
<dubbo:reference interface="com.young.service.UserService" id="userService"> <dubbo:method name="getAddress" timeout="超时时间" retries="重试次数"></dubbo:method> </dubbo:reference>
和提供者一样,消费者的优先级顺序为方法级的配置的优先级>接口级配置的优先级>全局级配置的优先级
配置的原则
dubbo推荐在Provider上尽量多配置Consumer端属性:
- 作为服务的提供者,比服务方更清楚服务性能的参数,如调用时间,合理的重试次数等,所以这些参数应尽量配置在服务的提供者方;
- 在provider配置后,Consumer不配置则会使用provider的配置值,即provider的配置会作为consumer配置的缺省值。如果使用consumer的全局配置,这对于provider是不可控的,并且是不合理的。
配置的覆盖规则
- 方法级的配置的优先级>接口级配置的优先级>全局级配置的优先级,即遵循就近原则,以此为基础;
- 在同级情况下,消费者的优先级大于提供者的优先级;
- 优先级高的会将优先级低的覆盖;
timeout和retries是两个不同的参数,可以设置在不同的级别,但都遵循覆盖原则。
以上面的覆盖规则可以得到如下的所有情况:
总结
以上为个人经验,希望能给大家一个参考,也希望大家多多支持脚本之家。
相关文章
@Controller、@RestController注解区别详解
这篇文章主要介绍了@Controller、@RestController注解区别详解,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧2019-10-10
最新评论