配置的原则
dubbo推荐在Provider上尽量多配置Consumer端属性：
作为服务的提供者，比服务方更清楚服务性能的参数，如调用时间，合理的重试次数等，所以这些参数应尽量配置在服务的提供者方；
在provider配置后，Consumer不配置则会使用provider的配置值，即provider的配置会作为consumer配置的缺省值。如果使用consumer的全局配置，这对于provider是不可控的，并且是不合理的。
当消费者请求一个服务时出现错误，会重试连接其他的服务器，但重试会带来更多的延迟。重试次数可以使用【retries=重试次数】来设置。
Dubbo的超时重试机制为服务容错、服务稳定提供了比较好的框架支持 dubbo在调用服务不成功时，默认会重试2次。Dubbo的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以 dubbo的重试机器也能一定程度的保证服务的质量。,但是在一些比较特殊的网络环境下(网络传输慢,并发多)可能由于服务响应慢,Dubbo自身的超时重试机制(服务端的处理时间超过了设定的超时时间时，就会有重复请求)可能会带来一些麻烦。
常见的应用场景故障: 1、发送邮件(重复) ；2、账户注册(重复).。
解决方案:
1.对于核心的服务中心，去除dubbo超时重试机制，并重新评估设置超时时间。
(1)、去掉超时重试机制 (全局配置)
<dubbo:provider delay="-1" timeout="60000" retries="0"/>
(2)、重新评估设置超时时间 (全局配置)
<dubbo:service interface="*.*" ref="*" timeout="延长服务时间"/>
2.业务处理代码必须放在服务端，客户端只做参数验证和服务调用，不涉及业务流程处理。
一. 配置:
配置优先顺序为：消费端方法级 > 服务端方法级 > 消费端接口级 > 服务端接口级 > 消费端全局 > 服务端全局
1). 注解方式:
在提供者中，reties的值设置在@Service中 默认retries=2,timeout=0
@Service(retries = 3,timeout = 3000)
public class XxxServiceImpl implements IXxxService {}
在消费者中，reties的值设置在@Reference中
@Reference(retries = 3,timeout = 3000,check = false)//check 默认为true,启动时检查服务是否可用
private xxxService xxxService;
2). xml方式:
- 消费端配置:
全局配置
<dubbo:consumer timeout="超时时间" retries="重试次数"></dubbo:consumer>
接口级配置
<dubbo:reference interface="XXXXXXX" id="XXXXXX" timeout="超时时间" retries="重试次数">
<dubbo:method name="XXXXXX" timeout="3000" retries="2"></dubbo:method>
</dubbo:reference>
方法级配置
<dubbo:reference interface="XXXXX" id="XXXXX">
<dubbo:method name="XXXXX" timeout="超时时间" retries="重试次数"></dubbo:method>
</dubbo:reference>
- 服务端配置:
全局配置
<dubbo:provider timeout="超时时间" retries="2"></dubbo:provider>
接口级配置
<dubbo:service interface="XXXXX" ref="XXXXX" timeout="超时时间" retries="重试次数">
<dubbo:method name="XXXXX"></dubbo:method>
</dubbo:service>
方法级配置
<dubbo:service interface="XXXXXX" ref="XXXXX" >
<dubbo:method name="XXXXX" timeout="超时时间" retries="重试次数"></dubbo:method>
</dubbo:service>
文献：
https://www.jianshu.com/p/4dc59c2e9930
https://blog.csdn.net/u013938578/article/details/104250807
