问题排查-dubbo的重试机制

背景

日志报错，dubbo调用超时，检查是否影响业务系统功能，dubbo有重试机制，error报警 cat filter invoke null ，及多个duubo timeout日志

debug

还原现场debug追踪dubbo调用链

错误日志输出

1、公司xxx封装的AbstractAccessLogFilter都会输出此次错误日志

2、XXXDubboTraceFilter捕获异常打印error日志

3、重试失败与成功分别打印不同日志

4、重试递归代码

5、dubbo请求及捕获异常处理

6、除了以上几种异常重试，业务异常直接抛出不重试

dubbo自带filter,xxx定制filter spi扩展机制,

总结：

DUBBO消费端设置额超时时间不能随心所欲，需要根据业务实际情况来设定，如果设置的时间太短，导致复杂业务本来就需要很长时间完成，导致在设定的超时时间内无法完成正常的业务处理。如果消费端达到超时时间，那么dubbo会进行重试机制（如果配置了dubbo.reference.retries>1），这种情况其实给服务提供端带来莫名的压力，而压力是正常值*dubbo.reference.retries，最终dubbo的消费端会出现RpcException提示retry了多少次还是失败。这种情况就是没有合理设置接口超时时间带来的问题。

重试机制是在等待超时时间到了之后或者服务提供端出现异常进行再次重试的机制。这个并不代表服务提供端完全执行失败了。所以不是所有接口都适合重试，如果一个服务是不等幂，那么不适合重试的机制，因为会存在重复提交的问题，否则是可以进行重试的。比如提交一个订单的接口是不能进行重试的，而查询类型的接口是可以重试的