vlambda博客
学习文章列表

敖丙找出Dubbo源码BUG,三歪夸了我一天

背景

某天运营反馈,点了一次保存,但是后台出现了3条数据,我当时就想,不应该啊,这代码我几万年没动了,我当时就叫他先别操作了,保留一下现场,我去排查一下。

我看了下新增的代码,直接右键查看作者

没想到三歪做过改动,我就去问三歪,XX模块的新增代码你是不是动过?

他沉默了很久没说话,然后抓起桌子上用剩下来的纸擦了擦鬓角留下的汗水,咽了一下口水说,是的我改过,我把之前dubbo的xml配置方式改成了注解的方式。

怎么了?现在出BUG了?

你呀你,下次这种改动跟我说一下,我估计是dubbo源码的bug吧,不要慌,让我去看看什么问题。

正文

其实dubbo配置的方式有很多种,大家用的最多的就是xml配置的方式,如果不需要重试次数,我们会加上重试次数为0,因为他默认是有多次的。

<dubbo:reference id="testService" interface="heiidea.trade.service.sdk.interfice.TestService" retries="0"/> 

或者使用注解的方式

@Reference(retries =0

其实我已经大概知道是什么原因了,但是为了证实自己的猜想,于是开启了接下来的debug之旅~~~

注:dubbo版本:2.6.2

首先是在采用@Reference注解条件下:

敖丙找出Dubbo源码BUG,三歪夸了我一天

采用@Reference注解配置重试次数

首先是都找到了dubbo重试的代码位置(启动dubbo项目,到调用接口时,F5进入方法,会跳转到InvokerInvocationHandler中的invoke方法中,继续跟踪进入MockClusterInvoker中的invoke方法,然后进入AbstractClusterInvoker中的invoke方法中,这里主要是拿到配置的负载均衡策略,后面会到FailoverClusterInvoker的doInvoke方法中)。

重点来了,这里会获取配置的retries值,可以看到上面配置的是0,但是取出来居然是null,如图:

敖丙找出Dubbo源码BUG,三歪夸了我一天
value为null

所以会返回defaultValue,加上本身调用的那一次,计算之后就会为3,如图:

敖丙找出Dubbo源码BUG,三歪夸了我一天
值为3

所以可以发现,采用@Reference注解的形式配置retries为0时,dubbo重试次数为2次(3中包含本身调用的那次)。

后面是采用 dubbo:reference 标签的方式:

敖丙找出Dubbo源码BUG,三歪夸了我一天
dubbo标签方式

方式如上,在获取属性的时候,可以看到获得的值为0,和注解形式配置的一致,如图:

敖丙找出Dubbo源码BUG,三歪夸了我一天
value为0

加上本身调用的那一次,计算之后就会为1,如图:

敖丙找出Dubbo源码BUG,三歪夸了我一天
value为1

所以可以发现,采用 dubbo:reference 标签形式配置retries为0时,dubbo重试次数为0(1为本身调用的那次)。

原因分析

首先是@Reference注解形式:

dubbo会把每个接口先解析为ReferenceBean,加上ReferenceBean实现了FactoryBean接口,所以在注入的时候,会调用getObject方法,生成代理对象。

但是这不是关键,因为到这一步时,所有的属性都已经加载完成,所以需要找到dubbo解析注解中属性的代码位置。

dubbo会使用自定义驱动器ReferenceAnnotationBeanPostProcessor来注入属性,而具体执行注入的代码位置是在ReferenceAnnotationBeanPostProcessor类的postProcessPropertyValues方法中调用inject方法执行的。

重点来了,因为采用标签时,是采用@Autowired注解注入,所以是采用spring原生方式注入,而在采用@Reference注解时,注入时会走到dubbo自己的ReferenceAnnotationBeanPostProcessor中私有内部类ReferenceFieldElement的inject方法中,然后调用buildReferenceBean创建ReferenceBean。

离原因越来越近了,在该方法中可以看到beanBuilder中的retries值还是0,说明到这一步还没有被解析为null,如图:

敖丙找出Dubbo源码BUG,三歪夸了我一天
retries为“0”

继续往下走,调用build方法中的configureBean时,在第一步preConfigureBean中方法,在该方法中会创建AnnotationPropertyValuesAdapter对象,在该对象构造方法中会调用adapt方法,然后走到AnnotationUtils中的getAttributes方法中,有一个关键方法nullSafeEquals,该方法会传入当前属性值和默认值。

如果相等,则会忽略掉该属性,然后将符合条件的属性放入actualAttributes这个map中,而我们的retries属性是0,和默认值一致,所以map中不会保存retries属性的值,只有timeout属性,因此出现了后面获取的值为null。

注解方式debug告一段落。

敖丙找出Dubbo源码BUG,三歪夸了我一天
map不包含retries

后面是dubbo:reference标签形式:

上面说到了,标签形式走到inject时,会和注解形式有所不同,采用该标签时,dubbo会使用自定义的名称空间解析器去解析,很容易理解,spring也不知道它自定义标签里面那些玩意儿是什么意思,所以dubbo会继承spring的。

NamespaceHandlerSupport,采用自定义的DubboNamespaceHandler解析器来解析的标签,如下图:

敖丙找出Dubbo源码BUG,三歪夸了我一天
dubbo自定义名称空间解析器

然后调用该类中的parse方法进行解析,而解析retries的地方就是获取class(此时的class就是上图绿色标明的ReferenceBean的class,其父类中有好多好多set方法,其中就包含setRetries方法)中所有的方法,过滤出set开头的方法,然后切割出属性名,放入属性池中,可以看到此处解析出的值为0,并不为null,如下图:

敖丙找出Dubbo源码BUG,三歪夸了我一天
获取属性名的位置
获取retries值为0

小结

画个简单图:

大致流程

结论

  • 采用注解形式:不配置retries或者配置为0,都会重试两次,只有配置为 -1 或更小,才会不执行重试。

  • 采用标签形式:不配置retries会重试两次,配置为0或更小都不会重试。

所以建议大家不需要重试时可以设置为-1,比如增删改操作的接口,否则需要保证幂等性。需要重试则设置为1或更大,其实这应该算dubbo的一个Bug吧?(我觉得是。。)

到这里就结束了,而上面说到的调用getObject方法就是后续服务发现以及和服务端建立长连接并返回代理对象了。

数据出现3条是因为我定义了接口超时的时间比较短,但是我们的新增涉及文件的操作,流程时间比较久,但是线程还是在的,所以dubbo重试了三次,三次也都是成功的了。

我后面把文件操作改成异步,然后主流程是同步的时间就缩短了很多。

补充:2.7.3版本已修复,就是在注解情况下,nullSafeEquals方法中的默认值和后面保持一致了,都是2,所以为0时也能保存到map中。

我是敖丙,一个在互联网苟且偷生的工具人。

你知道的越多,你不知道的越多,人才们的  【三连】 就是丙丙创作的最大动力,我们下期见!