Dubbo应用与异常记录

简介: 结合项目里使用暴露出的问题,对并发较多的核心业务或者对请求失败等敏感的业务场景不太建议使用Dubbo, 如电商的购买等行为,使用Dubbo就必须阅读源码,熟悉相关机制,或者直接自己造轮子。

结合项目里使用暴露出的问题,对并发较多的核心业务或者对请求失败等敏感的业务场景不太建议使用Dubbo,

如电商的购买等行为,使用Dubbo就必须阅读源码,熟悉相关机制,或者直接自己造轮子。

1.使用Dubbo踩过的坑

(1)Spring Cache在Service层对消费者不起作用
原因是:Spring容器还未加载完,就在Dubbo中暴露服务导致Cache的AOP不可用。因此需要将服务放在Spring容器加载完后再暴露。

(2)Dubbo对方法重载支持有问题

如果让hessian支持调用重载方法需要isOverloadEnabled()设为false。


2.Dubbo常见异常和错误

(1)调用超时com.alibaba.dubbo.remoting.TimeoutException异常
通常是业务处理太慢,可在服务提供方执行:jstack PID > jstack.log 分析线程都卡在哪个方法调用上,这里就是慢的原因。
如果不能调优性能,请将timeout设大。

(2)出现java.util.concurrent.RejectedExecutionException或者Thread pool exhausted

RejectedExecutionException表示线程池已经达到最大值,并且没有空闲连,拒绝执行了一些任务。
Thread pool exhausted通常是min和max不一样大时,表示当前已创建的连接用完,进行了一次扩充,创建了新线程,但不影响运行。
原因可能是连接池不够用,请调整dubbo.properites中的:

1
2
3
// 设成一样大,减少线程池收缩开销
dubbo.service.min.thread.pool.size= 200
dubbo.service.max.thread.pool.size= 200

  

3.dubbo如何正确关闭Spring容器

Dubbo是通过JDK的ShutdownHook来完成优雅停机的,所以如果用户使用"kill -9 PID"等强制关闭指令,是不会执行优雅停机的,只有通过"kill PID"时,才会执行。
服务提供方停止时,先标记为不接收新请求,新请求过来时直接报错,让客户端重试其它机器。
然后,检测线程池中的线程是否正在运行,如果有,等待所有线程执行完成,除非超时,则强制关闭。
服务消费方停止时,不再发起新的调用请求,所有新的调用在客户端即报错。
然后,检测有没有请求的响应还没有返回,等待响应返回,除非超时,则强制关闭。
设置优雅停机超时时间,缺省超时时间是10秒:(超时则强制关闭)

1
2
3
<dubbo:application ...>
     <dubbo:parameter key= "shutdown.timeout"  value= "60000"  /> <!-- 单位毫秒 -->
</dubbo:application>

看一下源码实现:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
if  ( "true" .equals(System.getProperty( "dubbo.shutdown.hook" ))) {
         Runtime.getRuntime().addShutdownHook( new  Thread() {
           public  void  run() {
             for  (Container container :  this .val$containers) {
               try  {
                 container.stop();
                 Main.logger.info( "Dubbo "  + container.getClass().getSimpleName() +  " stopped!" );
               catch  (Throwable t) {
                 Main.logger.error(t.getMessage(), t);
               }
               synchronized  (Main. class ) {
                 Main.access$ 102 ( false );
                 Main. class .notify();
               }
             }
           }
         });
       }

 


目录
相关文章
|
23天前
|
NoSQL Java Redis
Seata常见问题之实现openfeign远程调用失败如何解决
Seata 是一个开源的分布式事务解决方案,旨在提供高效且简单的事务协调机制,以解决微服务架构下跨服务调用(分布式场景)的一致性问题。以下是Seata常见问题的一个合集
Seata常见问题之实现openfeign远程调用失败如何解决
|
3月前
|
负载均衡 Dubbo 算法
深入理解Dubbo-2.Dubbo功能之高级特性分析
深入理解Dubbo-2.Dubbo功能之高级特性分析
56 0
|
26天前
|
Dubbo Java 应用服务中间件
nacos常见问题之dubbo的耗时严重如何解决
Nacos是阿里云开源的服务发现和配置管理平台,用于构建动态微服务应用架构;本汇总针对Nacos在实际应用中用户常遇到的问题进行了归纳和解答,旨在帮助开发者和运维人员高效解决使用Nacos时的各类疑难杂症。
50 0
|
8月前
|
Dubbo 应用服务中间件 微服务
|
3月前
|
消息中间件 Dubbo 安全
深入理解Dubbo-8.Dubbo的失败重试设计
深入理解Dubbo-8.Dubbo的失败重试设计
47 0
|
5月前
|
缓存 Dubbo Java
Dubbo的优雅下线原理分析
在线上环境,用到更多的,是kill pid指令,这个指令,等同于kill -15 pid指令,因此,当你在网上看到一些介绍kill -15 pid指令时,不用纠结好像没用到过,其实,就是你用到最多的kill pid指令。使用这个指令时,系统会对pid进程发送一个SIGTERM信号,就像给pid打了一个电话,告诉他,你的房子就要到期了,麻烦快点清理好东西搬走。这时,你仍有充裕的时间,把自己的东西打包好,好好清理下房间,没问题了,再搬出去。
30 0
|
8月前
|
XML Dubbo 应用服务中间件
Dubbo偶现无法注入服务
Dubbo偶现无法注入服务
139 0
|
12月前
|
存储 JavaScript 小程序
SpringCloud 三种服务调用方式,你学会了吗?
SpringCloud 三种服务调用方式,你学会了吗?
|
缓存 负载均衡 监控
《我想进大厂》之Dubbo普普通通9问
这是面试专题系列第四篇,Dubbo系列。Dubbo本身并不复杂,而且官方文档写的非常清楚详细,面试中dubbo的问题一般不会很多,从分层到工作原理、负载均衡策略、容错机制、SPI机制基本就差不多了,最大的一道大题一般就是怎么设计一个RPC框架了,但是如果你工作原理分层都搞明白了这个问题其实也就相当于回答了不是吗。
《我想进大厂》之Dubbo普普通通9问
|
Dubbo Java 应用服务中间件
我发现一个关于Dubbo服务调用的一个BUG
我发现一个关于Dubbo服务调用的一个BUG
我发现一个关于Dubbo服务调用的一个BUG