Dubbo超时和重连机制

dubbo启动时默认有重试机制和超时机制。
超时机制的规则是若是在必定的时间内，provider没有返回，则认为本次调用失败，
重试机制在出现调用失败时，会再次调用。若是在配置的调用次数内都失败，则认为这次请求异常，抛出异常。

若是出现超时，一般是业务处理太慢，可在服务提供方执行：jstack PID > jstack.log 分析线程都卡在哪一个方法调用上，这里就是慢的缘由。
若是不能调优性能，请将timeout设大。

某些业务场景下，若是不注意配置超时和重试，可能会引发一些异常。

1.超时设置

DUBBO消费端设置超时时间须要根据业务实际状况来设定，
若是设置的时间过短，一些复杂业务须要很长时间完成，致使在设定的超时时间内没法完成正常的业务处理。
这样消费端达到超时时间，那么dubbo会进行重试机制，不合理的重试在一些特殊的业务场景下可能会引起不少问题，须要合理设置接口超时时间。
好比发送邮件，可能就会发出多份重复邮件，执行注册请求时，就会插入多条重复的注册数据。

（1）合理配置超时和重连的思路

1.对于核心的服务中心，去除dubbo超时重试机制，并从新评估设置超时时间。
2.业务处理代码必须放在服务端，客户端只作参数验证和服务调用，不涉及业务流程处理

（2）Dubbo超时和重连配置示例

 <!-- 服务调用超时设置为5秒,超时不重试-->  
 <dubbo:service interface="com.provider.service.DemoService" ref="demoService"  retries="0" timeout="5000"/>

2.重连机制

dubbo在调用服务不成功时，默认会重试2次。
Dubbo的路由机制，会把超时的请求路由到其余机器上，而不是本机尝试，因此 dubbo的重试机器也能必定程度的保证服务的质量。
可是若是不合理的配置重试次数，当失败时会进行重试屡次，这样在某个时间点出现性能问题，调用方再连续重复调用，
系统请求变为正常值的retries倍，系统压力会大增，容易引发服务雪崩，须要根据业务状况规划好如何进行异常处理，什么时候进行重试。