一个dubbo配置超时的问题。求助。

最近有个dubbo的项目,有超时的问题。看了下配置文件
dubbo:reference 里配置的时间300秒 dubbo:registry 里也配置了一个超时时间3秒 各种超时问题

另一个环境两个的时间是反过来配置的,目前没发现这类问题。

想问下大神们,这两个地方配置的timeout作用分别是什么?

0

1个回答

在工作和学习的过程中,具体运用Dubbo的时候遇到了很多的问题,这些问题一方面让自己进一步了解所谓的dubbo,另一方面通过对它们的总结和分析能够在工作中加倍的提高效率,接下来将会对遇到的和别人总结的一些常见的问题进行汇总.

1.增加提供服务版本号和消费服务版本号.

    这个具体来说不算是一个问题,而是一种问题的解决方案,在我们的实际工作中会面临各种环境资源短缺的问题,也是很实际的问题,刚开始我们还可以提供一个服务进行相关的开发和测试,但是当有多个环境多个版本,多个任务的时候就不满足我们的需求,这时候我们可以通过给提供方增加版本的方式来区分.这样能够剩下很多的物理资源,同时为今后更换接口定义发布在线时,可不停机发布,使用版本号.



    引用只会找相应版本的服务,例如

dubbo服务的版本号在项目中非常实用,如果后续系列允许的话,我会专门对dubbo的版本进行一个详细的文章说明.

2.dubbo reference注解问题

   @Reference只能在springbean实例对应的当前类中使用,暂时无法在父类使用;如果确实要在父类声明一个引用,可通过配置文件配置dubbo:reference,然后在需要引用的地方跟引用springbean一样就可以了.

3.服务超时问题.

此问题也是在项目中非常常见的一个问题,但是这个问题背后可能是各种原因导致.

     目前如果存在超时,情况基本都在如下:

(1) 一种情况是服务请求超时.

   客户端耗时大,也就是超时异常时的client elapsedxxx,这个是从创建Future对象开始到使用channel发出请求的这段时间,中间没有复杂操作,只要CPU没问题基本不会出现大耗时,顶多1ms属于正常IOThread繁忙,默认情况下,dubbo协议一个客户端与一个服务提供者会建立一个共享长连接,如果某个客户端处于特别繁忙而且一直往一个服务提供者塞请求,可能造成IOThread阻塞,一般非常特殊的情况才会出现服务端工作线程池中线程全部繁忙,接收消息后塞入队列等待,如果等待时间比预想长会引起超时网络抖动,如果上述情况都排除了,还出现在请求发出后,服务接收请求前超过预想时间,只能归类到网络抖动了,需要SA一起查看问题服务自身耗时大,这个需要应用自身做好耗时统计,当出现这种情况的时候需要用数据来说明问题及规划优化方案,建议采用缓存埋点的方式统计服务中各个执行阶段的耗时情况,最终如果超过预想时间则把缓存统计的耗时情况打日志,减少日志量,且能够得到更明确的信息现在我们应用使用过程中发现两种类型的耗时,一种我们目前只能归类到网络抖动,后续需要找运维一起关注这个问题,另外一种是由于一些历史原因,数据库查询容易发生抖动,总有一个时间点会突然多出很多超时。



    (2) 二大类的情况是调用的版本不对.

在上面我们已经说了具体的版本问题,如果你调用的对方版本不对的话,就相当于你的消费者没有提供者.所以会出现超时,此时只需要把版本对应好即可.

(3)提供者的服务被禁止.

这是一种人为的控制,通过监控中心我们可以对具体的服务,以及它的权重进行控制,当我将一个具体的服务禁止之后消费者就调不到相关的服务,此时就会出现超时的问题.解决方案,取消禁止即可.注意这里有一定时间的缓存,实际操作的时候应该注意.

4.服务保护

     服务保护的原则上是避免发生类似雪崩效应,尽量将异常控制在服务周围,不要扩散开。说到雪崩效应,还得提下dubbo自身的重试机制,默认3次,当失败时会进行重试,这样在某个时间点出现性能问题,然后调用方再连续重复调用,很容易引起雪崩,建议的话还是很据业务情况规划好如何进行异常处理,何时进行重试。服务保护的话 考虑服务的dubbo线程池类型(fix线程池的话考虑线程池大小)、数据库连接池、dubbo连接数限制是否都合适.

5.注册中心的分组group和服务的不同实现group

       这两个东西完全不同的概念,使用的时候不要弄混了。registry上可以配置group,用于区分不同分组的注册中心,比如在同一个注册中心下,有一部分注册信息是要给开发环境用的,有一部分注册信息时要给测试环境用的,可以分别用不同的group区分开,目前对这个理解还不透彻,大致就是用于区分不同环境。service和reference上也可以配置group,这个用于区分同一个接口的不同实现,只有在reference上指定与service相同的group才会被发现。



    以上为5类我们所遇到的问题,总结下来为了以后的路走的更顺畅.

在工作和学习的过程中,具体运用Dubbo的时候遇到了很多的问题,这些问题一方面让自己进一步了解所谓的dubbo,另一方面通过对它们的总结和分析能够在工作中加倍的提高效率,接下来将会对遇到的和别人总结的一些常见的问题进行汇总.

1.增加提供服务版本号和消费服务版本号.

    这个具体来说不算是一个问题,而是一种问题的解决方案,在我们的实际工作中会面临各种环境资源短缺的问题,也是很实际的问题,刚开始我们还可以提供一个服务进行相关的开发和测试,但是当有多个环境多个版本,多个任务的时候就不满足我们的需求,这时候我们可以通过给提供方增加版本的方式来区分.这样能够剩下很多的物理资源,同时为今后更换接口定义发布在线时,可不停机发布,使用版本号.



    引用只会找相应版本的服务,例如

dubbo服务的版本号在项目中非常实用,如果后续系列允许的话,我会专门对dubbo的版本进行一个详细的文章说明.

2.dubbo reference注解问题

   @Reference只能在springbean实例对应的当前类中使用,暂时无法在父类使用;如果确实要在父类声明一个引用,可通过配置文件配置dubbo:reference,然后在需要引用的地方跟引用springbean一样就可以了.

3.服务超时问题.

此问题也是在项目中非常常见的一个问题,但是这个问题背后可能是各种原因导致.

     目前如果存在超时,情况基本都在如下:

(1) 一种情况是服务请求超时.

   客户端耗时大,也就是超时异常时的client elapsedxxx,这个是从创建Future对象开始到使用channel发出请求的这段时间,中间没有复杂操作,只要CPU没问题基本不会出现大耗时,顶多1ms属于正常IOThread繁忙,默认情况下,dubbo协议一个客户端与一个服务提供者会建立一个共享长连接,如果某个客户端处于特别繁忙而且一直往一个服务提供者塞请求,可能造成IOThread阻塞,一般非常特殊的情况才会出现服务端工作线程池中线程全部繁忙,接收消息后塞入队列等待,如果等待时间比预想长会引起超时网络抖动,如果上述情况都排除了,还出现在请求发出后,服务接收请求前超过预想时间,只能归类到网络抖动了,需要SA一起查看问题服务自身耗时大,这个需要应用自身做好耗时统计,当出现这种情况的时候需要用数据来说明问题及规划优化方案,建议采用缓存埋点的方式统计服务中各个执行阶段的耗时情况,最终如果超过预想时间则把缓存统计的耗时情况打日志,减少日志量,且能够得到更明确的信息现在我们应用使用过程中发现两种类型的耗时,一种我们目前只能归类到网络抖动,后续需要找运维一起关注这个问题,另外一种是由于一些历史原因,数据库查询容易发生抖动,总有一个时间点会突然多出很多超时。



    (2) 二大类的情况是调用的版本不对.

在上面我们已经说了具体的版本问题,如果你调用的对方版本不对的话,就相当于你的消费者没有提供者.所以会出现超时,此时只需要把版本对应好即可.

(3)提供者的服务被禁止.

这是一种人为的控制,通过监控中心我们可以对具体的服务,以及它的权重进行控制,当我将一个具体的服务禁止之后消费者就调不到相关的服务,此时就会出现超时的问题.解决方案,取消禁止即可.注意这里有一定时间的缓存,实际操作的时候应该注意.

4.服务保护

     服务保护的原则上是避免发生类似雪崩效应,尽量将异常控制在服务周围,不要扩散开。说到雪崩效应,还得提下dubbo自身的重试机制,默认3次,当失败时会进行重试,这样在某个时间点出现性能问题,然后调用方再连续重复调用,很容易引起雪崩,建议的话还是很据业务情况规划好如何进行异常处理,何时进行重试。服务保护的话 考虑服务的dubbo线程池类型(fix线程池的话考虑线程池大小)、数据库连接池、dubbo连接数限制是否都合适.

5.注册中心的分组group和服务的不同实现group

       这两个东西完全不同的概念,使用的时候不要弄混了。registry上可以配置group,用于区分不同分组的注册中心,比如在同一个注册中心下,有一部分注册信息是要给开发环境用的,有一部分注册信息时要给测试环境用的,可以分别用不同的group区分开,目前对这个理解还不透彻,大致就是用于区分不同环境。service和reference上也可以配置group,这个用于区分同一个接口的不同实现,只有在reference上指定与service相同的group才会被发现。



    以上为5类我们所遇到的问题,总结下来为了以后的路走的更顺畅.
0
Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
其他相关推荐
Dubbo微服务框架中Zookeeper超时问题
一.报错信息截图: 二.主要出现的原因: 确保zookeeper服务正常启动; 检查网络和防火墙; 检查配置文件配置是否正确; 三.本次解决方法: 在dubbo的配置文件中设置超时时间为10000ms项目即可启动。本次出现的问题是因为网络带宽的原因导致,导致我查找了好长时间,让别人插有网线的电脑启动,则可以正常启动,而我的电脑由于没有网口,装了个TPLINK的无线网卡上...
高并发请求dubbo超时,参数调优说明
 dubbo作为一个服务治理框架,功能相对比较完善,性能也挺不错。但很多朋友在使用dubbo的时候,只是简单的参考官方说明进行搭建,并没有过多的去思考一些关键参数的意义,最终做出来的效果有一定的打折。 这里我根据目前我们项目的使用情况列出几个性能调优的参数及其意义。        在介绍参数之前,我们先了解下dubbo中配置的优先级,以免出现调优参数设置了却没发现效果实际是配置被覆盖导致这样的问题...
阿里工作中常见问题答疑丨记一次系统Dubbo调用超时的故障
现象:生产环境用户无法使用下单,订单无法交易。异常日志:分析:发现订单调用商品的API超时了,登陆商品系统并没有发现任何的异常调用,感觉订单的系统调用并没有抵达商品系统,后来陆续发现订单访问其他系统的Dubbo调用都超时了,由此可断定可能是订单系统的问题。首先想到的是数据库的链接数,查看RDS的连接数:可以看到,15点开始,总连接数开始飙升,并且临近最大值480(但是一直没到最大值480),但是活...
dubbo超时的问题
出现dubbo超时的问题要添加timeout 原因:是因为添加了缓存,运行时要先去缓存里面查找,会耗费时间
dubbo的超时机制和重试机制
超时是针对消费端还是服务端? 如果是争对消费端,那么当消费端发起一次请求后,如果在规定时间内未得到服务端的响应则直接返回超时异常,但服务端的代码依然在执行。 如果是争取服务端,那么当消费端发起一次请求后,一直等待服务端的响应,服务端在方法执行到指定时间后如果未执行完,此时返回一个超时异常给到消费端。 dubbo的超时是争对客户端的,由于是一种NIO模式,消费端发起请求后得到一个ResponseFuture,然后消费端一直轮询这个ResponseFuture直至超时或者收到服务端的返回结果。
springboot集成dubbo设置超时和重试
在指定service上添加只针对该类中的该service调用的方法起作用 
Dubbo配置超时时间
当我们做项目遇到问题不知道怎么解决时,往往会想到使用Debug一层一层看一下,但是这就存在一个问题,会出现超时,然后项目报错,这就需要我们配置一下超时时间(默认为1s)了:timeout:超时时间(毫秒),当超过这个时间服务端还未给相应,会重试3次,3次之后还没收到相应,就不再进行重试(可配置)。这里讲超时时间改为了10min。...
Dubbo(十一)--dubbo-配置-超时时间
http://dubbo.apache.org/zh-cn/docs/user/references/xml/dubbo-consumer.html
dubbo配置之属性配置原则、启动检查、超时时间、重试次数、多版本
之前我们简单介绍了dubbo配置服务提供者、消费者以及管理平台监控平台,接下来我们再说一下dubbo的配置。 1.配置策略 1.1 属性配置 dubbo可以在JVM 启动参数、dubboXML、dubbo.properties 三个地方配置,这里我们以端口为例. JVM 启动参数 我们可以在启动项目时盘配置VM参数 -Ddubbo.protocol.port=20883 dubboXML ...
yml设置dubbo超时、重试
yml设置dubbo超时、重试 项目是基于springboot+dubbo。provider、conusme的配置并没有以xml形式。此处记录一下yml配置方法。 如果基于xml配置: <dubbo:service timeout="4000" retries="0" interface="com.test.service.TestService" ref="testServi...
dubbo服务调用超时问题解决方案
dubbo在调用服务不成功时,默认是会重试两次的。这样在服务端的处理时间超过了设定的超时时间时,就会有重复请求,比如在发邮件时,可能就会发出多份重复邮件,执行注册请求时,就会插入多条重复的注册数据,那么怎么解决超时问题呢?如下 1.对于核心的服务中心,去除dubbo超时重试机制,并重新评估设置超时时间。 2.业务处理代码必须放在服务端,客户端只做参数验证和服务调用,不涉及业务流程处理 当
dubbo超时问题
超时机制 Dubbo是阿里开源的分布式远程调用方案(RPC),由于网络或服务端不可靠,会导致调用出现一种不确定的中间状态(超时)。为了避免超时导致客户端资源(线程)挂起耗尽,必须设置超时时间。 Provider可以配置的Consumer端主要属性有timeout、retries、loadbalance、actives和cluster。Provider上应尽量多配置些Consumer端的
Dubbo超时配置
超时机制Dubbo是阿里开源的分布式远程调用方案(RPC),由于网络或服务端不可靠,会导致调用出现一种不确定的中间状态(超时)。为了避免超时导致客户端资源(线程)挂起耗尽,必须设置超时时间。Provider可以配置的Consumer端主要属性有timeout、retries、loadbalance、actives和cluster。Provider上应尽量多配置些Consumer端的属性,让Provi
10.Dubbo配置-【重试,超时(集群容错),启动检查,多版本,本地存根】
1.配置原则 属性配置 如果公共配置很简单,没有多注册中心,多协议等情况,或者想多个 Spring 容器想共享配置,可以使用 dubbo.properties 作为缺省配置。 Dubbo 将自动加载 classpath 根目录下的 dubbo.properties,可以通过JVM启动参数 -Ddubbo.properties.file=xxx.properties 改变缺省配置位置。 映射...
dubbo超时重试
1.此截图来自官网http://dubbo.io,超时的配置关系如下,方法超时参数为findXxx.timeout,接口超时参数为timeout,全局配置超时参数为default.timeout,当提供端url有变动时这几个参数都会设置到url的参数中。 2.超时等参数的设置。 当消费端引用某个接口服务时会订阅提供端服务的相关变动,开源代码的注册中心实现是Zookeeper,当有变动时动触
关于dubbo的超时问题
关于这个问题,一开始是在rsa二次解密的时候出现的。解密成功后但总是无法返回数据。报的是服务器超时。 还以为是因为service注入导致的,后来将解密的方法写出util类,但报的错误和之前一样,瞬间不知所措,在网上查了一下,后来才研究出来是因为dubble的超时问题,可以用下面的形式     <!-- 延迟到Spring初始化完成后,再暴露服务,服务调用超时设置为12秒,超时不重试--...
dubbo服务的超时(timeout)和 重试机制(retires)
节点角色说明:Provider: 暴露服务的服务提供方。Consumer: 调用远程服务的服务消费方。Registry: 服务注册与发现的注册中心。Monitor: 统计服务的调用次调和调用时间的监控中心。Container: 服务运行容器。调用关系说明:0. 服务容器负责启动,加载,运行服务提供者。1. 服务提供者在启动时,向注册中心注册自己提供的服务。2. 服务消费者在启动时,向注册中心订阅自...
dubbo向zookeeper发布服务报错:连接超时
在启动spring+dubbo+zookeeper的项目中,zookeeper是服务的注册中心,provider会向zookeeper发布服务,但是........问题来了,在服务发布时可能 连接不上 zookeeper注册中心,在zookeper部署的服务器上我们需要将zookeeper使用的端口默认为2181 暴露出来否则,zookeeper将连接不上就会报错连接超时。下面说说如何配置zook...
dubbo方法调用的timeout设置
参考dubbo用户手册,方法调用的默认超时时间为1s,但是具体的超时时间受限于服务端方法性能、服务端个数、客户端的并发数等因素,所以超时时间需要根据不同的场景进行调试。 基本步骤为: 测试服务端的TPS,单位为 任务数或线程个数/S,即每秒能够处理的任务数。TPS能够表示出每秒能够处理的任务个数。 根据客户端的并发量要求和服务端的服务能力设置超时时间。例如客户端并发量为R,单个服务端的...
dubbo接口超时时间的优先级
dubbo在服务端和消费端都可以设置接口的超时时间,如果同一个接口,两端都进行了设置,消费端的优先级要高于消费端。 之前一直有这样一个理解:对应TCP的连接,发起请求后,服务端也可以设置超时时间,当超过超时时间,服务端可以中断和客户端的连接。其实这样理解是错误的,服务端是没有超时时间的,所谓的超时其实都是在客户端进行设置,到超过超时时间没有响应,客户端就会处理超时。 dubbo中的超时时间也...
Dubbo的超时重试机制带来的数据重复问题
Dubbo的超时重试机制为服务容错、服务稳定提供了比较好的框架支持,但是在一些比较特殊的网络环境下(网络传输慢,并发多)可能 由于服务响应慢,Dubbo自身的超时重试机制(服务端的处理时间超过了设定的超时时间时,就会有重复请求)可能会带来一些麻烦。         常见的应用场景故障:  1、发送邮件(重复) ;2、账户注册(重复).。         解决方案:  
dubbo服务调用超时问题
dubbo在调用服务不成功时,默认是会重试两次的。这样在服务端的处理时间超过了设定的超时时间时,就会有重复请求,比如在发邮件时,可能就会发出多份重复邮件,执行注册请求时,就会插入多条重复的注册数据,那么怎么解决超时问题呢?如下 1.对于核心的服务中心,去除dubbo超时重试机制,并重新评估设置超时时间。 2.业务处理代码必须放在服务端,客户端只做参数验证和服务调用,不涉及业务流程处理 全局配...
【dobbo】服务配置详解(解决超时重试问题)
官方超时配置实例 全局配置关闭重试 官方api配置 http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-API%E9%85%8D%E7%BD%AE
在dubbox服务中,无法连上注册中心,报连接超时错误的问题
在Dubbox分布式服务中,连不上虚拟机注册中心,报连接超时问题.如下图所示:检查可能是如下两个问题:1.虚拟机的防火墙未关闭.解决如下,关闭防火墙,或者放开注册中心需要的端口关闭防火墙:检查防火墙状态:chkconfig iptables -- list关闭防火墙:service iptables stop关闭防火墙的开机自启动:chkconfig iptables off或者在防火墙设置中放开...
关于dubbo的provider和consumer都配置timeout超时时间的情况
在dubbo的provider和consumer的配置文件中,如果都配置了timeout的超时时间,dubbo默认以provider中配置的时间为准。 经验证是这样的, provider.xml的配置: conusmer中的配置: 最后这个service在调用时的超时时间就是4秒。 另外, 1,consumer会在超过4秒时得到一个调用超时的异常。
Dubbo超时
1、概念  1)服务提供者超时是指远程调用服务的方法执行的超时时间.  2)服务调用者超时是指服务调用者调用远程方法的执行超时时间. 2、超时设置   使用dubbo进行远程调用的过程中,需要设置远程调用的超时间.超时时间分别可以在服务的提供者配置中设置,也可以在服务调用者配置中设置,超时时间的单位是毫秒.   1)全局超时配置 <dubbo:consumer timeout="...
关于dubbox部分rest接口超时问题研究
  业务高峰期部分rest接口超时有一段时间了,之前一直怀疑是kafka、nginx、log4j、网络等原因并进行优化,一直没有太大改观。我们生产共有四台nginx反向代理网关,运维在某台nginx中通过日志grep看到,高峰期   nginx反向代理到后端某台tomcat,每秒达到100+,4台nginx则为400+,已超过tomcat设置的并发连接数和完全连接队列的大小(200+100=...
dubbo异步
相对比与前一个小节来说,异步调用的功能也是很实用的,现在异步化的操作是越来越多了,异步化的好处也是比较明显的,可以加快后台的处理效率,做到代码直接的解耦,Dubbo就是一个支持异步调用的RPC框架 3.2.1 异步调用的场景 假设系统A,远程调用B系统的某个方法,这个方法与数据库的交互很多,逻辑相对复杂,正常的代码执行的时间是3秒,A系统调用完B系统之后,还需要做一些其他的逻辑操作...
使用注解开发dubbox,想在服务层设置请求超时响应,级别是接口方法层,该如何设置啊?
  如图,已经设置了接口实现类级别的请求超时设置,现在想单独给接口实现类里某个方法里设置请求超时响应,该如何做啊,如果 是xml配置开发,我会设置,但是注解开,真不知道怎么设置了,大神麻烦说一下,谢谢了,真的很困扰。...
dubbo 超时设置和源码分析
本文 dubbo 2.6.2 在工作中碰到一个业务接口时间比较长,需要修改超时时间,不知道原理,在网上搜索,看到有人说如果你觉得自己了解了dubbo的超时机制,那么问问自己以下问题: 超时是针对消费端还是服务端? 超时在哪设置? 超时设置的优先级是什么? 超时的实现原理是什么? 超时解决的是什么问题 ? 如果连这些都回答不上了,那只能说明还没有完全掌握 dubbo的超时机制。 于是索性就自己本...
Dubbo 超时与重试的实现分析
重试的实现当消费端发起一次调用,如果集群容错模式选择的是FailoverCluster模式(缺省模式),当调用发生失败会自动发起切换,重试其它服务器。<dubbo:reference> <dubbo:method name="findFoo" retries="2" /> </dubbo:reference>FailoverCluster模式的实现是在 com.alibaba.dubbo.
dubbo的超时时间设置
背景: 该问题源于我的一位同事调用dubbo方法时,在项目组群里咨询我。他调用的方法抛出了超时异常,更为诡异的是过一会(几秒钟),又再次收到了dubbo接口返回值。   问题探寻步骤: 核实下该方法消费者设置的类级别的timeout配置,然后核实了该方法生产者设置的类级别timeout配置。发现消费者设置的超时时间比较短。   dubbo的spring配置建议: 生产者与消费者区分开...
dubbo框架中一行日志代码引发的超时问题
前一段时间有测试反馈,我负责的一个dubbo接口调用超时,而是是稳定必现的超时。拿到问题之后第一件事当然是分析代码所有可能性能瓶颈的地方,然后并没有收获,我们的接口超时时间设置的是5s,然后单测我们的接口时间只有几十ms。相同的数据,测试怎么会出现这么大的差异呢。难道是dubbo接口的配置问题?找我们的dubbo老司机检查了一遍并没有检查出配置问题,而且工程日志也出现任何可疑的错误信息。而且换了几个
谨慎DUBBO超时时间和重试机制
DUBBO消费端设置额超时时间不能随心所欲,需要根据业务实际情况来设定,如果设置的时间太短,导致复杂业务本来就需要很长时间完成,导致在设定的超时时间内无法完成正常的业务处理。如果消费端达到超时时间,那么dubbo会进行重试机制(如果配置了dubbo.reference.retries>1),这种情况其实给服务提供端带来莫名的压力,而压力是正常值*dubbo.reference.retries,最终
dubbo超时机制的底层实现
可以先看这边博客对dubbo的整体架构有个基本的了解DUBBO架构1 dubbo通信机制dubbo是一种NIO模式,消费端发起请求后得到一个ResponseFuture,然后消费端一直轮询这个ResponseFuture直至超时或者收到服务端的返回结果2 第一种超时机制 public Object get(int timeout) throws RemotingException { ...
dubbo接口超时和重试次数问题
背景:如果不设置dubbo解救超时时间,默认是1s,重试次数是2次,在调用dubbo接口时,会存在超过1s的接口响应时间,这时,就会重新发送请求,而在dubbo提供方逻辑还没有走完,就会由于接口响应时间问题而造成bug,在这次事故中是对数据库的操作几乎同时操作造成了SqlMapClient operation; SQL []这个错误。 dubbo默认值: 变量名 描述 默认值 ...
dubbo异常捕获和处理流程
1、dubbo是一套远程rpc框架,那就存在两种角色,一是服务提供者,二是服务调用者;服务提供者有时候需要throw异常,那这个时候客户端是否可以捕获,捕获的机制怎样;if (result.hasException() &amp;amp;&amp;amp; GenericService.class != invoker.getInterface()) {                 try {        ...
dubbo超时机制数据重复__给自己看的
在一些比较特殊的网络环境下(网络传输慢,并发多)可能由于服务响应慢,Dubbo自身的超时重试机制(服务端的处理时间超过了设定的超时时间时,就会有重复请求)可能会带来一些麻烦。 常见的应用场景故障:  1、发送邮件(重复) ;2、账户注册(重复). 解决方案: 1.对于核心的服务中心,去除dubbo超时重试机制,并重新评估设置超时时间。 (a),最好接口增加幂等性 (1)、去掉超时重试机制    ...
调用rpc dubbo接口,事务的回滚无效
需求:循环(数据量不大,最多预计是20多条数据),不计划批量插入。 如果其中一条数据发生插入异常,则本次执行插入的数据,要全部回滚。 流程:for()循环里,rpc调用另一个系统的接口(该接口是插入数据)。 @Transactional(rollbackFor = {Exception.class, RuntimeException.class}) for(){ //rpc,dubbo...
Dubbo超时机制导致的雪崩连接
2014-11-09  categories:资料  author:iigadmin 来源:http://www.taobaotest.com/blogs/2535 BUG作者:许晓 Bug标题:Dubbo超时机制导致的雪崩连接 ​Bug影响:Dubbo服务提供者出现无法获取Dubbo服务处理线程异常,后端DB爆出拿不到数据库连接池,导致前端响应时间异常飙高,系统处理能力下
文章热词 机器学习教程 Objective-C培训 交互设计视频教程 颜色模型 设计制作学习
相关热词 mysql关联查询两次本表 native底部 react extjs glyph 图标 dubbo学习 java 区块链问题