当服务消费者要进行消费的时候这个时候它可能就开启一个线程去调用服务提供者的具体实现等他返回相应的结果这个时候由于网络的问题或者服务端并不可靠它会在这阻塞很长的一段时间。如果这个服务一直有人在调用那么就会开一堆线程去请求服务提供者。服务端消费者的线程数肯定是有限制的那么所有线程就会阻塞在调用服务。如果没有设置超时那么线程就阻塞在这里一直在这里进行等待。这个就会导致整个服务消费端就不可用了这时候dubbo就提供了超时的机制。对dubbo熟悉的人对下面的配置一定不会陌生dubbo:reference idxxxx interfacexx checktrue asyncfalse retries1 timeout2000/上面设置需要关注的几个地方1.checktrue--系统在启动时就会去检查对应的dubbo服务不存在就报错导致启动失败所以如果设置为true就必须确保该服务提供者一定要在该应用启动之前启动否则就会启动失败2.async--false表明该服务是同步调用而不是异步调用3.retries1 重试一次也就是最多尝试2次如果失败就抛出异常4.timeout2000 服务超时时间单位为毫秒客户端在调用该dubbo服务时会启动超时检测如果达到2秒就会报超时异常超时异常后客户端会尝试1次调用不管失败与否都返回。注需要注意的地方是timeout只有在超时异常才有效如果是其他异常导致dubbo服务调用抛异常会立即进入下一次尝试直接看FailoverClusterInvoker该类是dubbo默认使用的集群调用使用的类。Dubbo 集群容错Design For failure在分布式系统中集群某个某些节点出现问题是大概率事件因此在设计分布式RPC框架的过程中必须要把失败作为设计的一等公民来对待。一次调用失败之后应该如何选择对失败的选择策略这是一个见仁见智的问题每种策略可能都有自己独特的应用场景。因此作为框架来说应当针对不同场景提供多种策略供用户进行选择。在Dubbo设计中通过Cluster这个接口的抽象把一组可供调用的Provider信息组合成为一个统一的Invoker供调用方进行调用。经过路由规则过滤负载均衡选址后选中一个具体地址进行调用如果调用失败则会按照集群配置的容错策略进行容错处理。Dubbo默认内置了若干容错策略如果不能满足用户需求则可以通过自定义容错策略进行配置。内置容错策略Dubbo主要内置了如下几种策略Failover(失败自动切换)Failsafe(失败安全)..............................................Failover(失败自动切换)Failover是高可用系统中的一个常用概念服务器通常拥有主备两套机器配置如果主服务器出现故障则自动切换到备服务器中从而保证了整体的高可用性。Dubbo也借鉴了这个思想并且把它作为Dubbo默认的容错策略。当调用出现失败的时候根据配置的重试次数会自动从其他可用地址中重新选择一个可用的地址进行调用直到调用成功或者是达到重试的上限位置。Dubbo里默认配置的重试次数是2也就是说算上第一次调用最多会调用3次。其配置方法容错策略既可以在服务提供方配置也可以服务调用方进行配置。而重试次数的配置则更为灵活既可以在服务级别进行配置也可以在方法级别进行配置具体优先顺序为服务调用方方法级配置 服务调用方服务级配置 服务提供方方法级配置 服务提供方服务级配置以XML方式为例具体配置方法如下服务提供方服务级配置dubbo:service interfaceorg.apache.dubbo.demo.DemoService refdemoService clusterfailover retries2 /服务提供方方法级配置dubbo:service interfaceorg.apache.dubbo.demo.DemoService refdemoServiceclusterfailover dubbo:method namesayHello retries2 / /dubbo:reference服务调用方服务级配置dubbo:reference iddemoService interfaceorg.apache.dubbo.demo.DemoService clusterfailover retries1/服务调用方方法级配置dubbo:reference iddemoService interfaceorg.apache.dubbo.demo.DemoService clusterfailover dubbo:method namesayHello retries3 / /dubbo:referenceFailover可以自动对失败进行重试对调用者屏蔽了失败的细节但是Failover策略也会带来一些副作用重试会额外增加一下开销例如增加资源的使用在高负载系统下额外的重试可能让系统雪上加霜。重试会增加调用的响应时间。某些情况下重试甚至会造成资源的浪费。考虑一个调用场景A-B-C如果A处设置了超时100ms再B-C的第一次调用完成时已经超过了100ms但很不幸B-C失败这时候会进行重试但其实这时候重试已经没有意义因此在A看来这次调用已经超时A可能已经开始执行其他逻辑。