您可參考右側導航欄了解博文涉及內容。
一、故障，錯誤，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、比較
主動冗余，和被動冗余和備份是不同的存在，被動冗余不像主動冗余一樣一直進行計算，實現也更簡單，因而也對系統的可用性保證更低。而備份則是更為低級別的錯誤恢復方式。
- 實現容易程度：備份>被動冗余>主動冗余
- 資源消耗程度：主動冗余>被動冗余>備份
- 可用性保證程度：主動冗余>被動冗余>備份
具體怎么選擇策略還需要具體情況具體分析。