精华内容
下载资源
问答
  • 容错范围
    2021-07-10 07:08:11

    计算机是一个较为复杂的系统,为确保其运行稳定性和可靠性,应当在系统设计时,对容错技术进行合理运用。基于此点,文章从容错的常用方法分析入手,论述了容错技术在计算机系统中的具体应用。期望通过本文的研究能够对计算机系统性能的提升有所帮助。

    1容错的常用方法

    1.1冗余

    这是计算机系统容错最为基本的途径之一,通过冗余可以大幅度提升系统的容错性能。大体上可将冗余分为两类,一类是时间冗余,另一类是空间冗余。前者是指借助重复计算过程来实现系统容错;后者是指利用额外的资源来实现系统容错,按照使用的冗余资源,可将之细分为硬件冗余、软件冗余、信息冗余等等。

    1.2回滚恢复容错

    这是一种通过对计算状态进行周期性保存来达到容错目的的方法。计算机系统在运行的过程中,如果出现故障问题,通过回滚恢复,可以使应用程序回到之前保存的某个状态处,重新对程序进行执行。该容错方法是时间冗余与空间冗余的有机结合,最早出现在分布式系统当中,随着技术的逐步完善,其在并行计算领域中得到广泛应用。

    1.3TRM容错

    这是目前计算机系统中应用最为广泛的容错技术,一个基本的TRM系统由三个完全相同的模块和一个投票器组成,三个模块会同时对输入的数据进行接收,每个模块将生成的结果发送给投票器,并由投票器通过投票的方式进行表决,其输出的数据主要取决于三个输入中多数一方的结果。如果三个模块中的某一个发生故障,其它两个模块可以保持正常运行,并对故障模块的错误输出进行掩盖,这样一来,投票器的输出结果便可以保持正确。容错系统可靠运行的条件是至少有两个模块需要始终保持正常。

    1.4检查点技术

    这是一种通过保留与恢复来达到容错目的的方法,其基本的技术原理如下:定期将执行状态存储于稳定的介质当中,当系统发生故障后,可从该介质中对状态进行恢复。被保存的状态即检查点,含有检查点的磁盘为检查点文件。如果计算机系统中加入检查点技术,运行中发生故障时,那么系统则可从故障中快速恢复正常,由此可确保系统的稳定运行,减轻了相应的损失。在计算机系统中,检查点的类型有两种,一种是局部,也就是所谓的单进程,另一种是全局,即并行程序。通过相关协议的设计,检查点可实现程序的快速恢复。在实际应用中发现,检查点技术存在如下不足:很难对软错误进行检测、开销大、可扩展性差、容易出现存储失效的情况。为了解决上述问题,业内的专家学者经过不断研究,对检查点技术进行优化改进,开发出无盘和增量两种检查点技术,前者是通过对计算机系统的内存进行利用,达到减少记录检查点开销的目的;后者则是通过保存必须的程序来减少存储开销。

    2容错技术在计算机系统中的具体应用

    2.1容错的实现步骤

    在计算机系统中对容错技术进行应用的过程中,容错的具体实现步骤如下:

    2.1.1对系统故障问题进行自动检测

    由上文可知,计算机系统出现故障后,会导致错误,由此可能会引起失效。而部分失效会造成系统的逻辑故障。在对逻辑故障进行检测时,可以使用的方法较多,其中较具典型性和代表性的有奇偶校验、一致性校验等等。大体上可将故障检测分为两种类型,一类是脱机,另一类是联机。在脱机状态下,对系统故障问题进行检测时,计算机及相关设备无法正常执行任务,而在联机状态下对系统故障进行检测时,可确保任务与检测过程一并进行,这是联机检测的应用优势,具体可以利用冗余校验的方法进行联机检测(田丽娜,王海龙,计算机系统容错技术分析:科技展望,2016)。

    2.1.2故障限制与屏蔽

    通常情况下,计算机系统中的故障都会出现在某个部位,但由于系统本身是一个整体,所以局部故障可能会影响到其它的功能,为使故障的影响范围降至最低程度,需要对故障进行限制,这是容错技术在计算机系统中应用时较为重要的一个作用。通过故障限制,将故障的传播限定在一个特定的区域内,避免对其它的区域造成影响。故障屏蔽是掩盖失效的一种方法,从本质上讲,就是利用冗余解决错误信息,比较常见的故障屏蔽为多数表决。

    2.1.3重试与诊断

    计算机系统是一个较为复杂的系统,在对系统进行首次操作时,可能无法成功,但再次操作却可以成功。这种情况大多是因为瞬时故障引起,其通常不会造成物理破坏,所以只需要通过重试便可进行解决。容错技术中的诊断,则是在故障检测并未提供故障性质、发生位置等信息的情况下,对故障进行准确判断的做法。

    2.1.4重组与恢复

    当容错系统检测到计算机当中存在故障问题时,并判断该故障为永久性故障后,通过重组,可对失效的器件进行替代,并将其从系统中隔离出去。这一过程也可通过冗余系统来完成,由此可以使计算机系统的性能得到保障。经过重组之后,需要将计算机系统中的错误消除掉,此时系统会回到故障检测前的某个点上,并从该点重新开始操作。为确保系统在故障后能够快速恢复,既要有备份文件和检验点,还要有应用记录。

    2.1.5重启

    当计算机系统中出现的错误导致大量的信息被破坏,并且系统未设计恢复功能,这样系统无法通过自动恢复来消除错误的影响(刘娟,高可靠计算机系统的容错技术分析:计算机产品与流通,2018)。如果系统在出现错误时,并未遭到破坏,可以通过重新启动来恢复相关的操作。重启分为两种方式,一种是热重启,在这种重启方式下,不会对系统造成任何损失,另一种是冷启动,这种方式下,系统需要对相应的程序进行重新加载。

    2.1.6修复与重构

    通过诊断找到计算机系统中某个故障元件后,可用完好的元件进行替换,从而快速消除故障,使系统恢复正常运行。容错技术中的修复,既可以在脱机的状态下进行,也可在联机的情况下完成。当元件替换后,应当使修复的模块重新加入到系统当中,这个过程即为重构。

    2.2实现容错的方法

    计算机系统实现容错时,需要对如下技术方法进行运用:

    2.2.1自动检验

    当计算机系统中出现故障时,在恢复错误前,系统应当具备发现错误及其成因的能力,也就是说,容错离不开自动检验的支撑。所谓的自动检验是一种快速检测系统故障的方法,可以通过自动检验装置来实现。系统容错设计时,通过自动检验的运用,可使系统对错误进行及时处理(仇宇婕,计算机控制系统可靠性技术分析:山东工业技术,2018)。

    2.2.2自动备份

    通过自动备份,可以使容错系统及时对丢失或是损坏的数据进行恢复,从而保证计算机系统在遭受无法抵御的破坏时,重要数据信息不会丢失。

    2.2.3事务跟踪

    在计算机系统容错设计中,事务跟踪主要针对的是用户软件和数据库的运行而设计的,其能够确保系统损坏时,数据信息的一致性。

    3结论

    总而言之,计算机系统在人们日常工作、生活中的使用越来越广泛,保证系统的运行可靠性尤为重要。为实现这一目标,应当对容错技术进行合理运用。鉴于此,在未来一段时期,应加大对容错技术的研究力度,除对现有的技术和方法进行优化改进与完善之外,还应加快开发一些新的容错技术,从而使其能够更好地为计算机系统服务。

    作者:雷利香 单位:枣庄科技职业学院

    更多相关内容
  • 在数组中查找近似给定值的元素,使其在指定的容错范围内,是一项常见任务。 这个非常简单的脚本会自动执行此任务,并按误差从最小到最大的顺序输出相关的元素索引,从而轻松地仅选择 n 个最接近的匹配项。 可以指定...
  • STC单片机UART通信波特率误差容忍范围研究.pdf
  • 针对一类执行器故障不确定离散重复过程, 提出一种有限频率范围的迭代学习容错控制算法. 通过定义故障系数矩阵和输出跟踪系统的等价二维模型, 沿故障系统的时间轴和批次轴设计迭代学习被动容错控制器, 以线性矩阵...
  • 重构电路,根据目标变化调整容错控制器,保证系统容错控制在一定范围内。依据轴承振动造成内环、外环、滚柱故障频率分析结果,对故障进行检测与诊断,获取故障信息,保证控制器结构不变,采用故障补偿技术实现故障...
  • 当系统在某些传感器或执行器故障的条件下,设计一鲁棒容错控制器,利用线性矩阵不等式方法分析了与区域极点指标相容的H∞指标和方差上界指标的取值范围,建立了容错控制中,类指标的相容性理论,并在相容指标约束下给出了...
  • 纳米电子交叉开关架构上的容错逻辑映射的覆盖范围优化
  • 基于延迟范围的混合迭代学习多阶段批处理的容错保证成本控制
  • 移动无线传感器网络中基于容错的基于行的屏障覆盖范围的形成
  • 因此,它提供的功能范围与 Fabric 中的功能有些相似。 但是,它是专门用于身份系统的,而 Fabric 是通用的。Indy Plenum 技术概览有关最新的文档和演练,请参阅我们的文档站点 。 请在系统找到系统的一般概览。 ...
  • 为了改善传统视频编码器在无线网络传输条件下的容错性能,并减轻由于丢帧引起的...通过H.263编解码器的试验证明: 所提出的算法可以很好地缩短由无线传输丢包引起的误差传播范围,从而得到比较好的视频主客观评价效果。
  • 为了能在一个很宽的存储和传输媒介范围内对活动图象进行访问,MPEG- 4具有很强的容错能力。较详细地介绍了MPEG-4标准中提供的容错工具。
  • 包括比如 Checkpoint 地址、Job Manager、Dispatcher、Resource Manager 等等,这些信息的容错是由 Kubernetes/Zookeeper 等系统的高可用性来保障的,不在我们讨论的容错范围内。Flink 作业运行起来以后,会从数据源...

    ▼ 关注「Apache Flink」,获取更多技术干货 ▼

    摘要本文整理自 Apache Flink 引擎架构师、阿里巴巴存储引擎团队负责人梅源在 Flink Forward Asia 2021 核心技术专场的演讲。本次演讲内容围绕 Flink 的高可用性探讨 Flink 新一代流计算的核心问题和技术选型,包括:

    1. Flink 高可用流计算的关键路径

    2. 容错 (Fault Tolerance) 2.0 及关键问题

    3. 数据恢复过程

    4. 稳定快速高效的 Checkpointing

    5. 云原生下容错和弹性扩缩容

    Tips:点击「阅读原文」查看原文视频 & 演讲PDF~

    一、高可用流计算的关键路径


    51a81fe7e2b36c7aff4dcbfad8787cb7.png

    上图的双向轴线是大数据应用随时间延迟的图谱,越往右边时间延迟要求越短,越往左延迟要求没那么高。Flink 诞生之初大概是在上图中间,可以理解为往右对应的是流式计算,而往左边对应的是批式计算。过去一两年,Flink 的应用图谱向左边有了很大的扩展,也就是我们常说的流批一体;与此同时我们也从来没有停止过把图谱向更实时的方向推进。

    Flink 是以流式计算起家,那么向更实时的方向推进到底是指什么?什么是更实时更极致的流式计算?

    在正常处理的情况下,Flink 引擎框架本身除了定期去做 Checkpoint 的快照,几乎没有其他额外的开销,而且 Checkpoint 快照很大一部分是异步的,所以正常处理下 Flink 是非常高效的,端到端的延迟在 100 毫秒左右。正因为要支持高效的处理,Flink 在做容错恢复和 Rescale 的时候代价都会比较大:需要把整个作业停掉,然后从过去的快照检查点整体恢复,这个过程大概需要几秒钟,在作业状态比较大的情况下会达到分钟级。如果需要预热或启动其他服务进程,时间就更长了。

    所以,Flink 极致流计算的关键点在容错恢复部分。这里说的极致的流计算是指对延迟性、稳定性和一致性都有一定要求的场景,比如风控安全。这也是 Fault Tolerance 2.0 要解决的问题。

    二、容错 (Fault Tolerance) 2.0

    及关键问题


    d64953beb48f88d4b5785c09782ddfd6.png

    容错恢复是一个全链路的问题,包括 failure detect、job cancel、新的资源申请调度、状态恢复和重建等。同时,如果想从已有的状态恢复,就必须在正常处理过程中做 Checkpoint,并且将它做得足够轻量化才不会影响正常处理。

    容错也是多维度的问题,不同的用户、不同的场景对容错都有不同需求,主要包括以下几个方面:

    • 数据一致性 (Data Consistency),有些应用比如在线机器学习是可以容忍部分数据丢失;

    • 延迟 (Latency),某些场景对端到端的延迟要求没那么高,所以可以将正常处理和容错恢复的时候要做的工作综合平均一下;

    • 恢复时的行为表现 (Recovery Behavior),比如大屏或者报表实时更新的场景下,可能并不需要迅速全量恢复,更重要的在于迅速恢复第一条数据;

    • 代价 (Cost),用户根据自己的需求,愿意为容错付出的代价也不一样。综上,我们需要从不同的角度去考虑这个问题。

    另外,容错也不仅仅是 Flink 引擎侧的问题。Flink 和云原生的结合是 Flink 未来的重要方向,我们对于云原生的依赖方式也决定了容错的设计和走向。我们期望通过非常简单的弱依赖来利用云原生带来的便利,比如 across region durability,最终能够将有状态的 Flink 的应用像原生的无状态应用一样弹性部署。

    基于以上考虑,我们在 Flink 容错 2.0 工作也有不同的侧重点和方向。

    第一,从调度的角度来考虑,每次错误恢复的时候,不会把和全局快照相对应的所有 task 节点都回滚,而是只恢复失败的单个或者部分节点,这个对需要预热或单个节点初始化时间很长的场景是很有必要的,比如在线机器学习场景。与此相关的一些工作比如 Approximate Task-local Recovery 已在 VVP 上线;Exactly-once Task-local Recovery,我们也已经取得了一些成果。

    接下来重点聊一下 Checkpoint 以及和云原生相关的部分。

    三、Flink 中的数据恢复过程


    那么,容错到底解决了什么?在我看来其本质是解决数据恢复的问题。

    104c15c39ae19d97d6672bc26a7437fa.png

    Flink 的数据可以粗略分为以下三类,第一种是元信息,相当于一个 Flink 作业运行起来所需要的最小信息集合,包括比如 Checkpoint 地址、Job Manager、Dispatcher、Resource Manager 等等,这些信息的容错是由 Kubernetes/Zookeeper 等系统的高可用性来保障的,不在我们讨论的容错范围内。Flink 作业运行起来以后,会从数据源读取数据写到 Sink 里,中间流过的数据称为处理的中间数据 Inflight Data (第二类)。对于有状态的算子比如聚合算子,处理完输入数据会产生算子状态数据 (第三类)。

    Flink 会周期性地对所有算子的状态数据做快照,上传到持久稳定的海量存储中 (Durable Bulk Store),这个过程就是做 Checkpoint。Flink 作业发生错误时,会回滚到过去的一个快照检查点 Checkpoint 恢复。

    我们当前有非常多的工作是针对提升 Checkpointing 效率来做的,因为在实际工作中,引擎层大部分 Oncall 或工单问题基本上都与 Checkpoint 相关,各种原因会造成 Checkpointing 超时。

    下面简单回顾一下 Checkpointing 的流程,对这部分内容比较熟悉的同学可以直接跳过。Checkpointing 的流程分为以下几步:

    2fc874b29a6703fb806d111fc1d3d053.png

    第一步:Checkpoint Coordinate 从 Source 端插入 Checkpoint Barrier (上图黄色的竖条)。

    bd91ac4c5002b7e0376cabae6a9f39e3.png

    第二步:Barrier 会随着中间数据处理向下游流动,流过算子的时候,系统会给算子的当前状态做一个同步快照,并将这个快照数据异步上传到远端存储。这样一来,Barrier 之前所有的输入数据对算子的影响都已反映在算子的状态中了。如果算子状态很大,会影响完成 Checkpointing 的时间。

    451c13a3fd3352d320251a8ee526bf76.png

    第三步:当一个算子有多个输入的时候,需要算子拿到所有输入的 Barrier 之后才能开始做快照,也就是上图蓝色框的部分。可以看到,如果在对齐过程中有反压,造成中间处理数据流动缓慢,没有反压的那些线路也会被堵住,Checkpoint 会做得很慢,甚至做不出来。

    ba64420d1fdd231aa1c2211912a4ca32.png

    第四步:所有算子的中间状态数据都成功上传到远端稳定存储之后, 一个完整的 Checkpoint 才算真正完成。

    从这 4 个步骤中可以看到,影响快速稳定地做 Checkpoint 的因素主要有 2 个,一个是处理的中间数据流动缓慢,另一个是算子状态数据过大,造成上传缓慢,下面来讲一讲如何来解决这两个因素。

    四、稳定快速高效的 Checkpointing


    1011291431e52c735e1f103b30daf66d.png

    针对中间数据流动缓慢,可以:

    1. 想办法不被中间数据堵塞:Unaligned Checkpoint——直接跳过阻塞的中间数据;

    2. 或者让中间的数据变得足够少:Buffer Debloating。

    3. 针对状态数据过大,我们需要将每次做 Checkpoint 时上传的数据状态变得足够小:Generalized Log-Based Incremental Checkpoint。

    下面来具体展开阐述每一种解决方法。

    4.1 Unaligned Checkpoint

    1cdd8bef969bd8d689ab80ecce304b42.png

    Unaligned Checkpoint 的原理是将从 Source 插入的 Barrier 跳过中间数据瞬时推到 Sink,跳过的数据一起放在快照里。所以对于 Unaligned Checkpoint 来说,它的状态数据不仅包括算子的状态数据,还包括处理的中间数据,可以理解成给整个 Flink Pipeline 做了一个完整的瞬时快照,如上图黄色框所示。虽然 Unaligned Checkpoint 可以非常快速地做 Checkpoint,但它需要存储额外的 Pipeline Channel 的中间数据,所以需要存储的状态会更大。Unaligned Checkpoint 在去年 Flink-1.11 版本就已经发布,Flink-1.12 和 1.13 版本支持 Unaligned Checkpoint 的 Rescaling 和动态由 Aligned Checkpoint 到 Unaligned Checkpoint 的切换。

    4.2 Buffer Debloating

    Buffer Debloating 的原理是在不影响吞吐和延迟的前提下,缩减上下游缓存的数据。经过观察,我们发现算子并不需要很大的 input/output buffer。缓存太多数据除了让作业在数据流动缓慢时把整个 pipeline 填满,让作业内存超用 OOM 以外,没有太大的帮助。

    22228b87eb7b86871ef841a427138628.png

    这里可以做个简单的估算,对于每个 task,无论是输出还是输入,我们总的 buffer 数目大概是每个 channel 对应的 exclusive buffer 数乘以 channel 的个数再加上公用的 floating buffer 数。这个 buffer 总数再乘以每个 buffer 的 size,得到的结果就是总的 local buffer pool 的 size。然后我们可以把系统默认值代进去算一下,就会发现并发稍微大一点再多几次数据 shuffle,整个作业中间的流动数据很容易就会达到几个 Gigabytes。

    实际中我们并不需要缓存这么多数据,只需要足够量的数据保证算子不空转即可,这正是 Buffer Debloating 做的事情。Buffer Debloating 能够动态调整上下游总 buffer 的大小,在不影响性能的情况下最小化作业所需的 buffer size。目前的策略是上游会动态缓存下游大概一秒钟能够处理的数据。此外,Buffer Debloating 对 Unaligned Checkpoint 也是有好处的。因为 Buffer Debloating 减少了中间流动的数据,所以 Unaligned Checkpoint 在做快照的时候,需要额外存储的中间数据也会变少。

    6a25bf5c63c9118bb83340b744cda804.png

    上图是对 Buffer Debloating 在反压的情况下,Checkpointing 时间随 Debloat Target 变化的时间对比图。Debloat Target 是指上游缓存 “预期时间” 内下游能处理的数据。这个实验中,Flink 作业共有 5 个 Network Exchange,所以总共 Checkpointing 所需的时间大约等于 5 倍的 Debloat Target,这与实验结果也基本一致。

    4.3 Generalized Log-Based Incremental Checkpoint

    前面提到状态大小也会影响完成 Checkpointing 的时间,这是因为 Flink 的 Checkpointing 过程由两个部分组成:同步的快照和异步上传。同步的过程通常很快,把内存中的状态数据刷到磁盘上就可以了。但是异步上传状态数据的部分和上传的数据量有关,因此我们引入了 Generalized Log-Based Incremental Checkpoint 来控制每次快照时需要上传的数据量。

    191696c74d189a06277f00be9751638a.png

    对于有状态的算子,它的内部状态发生改变后,这个更新会记录在 State Table 里,如上图所示。当 Checkpointing 发生的时候,以 RocksDB 为例,这个 State Table 会被刷到磁盘上,磁盘文件再异步上传到远端存储。根据 Checkpoint 的模式,上传的部分可以是完整的 Checkpoint 或 Checkpoint 增量部分。但无论是哪种模式,它上传文件的大小都是与 State Backend 存储实现强绑定的。例如 RocksDB 虽然也支持增量 Checkpoint,但是一旦触发多层 Compaction,就会生成很多新的文件,而这种情况下增量的部分甚至会比一个完整的 Checkpoint 更大,所以上传时间依然不可控。

    23c24e4e20920fada33e761934745933.png

    既然是上传过程导致 Checkpointing 超时,那么把上传过程从 Checkpointing 过程中剥离开来就能解决问题。这其实就是 Generalized Log-Based Incremental Checkpoint 想要做的事情:本质上就是将 Checkpointing 过程和 State Backend 存储 Compaction 完全剥离开。

    具体实现方法如下:对于一个有状态的算子,我们除了将状态更新记录在 State Table 里面,还会再写一份增量到 State Changelog,并将它们都异步的刷到远端存储上。这样,Checkpoint 变成由两个部分组成,第一个部分是当前已经物化存在远端存储上的 State Table,第二个部分是还没有物化的增量部分。因此真正做 Checkpoint 的时候,需要上传的数据量就会变得少且稳定,不仅可以把 Checkpoint 做得更稳定,还可以做得更高频。可以极大缩短端到端的延迟。特别对于 Exactly Once Sink,因为需要完成完整的 Checkpoint 以后才能完成二阶段提交。

    五、云原生下容错和弹性扩缩容


    在云原生的大背景下,快速扩缩容是 Flink 的一大挑战,特别是 Flink-1.13 版本引入了 Re-active Scaling 模式后,Flink 作业需要频繁做 Scaling-In/Out,因此 Rescaling 已成为 Re-active 的主要瓶颈。Rescaling 和容错 (Failover) 要解决的问题在很大程度上是类似的:例如拿掉一台机器后,系统需要快速感知到,需要重新调度并且重新恢复状态等。当然也有不同点,Failover 的时候只需要恢复状态,将状态拉回到算子上即可;但 Rescaling 的时候,因为拓扑会导致并行度发生变化,需要重新分配状态。

    5d7755908cb75cb4648116d54b378914.png

    状态恢复的时候,我们首先需要将状态数据从远端存储读取到本地,然后根据读取的数据重新分配状态。如上图所示,整个这个过程在状态稍大的情况下,单个并发都会超过 30 分钟。并且在实际中,我们发现状态重新分配所需要的时间远远大于从远端存储读取状态数据的时间。

    e8d03b15f22386ffd361bc9d3a02e338.png

    那么状态是如何重新分配的呢?Flink 的状态用 Key Group 作为最小单位来切分,可以理解成把状态的 Key Space 映射到一个从 0 开始的正整数集,这个正整数集就是 Key Group Range。这个 Key Group Range 和算子的所允许的最大并发度相关。如上图所示,当我们把算子并发度从 3 变成 4 的时候,重新分配的 Task1 的状态是分别由原先的两个 Task 状态的一部分拼接而成的,并且这个拼接状态是连续且没有交集的,所以我们可以利用这一特性做一些优化。

    516d8f80142b0c9191eea3b1b7a672ab.png

    上图可以看到优化后,DB Rebuild 这部分优化效果还是非常明显的,但目前这部分工作还处于探索性阶段,有很多问题尚未解决,所以暂时还没有明确的社区计划。

    最后简单回顾一下本文的内容。我们首先讨论了为什么要做容错,因为容错是 Flink 流计算的关键路径;然后分析了影响容错的因素,容错是一个全链路的问题,包括 Failure Detection、Job Canceling、新的资源申请调度、状态恢复和重建等,需要从多个维度去权衡思考这个问题;当前我们的重点主要是放在如何稳定快速做 Checkpoint 的部分,因为现在很多实际的问题都和做 Checkpoint 相关;最后我们讨论了如何将容错放在云原生的大背景下与弹性扩缩容相结合的一些探索性工作。

    往期精选

    ceb67f4142ea30933ed4d051197a07a7.png

    eb0860f035232be0508cac84847bc2c2.png

    3ab816a18946966aede080d15a743bea.png

    0c70954fbf6356f33889ea89b70fc6e2.png

    更多 Flink 相关技术问题,可扫码加入社区钉钉交流群~

    6725ea5ed33f6a639e71e6ea3c4e9419.png

     e2653a2fd3ca84c118db24c355b1d75a.gif  戳我,查看原文视频&演讲PDF~

    展开全文
  • 压缩容错网络编码

    2021-03-17 03:33:06
    由于许多信号在时域上是相关的,因此本文提出了一种压缩容错网络编码方案,以探索信号的时间相关性。 该方案通过将压缩感知理论注入网络编码中,克服了网络编码理论的弊端,即该方案具有良好的压缩增益。 同时,当...
  • 该设计在继承变结构控制的优点的同时,显式地引入推力器输出的饱和幅值,以确保控制输出在其要求界的范围内.同时,充分利用星上推力器的硬件冗余以实现对部分推力器故障的容错,这种思想的引入使得所设计的控制器对故障...
  • 为了在出现硬件或软件的暂时或永久故障的情况下,保证关键任务仍能在规定的时限范围内完成运算,并输出正确的结果,提出一种双处理器实时嵌入式容错系统体系结构。该系统结构采用多处理器体系结构,实现计算机之间的...
  • 微服务之容错

    2021-12-02 22:17:34
    今天先谈谈容错。 微服务的容错 在微服务架构中,整个系统被拆分为多个独立部署的服务单元。各个服务模块通过rpc调用来完成整个系统的服务功能。那么,对于单一服务而言,不可避免的要面对这个问题:RPC调用失败了...

    前言

    微服务虽然带来了很多好处,但是引入的麻烦也不小。例如:分布式事务,分布式JOB,分布式SESSION等等。今天定个小目标,争取每周学习其中一个小题目。今天先谈谈容错。

    微服务的容错

    在微服务架构中,整个系统被拆分为多个独立部署的服务单元。各个服务模块通过rpc调用来完成整个系统的服务功能。那么,对于单一服务而言,不可避免的要面对这个问题:RPC调用失败了怎么办?而导致这个问题的原因可能有:

    1. 数据问题,导致下游系统失败了。
    2. 网络出现抖动,导致断线了。
    3. 发生网络分区了。
    4. 下游系统挂了。
      如果说,第一种情况,我们属于业务系统的问题。那么,我们应当如何应对后面三种情况呢?如果有同学说,这个事情发生的概率太低了,问题不大。那么一旦发生,后果将会非常严重,整个系统服务不可用!感兴趣的同学,可以自行了解一下,灾难级杀手:服务雪崩。为此,我们必须考虑服务容错。

    容错手段

    在RPC调用中,最简单且有效的容错手段就是超时。超时后的处理,也是对当前调用的一种降级。但是,如果服务提供者挂了,至少在重启之前,调用都会失败。因此,这时候就上断路器。在RPC调用满足一定程度的错误阈值(例如:在一段时间内发生错误的调用的占比)后,直接停止调用,直接降级处理。而在服务层面,为了保证负载在服务的承受范围内,采取限流措施。当然,也可以通过提高系统的承受能力,从而可以处理更多的请求。例如:引入缓存。

    限流

    我们每个服务器的处理能力都是存在极限的。只要网络并发请求超过了服务的处理极限,那么必然会把服务压垮。因此,限流是确保服务的负载在可承受可处理范围的一个重要手段。

    限流算法

    计算器算法

    这是最简单的限流算法,也叫固定时间窗口算法。要理解这个算法,首先得明白,什么是固定时间窗口。例如,假定时间窗口长度为1分钟,那么从此刻开始,[now, now + 1)即为当前计数的时间窗口区间。在这个时间范围内的每一次请求,计数器都会+1,当达到设定的最大请求数阈值时,拒绝请求。只有等到下一个时间窗口,重置请求计数器后,才能继续请求。
    在这里插入图片描述
    优点:简单粗暴、通俗易懂。
    缺点:存在瞬时流量峰值问题。
    例如,一个5秒时间窗口,在第5秒时来了100个请求(假设限流阈值为100request/5s),被限流了。但是在第6秒时,重置了请求计数,这是又来了50个请求,被放行了。超出了系统100request/5s的能力。

    滑动时间窗口算法

    针对计数器算法的缺点进行改进。既然一个时间窗口存在统计精度问题,那就多分几个小的时间窗口。同时,每次统计,向前滑动一个小时间串口(后面称格子)。从而实现在整个大的时间窗口内的请求数量不会超过阈值。下图例子为:时间窗口为5s,分5个小格子进行统计,即:每个小格子为1s。每次向前滑动一个小格子,即向前滑动一秒。
    在这里插入图片描述

    优点:相比于计数器算法,解决了临界突发问题。
    缺点:无法解决瞬时流量整个时间窗口范围内均会被限流,可能造成系统能力浪费(突刺现象)。例如:以上述为例,在第5秒瞬间100个请求打满。那么在接下来的5秒内均无法再有请求进来,而可能到第4秒的时候,已经全部处理完了。

    漏桶算法

    为了应对突刺现象,对请求流量进行整型,于是漏桶算法出现了。漏桶算法能够让流量以一个稳定速度流向后端服务。
    在这里插入图片描述

    核心思想是,参照漏桶,让请求像漏桶漏水的流速一样,平滑的请求后端服务。一个比较容易理解的例子:消息队列。消息队列的容量就是水桶的容量,消息生产者就是水龙头,进水速度总是不固定。消息的消费者就是漏桶的漏洞,总是以固定速率消费消息。再举个例子,在通讯时,双方约定,只能以固定的速率向对方发送数据。因此请求方增加了一个缓存。应用漏桶的概念就是,缓存就是漏桶的大小。所有的需要发送的数据都往缓存中放,而另外有一个线程,专门以固定的速率向对方发送数据。
    由此可见,通常漏桶算法都是异步的。

    特点:

    1. 强制将请求以一个固定的速率流出。
    2. 削峰填谷,禁止突发。

    令牌桶算法

    先看下原理:
    在这里插入图片描述
    核心思路:

    1. 固定速率往桶中放令牌。如果桶已满,则丢弃。
    2. 每个请求进来,都需要从桶中取令牌,成功则可以执行,否则拒绝执行。

    举个例子,某服务器并发能力是10QPS,对应的令牌桶容量为10个令牌。假定处理能力是5个请求每秒,那么不妨设计令牌产生的速度为5个每秒。初始时,桶中有10个令牌,假设有10个并发,那么此时就会把桶中的令牌全部取走。下一个请求进来,得看具体的实现怎么处理了,RateLimiter的默认方法acquire是由是等待新的令牌产生,然后返回。这意味着至少需要等待1/5秒新的令牌产生才能继续获取到令牌。而tryAquire则不会等待,直接拒绝。而Sentinel也是直接拒绝的。

    特点:

    1. 限制平均流速,允许一定程度的突发。(可以瞬时取到多个令牌,发出请求,只限制平均流速。)

    应用:

    • 预热
      系统刚启动的时候,由于各种原因(缓存还没准备好、JVM热点代码未编译等等)处理能力还没有达到稳定状态,因此需要先预热。通过平滑的改变令牌产生的速度,逐步让系统达到稳定的水平。Sentinel预热的源码分析

    限流的维度

    1. 限制总并发数
      如:线程池。弊端:线程切换开销 + 可能存在线程切换后的可能存在上下文丢失(ThreadLocal参数)。好处,通过线程隔离来保护原线程。
    2. 限制时间窗口内的平均速率-QPS。
      上面提到的限流算法,都属于这个范畴。

    后记

    可算是写完了,从去年写到今年。。花了很多时间来理解这个令牌桶跟漏桶算法。刚刚家人问,你还在看漏桶啊?才恍然发现。。但好在总算是理解了。二者的区别还是很大的。也明白了。
    为什么说令牌桶才能允许突发?
    因为令牌桶只要桶中有足够的令牌,可以同时允许多个请求流出。而漏桶,不管多少个请求进来,哪怕就是你进入到了漏桶中,最终还是只能等待调度,而调度总是以固定的速率流出的。
    参考了很多sentinel官方的材料,下次好好聊聊sentinel。

    参考

    https://www.cnblogs.com/xuwc/p/9123078.html
    https://github.com/alibaba/Sentinel/wiki/%E4%B8%BB%E9%A1%B5
    https://github.com/alibaba/Sentinel/wiki/%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6
    https://github.com/alibaba/Sentinel/wiki/Guideline:-%E4%BB%8E-Hystrix-%E8%BF%81%E7%A7%BB%E5%88%B0-Sentinel
    https://github.com/alibaba/Sentinel/wiki/Sentinel-%E4%B8%8E-Hystrix-%E7%9A%84%E5%AF%B9%E6%AF%94

    展开全文
  • 微服务架构服务容错设计分析

    多人点赞 热门讨论 2021-07-13 00:03:07
    在微服务体系架构中,由于...微服务容错机制正是这样一种稳定性解决方案,可以理解微微服务架构的保险丝,通过它可以对业务平台形成一种有效的保护机制。在发生平台异常时候,容错机制是平台稳定运行的最后一道屏障。

    公众号:慕枫技术笔记

    真正的大师永远怀着一颗学徒的心

    在这里插入图片描述

    引言

    在微服务体系架构中,由于拆解的服务数变多了,服务发生故障的地方也会相应的增加,因此如何保证服务架构健壮是一个值得深思的问题。微服务容错机制正是这样一种稳定性解决方案,可以理解微微服务架构的保险丝,通过它可以对业务平台形成一种有效的保护机制。在发生平台异常时候,容错机制是平台稳定运行的最后一道屏障。


    微服务架构为什么需要容错机制

    说起来可能有一些年头了,以前小时候家里面经常出现电压不稳电灯忽明忽暗,有时候甚至出现短路停电的情况。每次一片漆黑的时候,大人们最常说的一句话就是:哎,估计又是保险丝断了哦。这里的保险丝就是保护家中电路电器的一种手段,当发生短路情况时,通过熔断保险丝来保护家中电器不受电流过载的影响。

    在微服务架构体系中的熔断降级正是起到保险丝作用的基础组件。我们在进行架构设计时,不仅需要满足业务要求,同时也需要面向失败进行设计,意思就是说当外部条件发生变化或者内部出现异常时,平台的架构能够将这种异常的影响降到最低,强大的容错能力是优秀架构的关键指标。

    回到今天的主题容错机制,我们可以反过来想,如果没有如果没有熔断降级系统容错机制,整个系统平台在异常情况下,会发生怎样的系统反应,我们先看下以下几种场景。

    场景一:服务节点异常影响上游服务调用方

    假设我们有客户端服务,需要分别调用Service1集群的接口、Service2集群的接口以及Service3集群的接口来完成一项业务流程,如果Service3集群发生异常情况,服务都还在,但是可能由于出现fullGC、慢查询、业务异常等情况,客户端在调用Service3集群时出现timeout,不能在规定时间内进行服务响应。当调用请求不断发出时,此时Client中的工作线程将会被这些调用的time out阻塞住,当业务不断进行请求时,Client对应的工作线程会越来越多的被阻塞住,进而导致客户端不可用。
    在这里插入图片描述
    当此客户端不可用时,可能上层调用方也会由Client的不可用向上影响,导致上层调用方也出现异常,就像病毒一样一层一层的传导,异常影响被不断向上放大,最终导致整个平台不可用。在这里插入图片描述

    场景二:流量激增导致服务不可用,影响其他依赖该服务的服务异常

    我们假设Service1集群可以承载6000QPS的流量,正常情况下上游三个服务的流量总和都小于这个阈值。但是当流量发生激增时,其中一个服务的QPS就超过了10000QPS,超出了Service1集群的服务能力,因此造成了集群的异常出现响应异常的情况,此时Service2集群以及Service3集群由于依赖Service1集群的服务,同样会出现线程阻塞的情况,最终导致整个平台的异常。
    在这里插入图片描述
    因此基于以上分析,微服务架构中引入熔断降级组件是为了提升微服务架构整体的容错能力。主要避免以下三种场景对平台稳定性的影响。

    1、单个服务集群节点出现异常故障,其影响范围可能被无限向上游服务放大;
    2、由于使用了共同基础服务,基础服务出现异常时,多租户相互影响;
    3、某个服务的瞬时流量突增,某个服务集群扛不住,影响整个平台稳定性;

    如何破局

    资源隔离

    我们以现实生活中的船舱为例,实际的船舱格局大致如下所示,船舱底部并不是完全的一整个空心结构,而是通过格子进行区域隔离。为什么这么设计呢?主要还是为了一旦发生船舱漏水,只影响其中一个隔离区域,而不是整个船舱都灌满水,从而达到一定程度保护船体不会因为一处漏洞而沉没的目的。

    那么借助于船舱隔离的思想,在我们的程序世界中,我们是不是也可以采用资源隔离的方式来保护我们的微服务架构呢?答案是肯定的,也的确是这么做的。
    在这里插入图片描述

    1、线程池隔离

    我们可以通过线程池隔离的方式来实现资源的隔离,不同的请求使用相应的线程池来处理,即便出现请求资源time out的情况,最多影响当前线程池的资源,而不会影响整个服务的线程资源。类似船舱中的隔离区域。
    在这里插入图片描述

    2、信号量隔离

    信号量主要是用来控制线程数的,规定好一些调用最大的并发量,超过指定的信号量后,可以将请求丢弃或者延时处理,防止线程的不断增长导致的服务异常。
    在这里插入图片描述

    熔断

    所谓熔断,正如上文所说,它的作用就是想保险丝一样,在流量过大或者请求错误率过大的情况下,此时保险丝就熔断了,对应的业务链路断开,不再提供服务。当流量恢复正常或者错误降低后,熔断开关再进行闭合,之前的业务链路重新恢复。这是一种很好的保护后端微服务的一种方式。
    在大促期间,平台需要用足够的机器去保证核心商业链路正常运转,对于退款、退货这种服务,则可以通过暂时熔断的方式不对外提供服务,当大促过了之后再进行恢复。

    在这里插入图片描述

    在熔断机制中,核心的内容就是断路器的设计,断路器设计主要有两方面一个是状态转换的设计,一个是如何根据阈值以统计数据来执行核心的断路功能。

    降级

    和熔断的场景有点蕾丝,当系统流量过多时,系统资源有限,平台处理不过来那么多的请求。此时就可以可将不是那么重要的功能模块进行降级处理,停止对外服务,这样可以释放出更多的资源供给核心功能的去用。如下所示,商品详情页中,商品服务中方商品列表才是最重要的服务,至于用户的积分以及用户的头像此时并不是核心业务,所以在系统能力有限的情况下,优先让商品服务对外提供服务,其他服务进行降级处理。
    在这里插入图片描述

    总结

    本文主要对微服务架构中的容错机制进行了分析,从为什么要有容错机制到如何通过资源隔离、熔断以及降级等方式实现微服务容错保护进行了阐述。下一篇文章将带大家看看熔断降级组件Hystrix的工作原理,敬请期待哦。


    我是慕枫,感谢各位小伙伴点赞、收藏和评论,文章持续跟新,我们下期再见!

    微信搜索:慕枫技术笔记,优质文章持续更新,我们有学习打卡的群可以拉你进,一起努力冲击大厂,另外有很多学习以及面试的材料提供给大家。

    在这里插入图片描述

    展开全文
  • 容错机制总结

    2022-03-01 20:14:37
    经过查阅资料,原来这些专有名词都有一个统一的名字:容错机制。终于,借此机会对常见的容错机制进行一下总结,方便以后学习。 文章中若有本人理解或描述不当之处,欢迎老铁们指出~ fail-fast - 快速故障 在系统...
  • 通俗来说,容错率就是指允许错误出现的范围和概率。放到个人身上,可以视作一种包容度,一个人对“错误”、“不完美”、“未达成目标”、“缺点”等负面事物的包容度。 容错率低的人,会对错误、缺点等非常在意。...
  • 针对RFID故障频率较高而导致RFID阅读器定位准确性较低的问题,首先对RFID阅读器的故障类型进行了分析,然后基于线性二阶锥形规划,提出了一种可以处理长时间大范围故障的RFID阅读器定位算法,并提出了一种质量指数...
  • 在云存储平台下, 提出了一种基于访问统计的自适应容错机制SFMAF, 该机制...实验结果表明, SFMAF相对于副本冗余机制, 在CPU和内存使用率可接受范围内的增加上, 减少了系统内部数据的传输流量, 即减少了系统存储空间。
  • V神的99%容错共识算法详解

    千次阅读 2018-08-22 14:37:44
    最近V神发了一篇博客,提出了一种能99%容错的共识算法,引发了大家的广泛思考。原文地址: https://vitalik.ca/general/2018/08/07/99_fault_tolerant.html 众所周知,在同步网络中,容错率可以达到50%(这...
  • 在基于PMSM的高性能矢量控制伺服调速系统中,需耍实时精确地知道电机转子的旋转位置和速度信息,这些信息的获取最多的是通过安装在电机上的位置...因此,对于伺服调速系统中PMSM位置传感器故障容错控制研宄就应用而生。
  • 拜占庭容错最终一致算法 这项研究由资助,并根据他们的要求开源。...我们使用来生成大范围的网络行为并确保我们的正确性属性成立。 要运行测试网,请运行: # install rust + cargo (see https://rustup.rs/) QUICKC
  • 数据和计算系统如何容错

    千次阅读 2021-12-13 16:02:56
    容错是大规模数据系统和计算系统的必备功能,不能容错的分布式系统基本没有可用性。大家可能觉得高质量的系统错误率没有那么高,实质上系统的故障率总是随着系统规模和复杂程度增加。笔者读书的时候曾经听过一位参与...
  • 原标题:容错服务器——边缘计算,带你和未来见个面 未来,已来!在物联网技术革命性发展的当下,工业自动化产业依然面临一次从量变到质变式的机遇,那就是“边缘计算”。容错带你和未来见个面。容错服务器及容错软件...
  • 在连续型执行器故障的模式下,利用线性矩阵不等式技术,给出了2个指标约束下容错性能的相容性判别条件,分析了与区域极点指标相容的H∞指标的取值范围,并在相容指标约束下给出了满意容错控制器的设计方法。...
  • 关于一个人的颜值,我们通常都是用高和低来区分好看还是不好看,不过最近又出了一个新的词哦,那就是“低容错颜值”,这是说颜值高还是不高呢?下面八宝网小编带来:低容错颜值表示什么意思低容错颜值什么梗。低容错...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 68,945
精华内容 27,578
关键字:

容错范围