转自dubbo官网文档http://dubbo.apache.org/zh-cn/blog/dubbo-cluster-error-handling.html

Design For failure

在分布式系统中,集群某个某些节点出现问题是大概率事件,因此在设计分布式RPC框架的过程中,必须要把失败作为设计的一等公民来对待。一次调用失败之后,应该如何选择对失败的选择策略,这是一个见仁见智的问题,每种策略可能都有自己独特的应用场景。因此,作为框架来说,应当针对不同场景提供多种策略,供用户进行选择。

在Dubbo设计中,通过Cluster这个接口的抽象,把一组可供调用的Provider信息组合成为一个统一的Invoker供调用方进行调用。经过路由规则过滤,负载均衡选址后,选中一个具体地址进行调用,如果调用失败,则会按照集群配置的容错策略进行容错处理。

Dubbo默认内置了若干容错策略,如果不能满足用户需求,则可以通过自定义容错策略进行配置。

内置容错策略

Dubbo主要内置了如下几种策略:

  • Failover(失败自动切换)
  • Failsafe(失败安全)
  • Failfast(快速失败)
  • Failback(失败自动恢复)
  • Forking(并行调用)
  • Broadcast(广播调用)

这些名称比较相似,概念也比较容易混淆,下面逐一进行解释。

Failover(失败自动切换)

Failover是高可用系统中的一个常用概念,服务器通常拥有主备两套机器配置,如果主服务器出现故障,则自动切换到备服务器中,从而保证了整体的高可用性。

Dubbo也借鉴了这个思想,并且把它作为Dubbo默认的容错策略。当调用出现失败的时候,根据配置的重试次数,会自动从其他可用地址中重新选择一个可用的地址进行调用,直到调用成功,或者是达到重试的上限位置。

Dubbo里默认配置的重试次数是2,也就是说,算上第一次调用,最多会调用3次。

其配置方法,容错策略既可以在服务提供方配置,也可以服务调用方进行配置。而重试次数的配置则更为灵活,既可以在服务级别进行配置,也可以在方法级别进行配置。具体优先顺序为:

服务调用方方法级配置 > 服务调用方服务级配置 > 服务提供方方法级配置 > 服务提供方服务级配置

以XML方式为例,具体配置方法如下:

服务提供方,服务级配置

<dubbo:service interface="org.apache.dubbo.demo.DemoService" ref="demoService" cluster="failover" retries="2" />

服务提供方,方法级配置

<dubbo:service interface="org.apache.dubbo.demo.DemoService" ref="demoService"cluster="failover">
<dubbo:method name="sayHello" retries="2" />
</dubbo:reference>

服务调用方,服务级配置

<dubbo:reference id="demoService" interface="org.apache.dubbo.demo.DemoService" cluster="failover" retries="1"/>

服务调用方,方法级配置:

 <dubbo:reference id="demoService" interface="org.apache.dubbo.demo.DemoService" cluster="failover">
<dubbo:method name="sayHello" retries="3" />
</dubbo:reference>

Failover可以自动对失败进行重试,对调用者屏蔽了失败的细节,但是Failover策略也会带来一些副作用:

  • 重试会额外增加一下开销,例如增加资源的使用,在高负载系统下,额外的重试可能让系统雪上加霜。
  • 重试会增加调用的响应时间。
  • 某些情况下,重试甚至会造成资源的浪费。考虑一个调用场景,A->B->C,如果A处设置了超时100ms,再B->C的第一次调用完成时已经超过了100ms,但很不幸B->C失败,这时候会进行重试,但其实这时候重试已经没有意义,因此在A看来这次调用已经超时,A可能已经开始执行其他逻辑。

Failsafe(失败安全)

失败安全策略的核心是即使失败了也不会影响整个调用流程。通常情况下用于旁路系统或流程中,它的失败不影响核心业务的正确性。在实现上,当出现调用失败时,会忽略此错误,并记录一条日志,同时返回一个空结果,在上游看来调用是成功的。

应用场景,可以用于写入审计日志等操作。

Failfast(快速失败)

某些业务场景中,某些操作可能是非幂等的,如果重复发起调用,可能会导致出现脏数据等。例如调用某个服务,其中包含一个数据库的写操作,如果写操作完成,但是在发送结果给调用方的过程中出错了,那么在调用发看来这次调用失败了,但其实数据写入已经完成。这种情况下,重试可能并不是一个好策略,这时候就需要使用到Failfast策略,调用失败立即报错。让调用方来决定下一步的操作并保证业务的幂等性。

Failback(失败自动恢复)

Failback通常和Failover两个概念联系在一起。在高可用系统中,当主机发生故障,通过Failover进行主备切换后,待故障恢复后,系统应该具备自动恢复原始配置的能力。

Dubbo中的Failback策略中,如果调用失败,则此次失败相当于Failsafe,将返回一个空结果。而与Failsafe不同的是,Failback策略会将这次调用加入内存中的失败列表中,对于这个列表中的失败调用,会在另一个线程中进行异步重试,重试如果再发生失败,则会忽略,即使重试调用成功,原来的调用方也感知不到了。因此它通常适合于,对于实时性要求不高,且不需要返回值的一些异步操作。

按照目前的实现,Failback策略还有一些局限,例如内存中的失败调用列表没有上限,可能导致堆积,异步重试的执行间隔无法调整,默认是5秒。

Forking(并行调用)

上述几种策略中,主要都是针对调用失败发生后如何进行弥补的角度去考虑的,而Forking策略则跟上述几种策略不同,是一种典型的用成本换时间的思路。即第一次调用的时候就同时发起多个调用,只要其中一个调用成功,就认为成功。在资源充足,且对于失败的容忍度较低的场景下,可以采用此策略。

Broadcast(广播调用)

在某些场景下,可能需要对服务的所有提供者进行操作,此时可以使用广播调用策略。此策略会逐个调用所有提供者,只要任意有一个提供者出错,则认为此次调用出错。通常用于通知所有提供者更新缓存或日志等本地资源信息。

各种策略对比

下表对各种策略做一个简单对比,

策略名称 优点 缺点 主要应用场景
Failover 对调用者屏蔽调用失败的信息 增加RT,额外资源开销,资源浪费 对调用rt不敏感的场景
Failfast 业务快速感知失败状态进行自主决策 产生较多报错的信息 非幂等性操作,需要快速感知失败的场景
Failsafe 即使失败了也不会影响核心流程 对于失败的信息不敏感,需要额外的监控 旁路系统,失败不影响核心流程正确性的场景
Failback 失败自动异步重试 重试任务可能堆积 对于实时性要求不高,且不需要返回值的一些异步操作
Forking 并行发起多个调用,降低失败概率 消耗额外的机器资源,需要确保操作幂等性 资源充足,且对于失败的容忍度较低,实时性要求高的场景
Broadcast 支持对所有的服务提供者进行操作 资源消耗很大 通知所有提供者更新缓存或日志等本地资源信息

自定义容错策略

如果上述内置的容错策略无法满足你的需求,还可以通过扩展的方式来实现自定义容错策略。

扩展接口

com.alibaba.dubbo.rpc.cluster.Cluster

扩展配置

<dubbo:service cluster="xxx" />

扩展示例

下面通过一个例子来展示如何使用自定义的容错策略。 Maven 项目结构:

src
|-main
|-java
|-com
|-xxx
|-XxxCluster.java (实现Cluster接口)
|-resources
|-META-INF
|-dubbo
|-org.apache.dubbo.rpc.cluster.Cluster (纯文本文件,内容为:xxx=com.xxx.XxxCluster)

XxxCluster.java:

package com.xxx;

import org.apache.dubbo.rpc.cluster.Cluster;
import org.apache.dubbo.rpc.cluster.support.AbstractClusterInvoker;
import org.apache.dubbo.rpc.cluster.Directory;
import org.apache.dubbo.rpc.cluster.LoadBalance;
import org.apache.dubbo.rpc.Invoker;
import org.apache.dubbo.rpc.Invocation;
import org.apache.dubbo.rpc.Result;
import org.apache.dubbo.rpc.RpcException; import java.util.List; public class XxxCluster implements Cluster { @Override
public <T> Invoker<T> join(Directory<T> directory) throws RpcException {
return new AbstractClusterInvoker<T>() {
@Override
protected Result doInvoke(Invocation invocation, List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
// your custimzed fault tolarence strategy goes here
}
};
} }

META-INF/dubbo/com.alibaba.dubbo.rpc.cluster.Cluster文件的内容为

xxx=com.xxx.XxxCluster

Dubbo集群容错的更多相关文章

  1. Dubbo学习(二) Dubbo 集群容错模式-负载均衡模式

    Dubbo是Alibaba开源的分布式服务框架,我们可以非常容易地通过Dubbo来构建分布式服务,并根据自己实际业务应用场景来选择合适的集群容错模式,这个对于很多应用都是迫切希望的,只需要通过简单的配 ...

  2. dubbo集群容错解决方案

    dubbo主要核心部件 Remoting:网络通信框架,实现了sync-over-async和request-response消息机制. RPC:一个远程过程调用的抽象,支持负载均衡.容灾和集群功能. ...

  3. dubbo集群容错之LoadBalance

    原文地址:Dubbo 源码分析 - 集群容错之 LoadBalance dubbo 提供了4种负载均衡实现,分别是基于权重随机算法的 RandomLoadBalance.基于最少活跃调用数算法的 Le ...

  4. Dubbo 集群容错有几种方案?

    集群容错方案 说明 Failover Cluster 失败自动切换,自动重试其它服务器(默认) Failfast Cluster 快速失败,立即报错,只发起一次调用 Failsafe Cluster ...

  5. Dubbo 源码分析 - 集群容错之 Cluster

    1.简介 为了避免单点故障,现在的应用至少会部署在两台服务器上.对于一些负载比较高的服务,会部署更多台服务器.这样,同一环境下的服务提供者数量会大于1.对于服务消费者来说,同一环境下出现了多个服务提供 ...

  6. Dubbo 源码分析 - 集群容错之 Directory

    1. 简介 前面文章分析了服务的导出与引用过程,从本篇文章开始,我将开始分析 Dubbo 集群容错方面的源码.这部分源码包含四个部分,分别是服务目录 Directory.服务路由 Router.集群 ...

  7. dubbo源码解析五 --- 集群容错架构设计与原理分析

    欢迎来我的 Star Followers 后期后继续更新Dubbo别的文章 Dubbo 源码分析系列之一环境搭建 博客园 Dubbo 入门之二 --- 项目结构解析 博客园 Dubbo 源码分析系列之 ...

  8. Dubbo负载均衡与集群容错机制

    1  Dubbo简介 Dubbo是一款高性能.轻量级的开源Java RPC框架,它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现. 作为一个轻量级RPC框架,D ...

  9. dubbo负载均衡策略和集群容错策略都有哪些

    dubbo负载均衡策略 random loadbalance 默认情况下,dubbo是random load balance随机调用实现负载均衡,可以对provider不同实例设置不同的权重,会按照权 ...

随机推荐

  1. mongoose 入门基本操作

    简介 Mongoose是在node.js异步环境下对mongodb进行便捷操作的对象模型工具 那么要使用它,首先你得装上node.js和mongodb,关于mongodb的安装和操作介绍可以参考:ht ...

  2. [转]ubuntu ssh登陆显示系统信息

    Welcome to Ubuntu LTS (GNU/Linux --generic i686) * Documentation: https://help.ubuntu.com/ System in ...

  3. 编译安装openssl

    wget https://www.openssl.org/source/openssl-1.1.0g.tar.gztar xf openssl-1.1.0g.tar.gzcd openssl-1.1. ...

  4. mysql问题处理积累

    1.mysql errors:message from server: "Host 'xxx' is blocked because of many connection errors; u ...

  5. HAProxy+keepalived+MySQL 实现MHA中slave集群负载均衡的高可用

    HAProxy+keepalived+MySQL实现MHA中slave集群的负载均衡的高可用 Ip地址划分: 240    mysql_b2 242    mysql_b1 247    haprox ...

  6. 如何停止处于stopping状态的windows服务

    工作中有时需要启动和停止windows service,有时候会出现服务处于stopping或者starting的状态,但是,在services界面中,start service/stop servi ...

  7. BZOJ5343[Ctsc2018]混合果汁——主席树+二分答案

    题目链接: CTSC2018混合果汁 显然如果美味度高的合法那么美味度低的一定合法,因为美味度低的可选方案包含美味度高的可选方案. 那么我们二分一个美味度作为答案然后考虑如何验证? 选择时显然要贪心的 ...

  8. MT【230】一道代数不等式

    设$a,b,c>0,$满足$a+b+c\le abc$证明:$\dfrac{1}{\sqrt{1+a^2}}+\dfrac{1}{\sqrt{1+b^2}}+\dfrac{1}{\sqrt{1+ ...

  9. [树链剖分]hihocoder1883

    描述 有一个无向图,有n个点,m1条第一类边和m2条第二类边.第一类边有边权,第二类边无边权.请为第二类的每条边定义一个边权,使得第二类边可能全部出现在该无向图的最小生成树上,同时要求第二类边的边权总 ...

  10. 洛谷P4768 [NOI2018]归程(可持久化并查集,最短路)

    闲话 一个蒟蒻,在网络同步赛上进行了这样的表演-- T2组合计数不会,T3字符串数据结构不会,于是爆肝T1 一开始以为整个地图都有车,然后写了2h+的树套树,终于发现样例过不去 然后写可持久化并查集D ...