分佈式系統設計之容錯機制

前言

由於分佈式系統是由多個分佈在不同網絡節點的子系統或者稱爲子服務組成,在處理客 戶端請求時,服務之間需要通過網絡來進行相互調用,所以如果某個服務由於宕機或者其他 原因導致不可用,則服務調用方需要採取一定的容錯機制來避免該不可用服務影響了當前服 務的請求處理。
在這裏插入圖片描述
即一個服務可能會通過 RPC 調用多個其他服務,如果其中某個服務不可用, 則需要保證另外的多個服務的處理結果,以及當前發起 RPC 服務調用的服務的處理結果都 可以正常返回給客戶端,只是這個不可用服務的處理結果需要返回錯誤而已。

分佈式系統可以根據自身業務特點來選定容錯機制,對服務調用失敗採取不同的處理方 式和產生不同的處理結果,具體的容錯機制可以分爲如下六種。

FailOver:失敗自動切換

失敗自動切換機制是指當調用該服務集羣的某個節點失敗時,自動切換到該服務集羣的 另外一個節點並進行重試,其中切換機制類似於負載均衡機制,不過一般採用輪詢方式。這 種容錯機制通常適用於讀操作,所以可以請求從該服務集羣的多個節點的任意一個節點獲取 數據。由於需要切換到服務集羣的另外一個節點進行服務重試,所以整個請求處理流程的時 間延遲會加大。

FailFast:快速失敗

快速失敗機制是指當進行服務調用失敗時,直接返回錯誤,而不會進行重試或者切換到 服務集羣的另外一個節點進行調用,即要麼成功,要麼失敗,只發起一次服務調用請求。

這種機制通常適用於非冪等的操作,因爲服務調用失敗的原因包括:服務節點機器宕機 導致服務不可用;服務可用,但是兩個服務節點之間的網絡出現延遲或者被調用的服務節點 繁忙,處理請求緩慢,導致返回結果超時。所以當服務調用失敗時,可能確實沒有進行操作, 也可能是進行了操作,但是返回響應結果超時或者丟失,而該操作又是非冪等的,故不能進 行重複操作,否則會導致數據不一致性。

FailSafe:失敗安全

失敗安全機制跟快速失敗機制類似,都是隻發起一次服務調用,要麼成功,要麼失敗, 不會進行重試操作。不過與快速失敗不同的是,失敗安全機制在調用失敗時會進行日誌記錄。 所以可以通過對日誌進行監控和分析來及時瞭解服務調用情況,及早發現和處理服務調用失 敗的情況,以及對於重要服務的調用可以通過日誌的數據來進行補償。

FailBack:失敗自動恢復

失敗自動恢復機制在服務調用失敗時,跟失敗安全機制類似也會進行服務調用的記錄, 不過在記錄的基礎上,增加了自動定時重發的邏輯,適用於異步、冪等性的請求調用或者消 息系統中允許消息重複的場景。

Forking:並行調用多個服務節點

並行機制通常用於實時性要求較高的讀操作的場景,其基本工作過程爲並行調用服務集 羣的所有節點,由於是讀操作,故所有服務節點返回的數據都是相同的,所以只要有一個服 務節點返回調用成功則返回響應給客戶端。

這種機制相對於 FailOver 失敗自動切換機制,由於是對所有服務節點發起並行調用,而 不是在調用失敗時才一個個輪詢切換直到調用成功,所以延遲較小,實時性較高,不過機器 的系統資源開銷較大,所以如果需要進行這種調用,則需要保證機器性能較高。

BroadCast:廣播調用

廣播調用與並行調用類似,也是需要對服務集羣的每個節點都發起一次調用,不過不同 的是,廣播調用通常用於服務集羣的每個節點都維護了本地狀態,然後需要對這種本地狀態 進行寫操作的場景,即需要同步寫操作給服務集羣的每個節點,從而保證每個節點的數據一 致性和可靠性。

總結

以上介紹了 6 種分佈式系統中場景的容錯機制,其中前 4 種容錯機制是針對服務調用失 敗的場景,而後面兩種容錯機制,即 Forking 和 Broadcast 更多的是對數據實時性和數據可 靠性方面的考慮和容錯的實現。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章