容錯

容錯，亦作“ 容厝 ”。亦作“ 容措 ”。指措置；安放。對於不同的領域有不同的意思，比如對計算機通信術語來說意思就是指當系統在運行時有錯誤被激活的情況下仍能保證不間斷提供服務的方法和技術。

基本介紹

• 中文名：容錯
• 外文名：Fault Tolerance
• 拼音：róng cùo
• 注音：ㄖㄨㄙˊ ㄘㄨㄛˋ

詞語解釋

猶措置；安放。

漢 仲長統《昌言》：“ 孝宣之世，則以弘恭為中書令， 石顯為僕射。 中宗嚴明，二豎不敢容錯其奸心也。”《晉書·劉毅傳》：“故天下之人退而修本，州黨有德義，朝廷有公正，浮華邪佞，無所容厝。” 唐 韓愈《上鄭尚書相公啟》：“伏蒙仁恩，猥賜示問，感戴戰悚，若無所容措。”

相關概念

概述

容錯既是一種彩票專業術語又是計算機行業的專業術語。

容錯是彩票軟體運算中條件過濾保護機制的一種高級模式，在彩票專業術語裡指用戶選擇了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) 防衛式程式設計方法缺乏系統的理論依據，主要依靠程式設計師自身的經驗是無法進行系統可靠性分析的。