容错

更新时间:2022-08-25 16:09

容错,亦作“ 容厝 ”。亦作“ 容措 ”。指措置;安放。对于不同的领域有不同的意思,比如对计算机通信术语来说意思就是指当系统在运行时有错误被激活的情况下仍能保证不间断提供服务的方法和技术。

词语解释

犹措置;安放。

仲长统《昌言》:“ 孝宣之世,则以弘恭为中书令, 石显为仆射。 中宗严明,二竖不敢容错其奸心也。”《晋书·刘毅传》:“故天下之人退而修本,州党有德义,朝廷有公正,浮华邪佞,无所容厝。” 唐 韩愈上郑尚书相公启》:“伏蒙仁恩,猥赐示问,感戴战悚,若无所容措。”

相关概念

容错既是一种彩票专业术语又是计算机行业的专业术语。

容错是彩票软件运算中条件过滤保护机制的一种高级模式,在彩票专业术语里指用户选择了N个指标,并指定了其中允许出现错误的条件个数范围,在这种情况下的最终结果依然是正确的。

容错参数格式:A-B(其中A必须小于B,而且B一定不能大于用户选择的参与过滤的总条件个数。)

容错参数含义:前一个数字A代表错误的最小可能性,后面数字B代表错误的最大限度。只要错误的情况在这个范围之内,过滤后的结果中一定包含中奖号码。

例如:实战中一共选择了5个条件参与过滤,容错设置参数为0-2,那么前面的参数0表示这5个条件中错误的最小可能性为0,即没有错误发生;后面的参数2表示这5个条件里允许错误的最大限度为2个,即可能有1个条件或2个条件是错误的,但是不能超过2个,如果实际操作中的条件错误个数范围在0-2之间,那么过滤后的结果一定包括中奖号码。

再如:实战中一共选择了6个条件参与过滤,容错设置参数为1-3,那么前面的参数1表示这6个条件中错误的最小可能性为1,即最少会有1个条件是错误的,但是不知道是哪个条件错误;后面的参数3表示这6个条件错误的最大限度为3个,即可能有1个条件或2个条件或3个条件是错误的。如果实际操作中的条件错误个数范围在1-3之间,那么过滤后的结果中也一定包括中奖号码。

优势

1.对于彩票,即使选择的条件有意料中的错误,中奖号码也会在容错后的号码组里。

2.对于计算机,当系统出现数据、文件损坏或丢失时,使用容错技术能够自动将损坏或丢失的数据和文件恢复到事故发生前的状态,使系统能够保持连续正常的运行。

缺点

一、容错后过滤结果的号码注数随着容错参数设置的变化相应地增加了。

二、容错在计算机中指系统恢复文件的错误,存储在计算机中的文件或者在网络中传输的文件有可能因为故障或者干扰信号等的影响而发生错误或者丢失,此时一般情况下系统能够自动恢复文件,但是文件错误严重时候必须人为恢复或者文件彻底丢失。系统的恢复能力就是容错能力简称容错。

IT含义

定义

容错描述的是一个电脑系统或组件,它们被设计用来在组件发生故障时备用组件或程序能够立即代替它,这样就不会耽误它的服务。容错可以通过软件或嵌入硬件来提供,也可由一些组合来提供。

当执行软件时,操作系统提供一个界面,这个界面允许程序员在事务中预先确定的地点“检查站点”的关键数据。在执行硬件时(如Stratus 和它的VOS操作系统 ),程序员不需要知道机器的容错能力。

在硬件层上,容错通过转接各个硬件组件来实现。磁盘被镜像。多处理器以锁步(lock-stepped)的方式运行。当异常情况发生时,错误的组件被确定并从服务中删除,同时机器能继续正常运行。

重要性

在一些特殊应用场合,如航空航天、国防军事、核能电力、工业化工、卫生医疗急救等关键部门,一次计算机系统错误的发生就可能导致不可挽回的巨大损失,在这些关键系统的设计中必须采用大量的容错技术来保证运行中突发的计算机错误不会导致整个系统的失效。

容错方法

硬件错误的容错方法:

计算机硬件错误可分为永久性错误(permanent fault) 、瞬态错误(transient fault) 和间歇性错误 (intermittent fault)。永久性错误一般由硬件老化、电路短路等原因产生,一旦发生则原定功能失效,必须通过替换元器件来完成恢复;间歇性错误处于永久性错误和瞬态错误2种情况之间,表现为瞬态错误的发生频率超过系统可靠性允许阈值范围;瞬态错误在的硬件环境及未来元器件继续高度集成的发展趋势下正以几何级数的速度增长,其错误数在整个系统错误总数中占最大的比重,对整个系统的可靠性影响度也是最大的。

冗余的系统不一定是容错的,但容错的系统一定是存在冗余的。冗余方法在容错策略中被广泛用来探测、诊断并恢复系统运行时发生的错误。按冗余资源的形式不同可以将冗余方法分为硬件冗余、信息冗余、时间冗余、线程冗余等。

软件错误的容错方法:

分析一个计算机系统的可靠性,必须要考虑其软件的可靠性因素,但由于软件可靠性方面的研究比较困难,大大地落后于硬件方面的研究,还没有确定并且成熟的一套可供工程使用的方式和方法,所以在进行系统的可靠性预计时,往往忽视软件的失效率。人为的软件设计错误在软件整个生命周期中都一直存在,这一点已经得到证明。这种设计错误,在一定的输入激励下将产生一定的故障现象,客观上很难使用统一的模型对这种思维的结果进行数学的描述。例如,软件测试可以发现软件设计错误,通过修改软件的可靠性可以得到提高,但也有可能因为修改了已存在的错误带来了新的错误使得可靠性下降,所以软件可靠性在研究方面有很多地方不够成熟。这里主要介绍软件多样性方法,恢复块方法以及防卫式程序设计方法,除此之外提高软件容错能力亦可以从计算机平台环境、软件工程和构造异常处理模块等不同方面达到。此外,利用高级程序设计语言本身的容错能力,采取相应的策略,也是可行的办法,如C++语言中的try_except处理法、try_finally中止法等。

故障的恢复策略一般有2 种:前向恢复和后向恢复。所谓前向恢复是指使当前的计算继续下去,把系统恢复成连贯的正确状态,弥补当前状态的不连贯情况,所谓后向恢复是指系统恢复到前 一 个正确状态,继续执行。N-versionprogramming 方法属于前向恢复策略。

一般化容错方法:

虽然不同的应用背景对于可靠性的要求不同( 可靠性、成本、反应时间等诸多因素) 使得各种容错策略的设计迥异,研究者们还是在试图寻找各种容错设计的最大共同点和更具有一般性、广泛性的方法,目标是实现可靠性设计的非定制COTS(commercial off-the-shelf) 与可靠性的可裁剪,下面分别介绍两个从硬件和软件不同角度出发的以容错设计一般化为目标的例子。

Chameleon是一种容错软件设计的一种结构。根据可靠性需求可进行不同选择来动态地达到可靠性可裁剪的目的。整个软件体系都由对象ARMORs来组成,根据功能不同可以将ARMORs 分为三类: ( 1 ) 管理模块Managers :负责管理其他 ARMORs 对象根据用户可靠性要求完成容错策略的选择和组织;(2) 后台通信模块Daemons :允许 Chameleon 访问网络中其他节点,提供ARMOR 的错误探测并给出 ARMOR 之间通信的渠道。(3)普通ARMORs :根据应用的可靠性需求提供具体实施方法,比如指令重执、表决、检查点、心跳检测等具体解决方法。

整个Chameleon 软件结构类似于操作系统的结构组成,内核由执行硬件平台构成,外围是商业非定制的一般化操作系统( 例如 Linux 等 ) ,操作系统之上依次分别为可重构的ARMORs 框架以及具体 ARMORs 对象和管理执行层,最后是具体的应用层。

一般化硬件结构GUARDS基于所有组件 ( 包括硬件和软件)COTS 原则,给出了一种容错计算机系统设计的一般化体系结构,在最大程度保证容错策略普适性的同时最小化具体应用的功能特点,根据具体应用的可靠性不同可以对各个可配置层进行不同的配置方案,比如冗余信道、冗余链路的冗余度大小、输入输出数据整合层的数据核查方案的选择等。通过配置的改变,系统可以达到可靠性由低到高很大范围内的自由裁剪。

研究现状

尽管计算机系统容错研究已经取得了一些成果但仍然存在一些薄弱的研究点以及一些关键问题没有得到很好的解决,具体可以概括为以下几点:

(1) 关于硬件冗余容错方法研究,虽然可以根据系统结构从总体上使用概率统计方法分析系统的可靠性,但还缺乏广泛适用的有效方法实现对复杂冗余系统的有效建模、管理和精确量化分析,特别是在各部件可靠度不一致的情况下,建模分析的理论问题尚未解决。另外,硬件冗余实现成本大、功耗大、占用空间大等依然是需要解决的大难题。

(2) 对于信息冗余容错方法来说,绝大部分 ECC算法( 如前文提到的 RED-FEC Mechanism 、 ABFT [9] 、check-sum EDAC 等 ) 对于处理连续位出错的能力非常有限,而占系统总错误比例非常大的瞬态错误所导致的内存错误通常就是多个连续位出错的情况。这方面还需要继续研究发展。

(3) 对于时间冗余容错方法,除了由时间换空间而带来的较大的延迟外,此类方法还存在对永久性错误(permanenterror) 不敏感的问题。

(4) 对于并行多线程冗余容错方法,冗余线程之间的同步、通信等问题,线程之间的系统资源合理分配避免死锁问题等都还没有得到很好的解决,而且对于在单线程的处理器上引入真正的线程级机制实现容错人们研究较少。

(5) 在软件冗余方面,对于规模较小、数据处理过程较简单的小型软件很难体现N-version programming 软件多样性的优势,而另一方面,如果程序规模过大、过于复杂,一般来说N 版本软件的费用也会不菲。而且软件冗余技术的研究尤其滞后。

(6) 对于恢复块方法来说,用来判断程序是否安全运行的测试模块的无错运行假设是整个系统设计的前提,这个假设本身就存在一定的问题。

(7) 防卫式程序设计方法缺乏系统的理论依据,主要依靠程序员自身的经验是无法进行系统可靠性分析的。

免责声明
隐私政策
用户协议
目录 22
0{{catalogNumber[index]}}. {{item.title}}
{{item.title}}