配置的原则 dubbo推荐在Provider上尽量多配置Consumer端属性：

作为服务的提供者，比服务方更清楚服务性能的参数，如调用时间，合理的重试次数等，所以这些参数应尽量配置在服务的提供者方； 在provider配置后，Consumer不配置则会使用provider的配置值，即provider的配置会作为consumer配置的缺省值。如果使用consumer的全局配置，这对于provider是不可控的，并且是不合理的。

当消费者请求一个服务时出现错误，会重试连接其他的服务器，但重试会带来更多的延迟。重试次数可以使用【retries=重试次数】来设置。

Dubbo的超时重试机制为服务容错、服务稳定提供了比较好的框架支持 dubbo在调用服务不成功时，默认会重试2次。Dubbo的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以 dubbo的重试机器也能一定程度的保证服务的质量。,但是在一些比较特殊的网络环境下(网络传输慢,并发多)可能由于服务响应慢,Dubbo自身的超时重试机制(服务端的处理时间超过了设定的超时时间时，就会有重复请求)可能会带来一些麻烦。

常见的应用场景故障: 1、发送邮件(重复) ；2、账户注册(重复).。 解决方案: 1.对于核心的服务中心，去除dubbo超时重试机制，并重新评估设置超时时间。 (1)、去掉超时重试机制 (全局配置) (2)、重新评估设置超时时间 (全局配置) 2.业务处理代码必须放在服务端，客户端只做参数验证和服务调用，不涉及业务流程处理。

一. 配置: 配置优先顺序为：消费端方法级 > 服务端方法级 > 消费端接口级 > 服务端接口级 > 消费端全局 > 服务端全局

1). 注解方式: 在提供者中，reties的值设置在@Service中 默认retries=2,timeout=0

在消费者中，reties的值设置在@Reference中

2). xml方式:

接口级配置

方法级配置

接口级配置

方法级配置

文献： https://www.jianshu.com/p/4dc59c2e9930 https://blog.csdn.net/u013938578/article/details/104250807