石頭自清潔掃拖機器人G10S評測：多年黑科技集大成之作 懶人終極福音
科技圈經常能看到一個詞叫“縫合怪”，用來形容那些把好多功能或者外觀結合在一起的產品，通常這樣的詞是貶義詞，但如果真的是產品縫合的好、縫合的實用的話，那它就成了中性詞，今
我們所謂系統發生故障是指當它無法再按照規格要求向用戶提供服務時。這種故障是由故障所引發的，即內部組件或系統所依賴的外部組件發生故障。有一些故障是可以被容忍的，對用戶沒有明顯的影響，而另一些則會導致系統故障。
為了構建具備容錯能力的應用程序，首先需要了解可能出現哪些問題。在接下來的內容中，我們將探討一些最常見的故障根本原因。到最后，您可能會思考如何應對各種不同類型的故障。
在計算機系統中，任何物理組件都可能發生故障。硬盤驅動器、內存模塊、電源供應器、主板、固態硬盤、網絡接口卡以及中央處理器等，均可能因各種原因停止正常運作。有時，硬件故障甚至可能導致數據損壞。更甚者，整個數據中心可能會因電力中斷或自然災害而發生故障。不過，正如我們將在后文討論的那樣，通過引入冗余措施，許多這些基礎設施故障是可以應對的。雖然你可能認為這些硬件故障是導致分布式應用程序失敗的主要原因，但實際上，它們往往因為一些非常普通的原因而出現問題。
在最近對五個流行的分布式數據存儲系統進行的用戶報告研究中，發現了多數災難性故障的根本原因是對非致命錯誤處理的不當。在大多數情況下，這些錯誤處理中的問題本可以通過簡單的測試來檢測出來。例如，有些錯誤處理程序完全忽略了錯誤。其他則捕捉了過于通用的異常，比如Java中的Exception，然后出于毫無充分理由的原因終止整個進程。還有一些錯誤處理程序只實施了部分功能，甚至包含了"FIXME"和"TODO"這樣的注釋。回過頭來看，這或許并不太令人意外，因為錯誤處理往往被視為次要問題。這也是Go語言如此重視錯誤處理的原因。在后續，我們將更加深入地探討測試大型分布式應用程序的最佳實踐。
配置更改是導致災難性故障的主要根本原因之一。問題不僅僅在于錯誤的配置可能會引發問題，還有一種情況是對于啟用了很少被使用的功能的有效配置更改不再按預期工作，或者從來沒有按預期工作。配置更改之所以特別危險，是因為它們的影響可能會拖延。如果一個應用程序僅在真正需要配置值的時候才讀取它們，那么無效的配置更改可能會在幾小時甚至幾天后才顯現出問題，從而無法及早被發現。因此，配置更改應該像代碼更改一樣受到版本控制，經過測試，并在變更時采取預防性驗證措施。在持續部署的背景下，我們將探討代碼和配置更改的安全發布實踐。
單點故障（SPOF）是指當某個組件故障時，整個系統都會崩潰的情況。實際上，系統可能存在多個單點故障。
通常情況下，人員往往成為關鍵的單點故障（SPOF），如果將他們置于可能獨立引發災難性故障的位置，幾乎可以確定他們最終會引發這種故障。例如，人類故障經常發生在某人需要按照特定順序手動執行一系列操作步驟而不能犯任何錯誤的情況下。相比之下，計算機在執行指令方面表現出色，因此自動化應盡可能得到充分利用。
另一個常見的SPOF是DNS。如果客戶端無法解析應用程序的域名，它們將無法連接到該應用程序。造成這種情況的原因多種多樣，從域名到期到整個根級域名崩潰都有可能。
類似地，應用程序用于其HTTP端點的TLS證書也是一個SPOF。如果證書過期，客戶端將無法與應用程序建立安全連接。
理想情況下，在系統設計階段就應該識別這些SPOF。檢測它們的最佳方法是審查每個系統組件，然后詢問如果其中任何一個出現故障會發生什么。有些SPOF可以通過引入冗余來解決，而其他一些則無法。在這種情況下，唯一的選擇就是減小SPOF的影響范圍，也就是在它們發生故障時對系統造成的損害。我們將在后續討論的許多彈性模式都旨在減小故障的影響范圍。
當客戶端向服務器發送請求時，期望在不久后收到響應。在最佳情況下，請求后很快就會收到響應。如果出現了不同尋常的情況，客戶端有兩種選擇：要么繼續等待，要么因為超時異常或錯誤而取消請求。慢速的網絡調用是分布式系統的潛在隱患，因為客戶端無法確定響應是否最終會到達，因此它可能會長時間等待，或者干脆不取消請求，從而導致性能下降，而這種問題很難調試。這種故障也被稱為"灰色故障"，它非常微妙，很難迅速或準確地檢測到。由于其特性，灰色故障可能會輕松使整個系統崩潰。
當引入故障檢測和超時的概念時，會有很多原因導致未能獲得及時響應。舉例而言，服務器可能因在處理請求時速度極慢或崩潰而未能及時響應；或者可能是網絡丟失了少量數據包，從而引發大量的重傳和延遲。
慢速網絡調用 是分布式系統的潛在殺手。由于客戶端不清楚響應是否最終會抵達，因此它可能花費大量時間等待，甚至可能不會放棄，這將導致性能下降，而問題難以調試。這種故障也被稱為 灰色故障，這是一種如此微妙以至于不能迅速或準確檢測到的故障。由于其特性，灰色故障很容易將整個系統帶入崩潰的邊緣。
從觀察者的角度來看，一個非常慢的進程與根本不運行的進程幾乎沒有什么不同，兩者都無法執行有用的工作。資源泄漏是導致進程變慢的最常見原因之一。
內存可能是受泄漏影響最廣泛的資源之一。內存泄漏會導致內存消耗逐漸增加。即使是帶有垃圾回收功能的編程語言也容易受到泄漏的影響：如果對不再需要的對象保留了引用，垃圾回收器將無法刪除它。當泄漏消耗了大量內存以至于剩下很少時，操作系統將開始積極將內存頁面交換到磁盤。此外，垃圾回收器將更頻繁地啟動，試圖釋放內存。所有這些都會消耗CPU周期并使進程變得更慢。最終，當物理內存不再可用，且交換文件空間耗盡時，進程將無法分配內存，導致大多數操作失敗。
內存只是眾多可能泄漏的資源之一。以線程池為例：如果從線程池獲取的線程進行同步阻塞的HTTP調用而沒有設置超時，并且該調用從未返回，線程將不會返回到線程池。由于線程池具有有限的最大大小，如果持續喪失線程，最終線程將耗盡。
或許你認為在前述情況下，采用異步調用而不是同步調用會有所幫助。然而，現代HTTP客戶端使用套接字池以避免重復創建TCP連接并支付性能代價。如果請求未設置超時，連接將永遠不會返回到池中。由于池的最大大小是有限的，最終將不再有可用的連接。
此外，你的代碼并不是唯一訪問內存、線程和套接字的代碼。你的應用程序所依賴的庫也會使用相同的資源，它們可能會遇到我們剛剛討論的相同問題。
每個系統都有其負載容量，也就是它可以承受的負載極限。因此，當導向系統的負載持續增加時，它遲早會觸及到這個極限。
然而，有機會的負載增長為系統提供了逐漸擴展和增加容量的時間，這是一種情況；而突然和意外的洪水是另一種情況。
例如，考慮應用程序在一段時間內收到的請求數量。傳入請求的速率和類型可能會隨時間變化，有時甚至會因各種原因突然改變：
或許你認為，如果一個系統有數百個進程，那么如果其中一小部分進程變得緩慢或無法訪問，這應該不會有太大的影響。
故障的問題在于它們具有蔓延傳播的潛力，會從一個進程傳播到另一個進程，直到整個系統崩潰。這種情況發生在系統組件相互依賴的情況下，其中一個組件的故障會增加其他組件故障的概率。
通常需要采取足夠大的糾正措施來打破這個循環，比如暫時阻止流量到首次復制品。不幸的是，一旦這些故障開始，它們非常難以減輕，而預防故障從一個組件傳播到另一個組件是最佳方法。
本文鏈接：http://www.tebozhan.com/showinfo-26-14015-0.html分布式系統的挑戰：八個關鍵故障的解讀
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號