您可參考右側導航欄瞭解博文涉及內容。

一、故障，錯誤，BUG的區別

在瞭解一個系統的可用性可以從瞭解系統故障開始。但是什麼是故障，錯誤，bug？

故障與錯誤是經常容易被混淆的兩個概念,故障、錯誤、BUG之間是有區別的。

• 軟體程式碼由於人為因素寫錯了或者考慮不周全,成為了錯誤。
• 有錯誤的軟體存在一定缺陷,該缺陷在某種情況下可以轉化為故障。
• 產生了故障,人們就認為系統出 BUG了。

錯誤是最原始的驅動力,一個錯誤不一定導致故障,因此錯誤不見得被人們察覺。但是,一旦錯誤變為故障,人們是可以通過軟體的外在表現而察覺。故障是系統出錯後導致系統不正常工作的結果,故障從某種意義上來說屬於現象。即通過故障這種現象,人們可以知道軟體存在BUG,最終找到相關錯誤點,並對錯誤程式碼進行修復。BUG 是被激發出來的錯誤,是故障的總稱，因此一個系統實際存在的錯誤數比BUG 數要多,因為只有被激發出來的錯誤才能成為BUG。

那麼如果要設計一個可靠性非常高的系統，或者系統中的一個可用性非常高的模組或者子系統該怎麼設計呢？圍繞以下以下幾個問題

• 如何檢測故障：系統出現故障時，可以通過系統故障的外在可見性瞭解到系統出現BUG，也就是檢測系統的是否處於故障狀態；
• 故障發生會有什麼情況：系統故障發生後，會對系統產生什麼樣的影響。怎麼讓故障被系統管理員所知道；
• 如何應對故障：系統故障後，能夠自動化地改變策略，故障處理，維持系統的可用性。

二、故障檢測

要提升系統的可用性，就要先檢驗系統是否處於故障狀態。

1、ping與echo戰術

ping與echo戰術是錯誤檢測的常用方法。這裡的ping可以對應著window或者linux的ping命令理解，檢查網路是否連通，可以很好地幫助我們分析和判定網路故障。在錯誤檢測中，使用ping和echo就是外部模組，向需要的模組傳送請求即ping訊息，然後被檢測的模組返回相應的狀態資訊echo資訊。通過資訊瞭解到被檢測的模組狀態。如果被監測方在預期的時間內無法返回相應的訊息，則在進行幾次ping訊息傳送（能儘量避免因網路問題誤判的情況），如果仍無法返回資訊，即可確認為出錯。

ping和echo示意圖

monitor向monitored元件傳送ping命令，然後monitored返回echo資訊（或無法返回，直接認定monitored端所在的系統錯誤），monitor根據echo資訊判斷monitored的系統是否正常執行。monitor與monitored不僅可以在不同系統，也可以屬於同一系統的不同模組。

2、Heartbeat戰術

在使用ping和echo作為錯誤檢測戰術的系統中，總是由需要兩端即客戶端傳送ping，服務端傳送echo傳送訊息保障系統錯誤檢測的正常執行，那麼能否一端傳送資訊呢？那就是心跳戰術Heartbeats。
Heartbeat的發起者是被檢測者自身，定期傳送Heartbeat訊息向外界表示其本身正在處於正常執行的狀態。由於資訊的傳送是每隔一段時間傳送一次，類似人的心跳，所以被稱為心跳戰術。

Heartbeat示意圖

需要注意的是：Timer的作用是記錄訊息是否超時，所以在每一次接受Heartbeat訊息之後，都需要立即停止一個定時器的工作，同時開啟新的計時器。如果Timer超過規定時間，則進行診斷。

右側Monitored向左側Monitor傳送心跳資訊，如果左端Timer即使測發現訊息超時，甚至無法收到訊息則判定Monitored端故障。僅僅使用Heartbeat很可能會造成誤判，也就是heartbeat因為某種傳輸原因，沒能到達Monitor端，那麼Monitor就直接認定被檢測的系統是故障的嗎？顯然不合適，所以使用ping和heartbeat組合。

補充：除了ping和heartbeat常用的故障檢測還有在多數語言中都存在的異常捕獲——異常處理機制，異常出錯後，會上報資訊，那麼異常處理程式會根據具體的出錯資訊對其進行相應的處理，一般同屬於一個程序或一個執行緒。
常見如Python：

try:
    語句
except：
    出錯處理

3、ping與heartbeat組合使用

Heartbeat與Ping經常配合使用能提升錯誤檢測的效果。 在正常情況下,通過Heartbeat 訊息監測系統的狀態,當 Heartbeat 訊息消失後,可利用 Ping訊息做二次確認,若Ping訊息也沒有得到反饋,此時可判定相關模組出現故障。

HeartBeat與ping的混合使用示意圖

圖中增加了相應的 Ping和Echo 的支援模組,這此模Heartbeat 訊息超時時被呼叫,即當計時器超時,左側模組將傳送 Ping 訊息,同時啟動新的計時器等待 Echo 的到來。若在超時前接收到了 Echo訊息,則說明右側模組並沒有失效,反之則判斷右側模組失效。

流程圖：
Heartbeat傳送端流程圖

Heartbeat接收端流程圖（監控端）

由於系統可能是分散式的，或者監控和被監控的系統分屬於不同的系統，所以在流程圖中，可以看到在訊息的傳送端，還需要獲取相應的IP地址和埠號。

三、如何處理網路對訊息的影響

無論是ping還是heartbeat戰術都無法避免一個問題：如何確認echo或者heartbeat訊息是因為真正的系統故障還是因為網路傳輸過程中失效。即如何避免誤判系統故障或者降低誤判的機率。
如果被檢測的系統沒有故障，而在向監測端傳送訊息的時候，由於網路故障問題，監測端沒有接受到資訊，那麼監測端誤認為系統故障，就會採取相應的故障處理策略，這種處理本來是沒有必要的，是消耗資源的。
網路存在著一定的延時或其他問題,並不是所有的 Heartbeat訊息都能準時、週期性的到達,實際系統不能簡單地以一個Heartbeat 訊息超時或未到達為依據做出系統失效的判斷。因此可以採取兩種 Heartbeat 訊息的判定方法。

1、設定超時時間和最大超時次數

第一種判定方法。設定一個超時時間 TIME OUT 與最大超時次數 MAX TIME OUT,建議MAX_TIME OUT=3.
判定系失效方法:

• 在傳送訊息之後的3次超時計數過程中,只要接收到迴應,就判定系統未失效。
• 如果在傳送訊息之後的3次超時計數過程中監聽元件都沒有收到迴應,判定系統失效。

2、超時訊息重傳

第二種判定方法參考TCP 的超時重傳機制,讓監聽元件具有傳送ACK訊息的功能,ACK 訊息帶有序號,監聽元件傳送ACK訊息之後,響應元件接收到 ACK 訊息後才發回 Heartbeat消 息,Heartbeat 訊息也帶有序號,且應與對應的 ACK 訊息的序號相同。另外設定一個超時時間TIME OUT和一個最大無響應次數 MAX NO RESPONSE,建議 MAX NO RESPONSE=3.

判定系統未失效方法:

• 連續3次傳送ACK訊息之後至少有1次得到相同序號的 Heartbeat訊息響應,判定系統未失效。

判定系統失效方法:

• 連續3 次傳送 ACK 訊息之後在 TIME OUT 時間內無相同序號的 Heartbeat訊息響應,判定系統失效。

** 注**：這裡並不能完全解決系統故障誤判的問題，只是利用現有手段最大程度解決這一問題。

四、系統設計

解決了網路對訊息傳輸的作用對系統故障的影響，那麼如何使用Heartbeat與ping結合設計一個主備份的系統呢?更進一步即確認故障之後如何處理呢？

下面給出主從備份系統的示意圖

備份復件需要檢測主復件的狀態資訊,所以主復件問備份復件定時傳送 Heartbeat 訊息用於告知備份復件相關狀態資訊。備份復件在收到每個Heartbeat 訊息之後,啟動新的計時器,若計時器超時仍未收到下一個 Heartbeat 訊息,則備份附件進人確認階段。備份復件傳送 Ping 訊息,並且啟動新的計時器,若在新的計時器超時仍未收到明主復件故障,然後備份復件代替主復件接管所有工作,所有的客戶主復件的 Echo 資訊,則付與原來的備件復件進行通訊,此時 需要通知管理人員主備切換的訊息,便於管理人員設定新的備件,以保障未來的正常切換。

因此以上分析知道，在確認被檢測系統出錯之後，為保證系統的持續可用性（這也是本博重點討論的問題），接下來的處理是找到備份系統接管當前系統或模組的所有工作，並自動化通知相關管理人員做進一步操作。
具體實現可以使用主動冗餘這一錯誤恢復戰術。

五、主動冗餘

1、原理

主動冗餘中所有冗餘元件在啟動的時候同步,以並行的方式對時間作出響應,因而它們都處 在相同的狀態。通常,作出響應的第一個元件的結果被採用,其他響應被丟棄。 元件間的同步是通過將傳遞給被冗餘元件的全部訊息傳送給所有冗餘元件。發生錯誤時,使用該戰術的系統停機時間通常是幾毫秒。恢復時間就是元件間的切換時間,因為冗餘元件間狀態一致,各元件接收到的都是最新的訊息,並且擁有之前的所有狀態。此處的冗餘元件一般是指模組,但實際還可能包括通訊鏈路。 在可用性要求非常高的分散式系統中,如通訊核心網,冗餘組 件包括通訊路徑。這一極度契合了為高可用系統設計的要求。

2、代價

主動冗餘是一種高可靠性的設計，由原理可知，冗餘中所有元件都處於並行執行狀態下，所以一般應用對系統可靠性要求非常高的情況,且其工作代價也比較高。
從硬體成本上來看,需要雙份系統的硬體要求,從軟體上看,需要一套高效的心跳監測和倒換機制,以及狀態同步的機制。

3、示意圖

B與B'同時接收C的請求並且進行同樣的操作， 但是,只有B向A傳送處理完的結果。相當於B'的處理結果在平常狀態下將被丟棄。此時， 若B出現故障,則B'將直接接替B的工作。由於B'的執行狀況與B幾乎一致,B'可快速接替B的工作。B和B'的這種工作模式就是一種主動冗餘的方式。

因此可以看出：主動冗餘的優點是切換時間非常短，資料和計算都是熱備份的。所以一旦系統出現錯誤，就可以立刻切換，基本不會影響系統的正常執行。但缺點也十分明顯，所有的冗餘模組都處於啟用狀態，並指向相同的任務，即使在主系統沒有故障的情況下仍需要對請求做同樣的處理，從而保障所有模組的執行結果一致性。就造成了資源的成倍增加。

4、比較

主動冗餘，和被動冗餘和備份是不同的存在，被動冗餘不像主動冗餘一樣一直進行計算，實現也更簡單，因而也對系統的可用性保證更低。而備份則是更為低級別的錯誤恢復方式。

• 實現容易程度：備份>被動冗餘>主動冗餘
• 資源消耗程度：主動冗餘>被動冗餘>備份
• 可用性保證程度：主動冗餘>被動冗餘>備份

具體怎麼選擇策略還需要具體情況具體分析。