超时&配置覆盖关系|学习笔记

简介: 快速学习超时&配置覆盖关系

开发者学堂课程【阿里巴巴分布式服务框架 Dubbo 快速入门超时&配置覆盖关系】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址https://developer.aliyun.com/learning/course/624/detail/9467


超时&配置覆盖关系


内容简介:

一、超时设置及代码

二、进行配置

三、配置生效的两个规则


一、超时配置及代码

前面测试了启动时检查这个配置,接下来测试 timeout,即超时设置。

代码为:

<!--timeout=”0”超时-->

<dubbo:reference interface=”com.atguigu.gmall.service.UserService”

Id=”userService” timeout=”0”></dubbo:reference>

超时是用来服务消费方来引用服务提供方时,可能由于网路原因等等,服务提供方要执行一个方法,可能会有很长时间,如果很长时间都没有返回,导致大量线程在这阻塞,可能会引起性能下降,为了解决这个问题,可以指定上超时属性,只要这个方法在指定时间内没有返回,那就立即终止,不让线程大量阻塞。超时设置的单位时毫秒,若 timeout=“3000“,则默认是3秒。


二、进行配置

写一下服务提供者

try{

Thread.sleep(4000);

}catch(InterruptedException   e)  {

//TODO Auto-generated catch block

e.printStackTrace();

}

把服务提供者注册进来,启动注册到注册中心,服务消费者来调用提供者的功能,打开调用代码OrderService orderService=applicationContext.getBean(OrderService.class)

orderService.initOrder(“1”);

(注:在服务提供者已配置超时属性,若没有配置超时属性,需等待调用完成)

启动一下,结果为用户 id,1已经进来,但后续出现报错,报错为 Wating service-side responsetimeout.(等待服务端响应已经超时),但我们并没有设置超时时间,说明超时有一个默认值,在 schema 参考手册中,找到 dubbo:reference,默认使用的是的 timeout,打开 dubbo:consumer 默认值

为1000,也就是说 dubbo 为了考虑服务快速响应,默认超时为1000毫秒。

<!--timeout=”0”默认是1000毫秒-->

<dubbo:reference

interface=”com.atguigu.gmall.service.UserService”

Id=”userService” timeout=”3000”></dubbo:reference>

我们设置 timeout=“3000”,这样也是超时的;

方法 Thread.sleep(4000)至少4000ms才能出来,为了能调用成功,超时 Id=”userService” timeout=”5000”>应写5000ms,重新测试,结果显示调用完成,说明我们超时属性设置有作用了。同样我们知道 dubbo:reference 设置是为单个设置的,dubbo:consumer 是全体设置的,即可在全体设置里设置超时,但规则到底是谁起作用呢,在 XML 配置里,有一处为配置覆盖关系,

下图展示了配置的优先级,越上边是优先起作用的,越下边是后来起作用的。

image.png

image.png

方法级优先,接口级次之,全局配置再次之。

超时属性不仅能配置在 dubbo:reference 标签上,还能有一个<dubbo:method>,method 精确配置 userservice 的方法,例如<dubbo:method name=”getUserAddressList” timeout=“1000“>,即明确指定 geuUserAdressList 方法的超时时间,那么这个超时时间是1000生效还是 id=”userService timeout=“5000”超时时间5000生效,如果1000生效的话要睡4秒多,那么就调用失败了,5000调用成功了,重新测试,发现调用失败,响应超时。

总结一下:

方法级优先,接口级次之,全局配置再次之。还可以用 consumer 配置所有接口,代码为<dubbo:consumer check=”false” timeout=”5000”></dubbo:consumer>

//<配置当前消费者统一规则所有服务都不检查>

方法精确优先,如果没配方法,就用 id=”userService timeout=“5000”这个超时时间,若这个也没有配置,则用<dubbo:consumer check=”false”timeout=”5000”></dubbo:consumer这个超时时间


三、配置生效的两个规则

第一个是精确优先(方法级优先、接口级次之、全局配置再次之)

第二个是消费者配置优先(如果级别一样,则消费方优先,提供方次之)

方法级别的精确级别:

<dubbo:reference>配置:是在服务消费方,引用远程服务时。reference 是消费方引用时优先。

<dubbo:service>配置:服务提供方暴露自己服务时。提供方自己引用时不优先。

接口级别:

<dubbo:reference>

<dubbo:service>

全局配置:

<dubbo:consumer>

<dubbo:provider>

统一设置服务提供方规则为:<dubbo:provider timeout=”1000”>

方法级别在最上面,接口级别在中间,全局配置在最后;每一个级别中都是消费方级别优先,提供方配置次之。

在服务消费方配置一个接口级别的配置超时时间是5000,而在服务提供方配置一个方法级别精确的超时时间为1000,代码为<dubbo:method name=”getUserAddressList timeout=”1000”>,此时这个情况时精确优先还是消费方优先呢,将以前服务停掉,重新注册服务提供者,重新调用服务消费者,结果显示调用失败,说明在服务提供者里方法级别中的1000是起作用的,消费者并没有优先级作用,正是因为级别一样的情况下,消费方优先,提供方次之。

以上是以 timeout 为,显示了配置的查找顺序,其它 retries,loadbanlance,actives 等类似,据按照配置规则。

相关文章
|
3月前
|
SQL DataWorks 数据处理
DataWorks产品使用合集之假设存在时间戳字段: 假设源表有一个记录数据更新时间的字段,如何设置过滤条件
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
21 1
|
3月前
|
SQL 前端开发
大事件后端项目24-----更新文章分类
大事件后端项目24-----更新文章分类
|
3月前
|
监控 Java
记录页面修改差异(java注解实现)
记录页面修改差异(java注解实现)
|
4月前
|
缓存 架构师 NoSQL
五种更新缓存的组合方式
【4月更文挑战第19天】更新缓存的步骤特别简单,共两步:更新数据库和更新缓存。但这简单的两步中需要考虑很多问题。
|
4月前
|
关系型数据库 MySQL 数据库
mysqwl 数据库 设置默认时间 datetime 和 timestamp 实测
mysqwl 数据库 设置默认时间 datetime 和 timestamp 实测
35 0
|
10月前
|
JSON 前端开发 数据格式
全局日期请求转换处理
全局日期请求转换处理
66 0
在线时间戳转换工具的坑-同样的时间戳转为北京时间,转换结果受本机时区设置的影响...
在线时间戳转换工具的坑-同样的时间戳转为北京时间,转换结果受本机时区设置的影响...
244 0
|
JSON 前端开发 关系型数据库
解决mysql 库中间时间查询出来是时间戳方法 【数据库查询出时间,传给前端变为时间戳】【可用】
解决mysql 库中间时间查询出来是时间戳方法 【数据库查询出时间,传给前端变为时间戳】【可用】
310 0
封装时间戳转具体时间工具
封装时间戳转具体时间工具
139 0
封装时间戳转具体时间工具