快速失敗是讓失敗立即快速發生! - pathelland

banq發表於2020-11-20

隨著我們逐漸利用雲端計算,這變得越來越具有挑戰性。由於各個元件都面臨著被稱為“灰色失敗”的新挑戰,因此我們建立強大解決方案的方法仍然面臨壓力 。在出現灰色故障時,伺服器或網路的一部分不會快速失敗,而是開始緩慢執行。慢跑比快跑更糟。慢速元件有時以低於正常速度1%的速度執行,可能很健康,可以說“我還在這裡!” 但速度慢到足以阻塞所有工作。這使快速故障方案容易受到攻擊。
 

雲端計算環境增加了亞穩定性
14世紀哲學家讓·伯裡丹(Jean Buridan)命名的悖論叫做“伯裡丹的屁股” 。Buridan的《屁股》強調了確定性概念固有的明顯矛盾,或者認為每個事件都源於先前事件。矛盾的是,一個非常餓的驢正好放在兩捆乾草之間的中間位置。假設驢將去最近的資源,它將餓死。
在電子學中,有一種稱為METASTABILITY的現象。這意味著系統可能會在無限制的時間內處於不穩定狀態。為了使有效訊號作為電路的輸出,它必須位於一定的電壓或電流水平之內。如果輸出降落在中間的灰色區域,則下一個電路會發生混亂的情況。它也可以做奇怪的事情。
這種亞穩定性是非同步電路固有的。由於您不知道輸入訊號的時序,因此在某些時候,各種輸入會同時到達,並且電路無法在兩捆乾草之間做出決定。
步數字系統通常在輸入訊號上新增仲裁器,以確保對訊號進行排序,從而避免亞穩態。當在同步裝置的時鐘域內工作時,時鐘用於確保提供給邏輯電路的輸入的時序,並且避免了亞穩性問題。當同步電路接收輸入的非同步訊號時,特殊的同步器將使亞穩性的可能性逐漸消失,但仍然是可能的。
如果我們將分散式系統轉移到複雜的雲端計算環境中,則我們的分散式系統設計會帶來很多新問題。在虛擬機器中執行伺服器可為您提供大量有價值的計算,而且價格合理。但是,它可以根據自己的時間範圍進行操作。嘈雜的鄰居問題是指您的虛擬機器與同一個物理伺服器上的其他虛擬機器競爭資源時,其容量有所變化。多核伺服器增加了樂趣,因為它們的協調可能會或可能不會阻止您希望傳送的訊息。透過雲網路基礎架構進行的旅行可能會遇到擁塞,導致通訊模仿美國郵局。這使得基於計時器的故障快速機率成為可能。
以前,當我們將分散式系統與非常可預測的伺服器和網路組成時,您會想到一個很好的主意,即您的佇列可以多快完成健康檢查。使用該期望,您可以快速刪除有病的節點,而僅很少刪除健康的節點。這是一個機率遊戲,您做出正確決定的機率極高。這很像在時鐘域內工作的電路,以避免亞穩態行為。 
伺服器和/或往返於它們的訊息並非總是以可預測的速度工作。它與刪除同步電路中的時鐘非常相似,因此它是一個非同步數字系統。我們可以抑制和消除亞穩定性的可能性已經大大降低。  
更糟糕的是,我們的大多數系統都依賴於資料中心中的其他系統。HDFS取決於Zookeeper 。Zookeeper和其他服務取決於DNS 。這些系統中的每一個都有超時和重試。這可能會導致級聯的延遲,超時和故障。這是亞穩態的另一種形式,可以加重問題而不是減輕問題。
當這種亞穩定性干擾分散式系統中的主要系統或領導者時,您將無法快速訪問我們許多系統所需的“完美真理”或線性化能力。可用性可能會受到很大影響。
 

分散式演算法:“相當好”勝於完美
現在,讓我們將注意力轉移到那些不能給出最新理想答案的演算法上(banq注:CAP定理的高一致性與可用性)。當對使用者的請求基於包含過期狀態的複製節點群時,任何一個節點就足夠了。
我們看到了類似的新興容忍演算法,用於日誌記錄。Apache Bookkeeper [3]是一個開放原始碼日誌記錄子系統,在該子系統中,無需向包含日誌副本的所有日誌伺服器傳送將新記錄追加到日誌的寫操作。到達所需的子集就足夠了。
同樣,AWS Aurora [1],[2]在集中式伺服器中執行資料庫,但將其更新傳送到儲存伺服器池。由於並非所有儲存伺服器都需要及時響應,因此Bookkeeper和Aurora所採用的方法可顯著提高伺服器延遲的彈性。單個副本可以活在自己的時間扭曲中,而我們更廣泛的分散式演算法則可以輕鬆進行。
 

您是否遇到過穩定的分散式演算法?
在超現實世界上執行時,我們的某些演算法確實是穩定的。但是,有些不是。如果繼續朝著亞穩態叢集發展的趨勢,則依賴於固定的響應伺服器集合來傳達高度一致的線性化資料的任何演算法都將越來越面臨挑戰(CAP定理)。
哪些演算法可以為我們提供清晰明瞭的線性化更新以及99.9%的時間快速延遲?大約有99.999%的時間?當環境壓力很大時,這些反應如何?  
我們如何才能從對亞穩性敏感的演算法發展到一個可以容忍和抑制大多數亞穩性的世界?
 

相關文章