dubbo启动时默认有重试机制和超时机制。
超时机制的规则是如果在一定的时间内，provider没有返回，则认为本次调用失败，
重试机制在出现调用失败时，会再次调用。如果在配置的调用次数内都失败，则认为此次请求异常，抛出异常。
如果出现超时，通常是业务处理太慢，可在服务提供方执行：jstack PID > jstack.log 分析线程都卡在哪个方法调用上，这里就是慢的原因。
如果不能调优性能，请将timeout设大。
某些业务场景下，如果不注意配置超时和重试，可能会引起一些异常。
超时设置
DUBBO消费端设置超时时间需要根据业务实际情况来设定，
如果设置的时间太短，一些复杂业务需要很长时间完成，导致在设定的超时时间内无法完成正常的业务处理。
这样消费端达到超时时间，那么dubbo会进行重试机制，不合理的重试在一些特殊的业务场景下可能会引发很多问题，需要合理设置接口超时时间。
比如发送邮件，可能就会发出多份重复邮件，执行注册请求时，就会插入多条重复的注册数据。
（1）合理配置超时和重连的思路
1.对于核心的服务中心，去除dubbo超时重试机制，并重新评估设置超时时间。
2.业务处理代码必须放在服务端，客户端只做参数验证和服务调用，不涉及业务流程处理
（2）Dubbo超时和重连配置示例
重连机制
dubbo在调用服务不成功时，默认会重试2次。
Dubbo的路由机制，会把超时的请求路由到其他机器上，而不是本机尝试，所以 dubbo的重试机器也能一定程度的保证服务的质量。
但是如果不合理的配置重试次数，当失败时会进行重试多次，这样在某个时间点出现性能问题，调用方再连续重复调用，
系统请求变为正常值的retries倍，系统压力会大增，容易引起服务雪崩，需要根据业务情况规划好如何进行异常处理，何时进行重试。
配置的时候需要注意以下几点：
1、timeout，调用超时时间，默认为1000毫秒，即超过1000毫秒没有返回数据，就会执行重试机制。
2、retries，失败重试次数，默认为2，即失败（超时）之后的重试次数。
3、connections，对每个提供者的最大链接数，默认为100，建议根据服务器配置进行调整。
4、loadbalance，负载均衡策略，默认为random。
5、async，是否异步执行，默认为false。
6、delay，延迟注册服务时间，默认为0，建议不同的接口把暴露服务时间错开，避免dubbo报端口被占用的错误
以上几点，如果服务端和客户端都同事进行了配置，则以客户端优先级更高。
