本周是在家办公的一周，上面的图就是我在家的工位。

工欲善其事，必先利其器。在家办公，我是认真的。

在家里开发的时候有需求是这样的：一个如果接口调用失败，需要自动进行重试。

虽然关系不大，但是我还是想到了Dubbo的集群容错策略：Failover Cluster，即失败自动切换。

（这个转折是不是有点生硬.......）

所以借本文对于Dubbo的Cluster集群和Failover Cluster(失败自动切换)策略进行一个详细分析。

本文如果没有特别说明的地方，源码均是来自最新的2.7.5版本。

在阅读之前先抛出几个问题：

1.Dubbo Cluster集群的作用是什么？

2.Dubbo Cluster的10个实现类你能说出来几个，其中哪几个是集群容错的方法实现？

3.默认的集群实现类是什么呢？

4.Failover Cluster调用失败之后，会自动进行几次重试呢？

5.什么是Dubbo的粘滞连接？

6.粘滞连接在Cluster中是怎么应用的？

7.Cluster选择出一个可用的Invoker最多要进行几次选择？

8.请问几次选择分别是什么？

注意：上面的8个问题，前3个是非常常见的面试题。后面的都是你阅读完本文后就可以知道问题的答案，面试中并不常见，但是后面的问题可以综合成一个非常高频的面试题：有看过什么源码吗，能给我讲讲吗？

本文会对上面的问题进行逐一的、详细的解读。文章的最后会进行一个问题和答案的汇总。

废话不多说，看完之后觉得不错，还求个关注。抱拳了，老铁。

Dubbo Cluster集群的作用是什么？

在生产环境，我们常常是多个服务器跑相同的应用，这种做的目的其一是为了避免单点故障。

为了避免单点故障，现在的应用通常至少会部署在两台服务器上。而对于一些负载比较高的服务,比如网关服务，会部署更多的服务器。

这样，在同一环境下的服务提供者数量会大于1。对于服务消费者来说，同一环境下出现了多个服务提供者。

这时会出现几个问题：对于一次请求，我作为消费者到底调用哪个提供者呢？服务调用失败的时候我怎么做呢？是重试？是抛出异常？或者仅仅是打印出异常？

为了处理这些问题，Dubbo定义了集群接口Cluster以及Cluster Invoker。

集群Cluster的用途是将多个服务提供者合并为一个Cluster Invoker，并将这个Invoker暴露给服务消费者。

这样的好处就是对服务消费者来说，只需通过这个Cluster Invoker进行远程调用即可，至于具体调用哪个服务提供者，以及调用失败后如何处理等问题，现在都交给集群模块去处理。

集群模块是服务提供者和服务消费者的中间层，为服务消费者屏蔽了服务提供者的情况，这样服务消费者就可以专心处理远程调用相关事宜。比如发请求，接受服务提供者返回的数据等。这就是Dubbo Cluster集群的作用。

Dubbo Cluster的10个实现类是什么？

根据配置可以知道Dubbo集群接口Cluster有10种实现方法如下：

需要注意的是，十种实现方法其中只有failover、failfast、failsafe、failback、forking、broadcast这6种才属于集群容错的范畴。另外的实现均有其他的应用场景。

下面我们先说6种集群容错的实现方法：

Failover Cluster：

failover=org.apache.dubbo.rpc.cluster.support.FailoverCluster

失败自动切换，在调用失败时，失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过retries="2"来设置重试次数(不含第一次)。

Failfast Cluster：

failfast=org.apache.dubbo.rpc.cluster.support.FailfastCluster

快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

Failsafe Cluster：

failsafe=org.apache.dubbo.rpc.cluster.support.FailsafeCluster

失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

Failback Cluster：

failback=org.apache.dubbo.rpc.cluster.support.FailbackCluster

失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。

Forking Cluster：

forking=org.apache.dubbo.rpc.cluster.support.ForkingCluster

并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。

Broadcast Cluster：

broadcast=org.apache.dubbo.rpc.cluster.support.BroadcastCluster

广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

所以对于这个问题你也可以回答上来了：10个实现类中有哪几个是集群容错的方法实现？

接下来再说说另外四个实现类：

Available Cluster：

available=org.apache.dubbo.rpc.cluster.support.AvailableCluster

获取可用的服务方。遍历所有Invokers通过invoker.isAvalible判断服务端是否活着，只要一个有为true，直接调用返回，不管成不成功。

Mergeable Cluster：

mergeable=org.apache.dubbo.rpc.cluster.support.MergeableCluster

分组聚合，将集群中的调用结果聚合起来，然后再返回结果。比如菜单服务，接口一样，但有多种实现，用group区分，现在消费方需从每种group中调用一次返回结果，合并结果返回，这样就可以实现聚合菜单项。

Mock Cluster：

mock=org.apache.dubbo.rpc.cluster.support.wrapper.MockClusterWrapper

本地伪装，通常用于服务降级，比如某验权服务，当服务提供方全部挂掉后，客户端不抛出异常，而是通过 Mock 数据返回授权失败。

zone-aware Cluster：

zone-aware=org.apache.dubbo.rpc.cluster.support.registry.ZoneAwareCluste

上面的几种Cluster策略在官网都能找到对应的说明，但是对于这个zone-aware目前官网上是没有介绍的，因为这是前段时间发布的2.7.5版本才支持的内容，如下图所示：

所以对于zone-aware这个策略我多说两句。具体可以参照下面的这个issue：

https://github.com/apache/dubbo/issues/5399

zone-aware的应用场景是下面这样的。

业务部署假设是双注册中心：

则对应消费端，先在注册中心间选择，再到选定的注册中心选址：

所以，和之前相比，在Dubbo 2.7.5以后，对于多注册中心订阅的场景，选址时的多了一层注册中心集群间的负载均衡。

这个注册中心集群间的负载均衡的实现就是：zone-aware Cluster。

对于多注册中心间的选址策略，根据类上的注释可以看出，目前设计的有下面四种：

1.指定优先级：

来自preferred="true"注册中心的地址将被优先选择，只有该中心无可用地址时才

Fallback到其他注册中心




<dubbo:registry address="zookeeper://${zookeeper.address1}" preferred="true" />

2.同 zone 优先：

选址时会和流量中的zone key做匹配，流量会优先派发到相同zone的地址

<dubbo:registry address="zookeeper://${zookeeper.address1}" zone="beijing" />

3.权重轮询：

来自北京和上海集群的地址，将以10:1的比例来分配流量

<dubbo:registry id="beijing" address="zookeeper://${zookeeper.address1}" weight="100" />

<dubbo:registry id="shanghai" address="zookeeper://${zookeeper.address2}" weight="10" />

4.默认方法：

选择第一个可用的即可。

默认的集群方法是什么呢？

源码之下无秘密。我们从源码中寻找答案：

首先我们可以看到，Cluster是一个SPI接口。其默认实现是FailoverCluster.NAME，如下源码所示：

所以默认的实现方法就是：

org.apache.dubbo.rpc.cluster.support.FailoverClusterInvoker

由于Cluster是一个SPI接口，所以我们也可以根据实际需求去扩展自己的实现类。