沒有理由在分散式系統中反對冗餘 (馬克)

banq發表於2021-04-16
分散式

從根本上說，分散式系統比單機系統具有更高的可用性是一個根本原因：冗餘。執行系統所需的軟體，狀態和其他內容在多個地方存在。當其中一個地方發生故障時，其他地方可以接管。這適用於複製的資料庫，負載平衡的無狀態系統，無伺服器系統以及幾乎所有其他常見的分散式模式。
冗餘的一個問題是它增加了複雜性，這可能會降低可用性。冗餘可能意味著多臺計算機，多個機架，多個資料中心甚至多個洲。這可能意味著軟體故障，其中諸如金絲雀部署之類的通用技術可以在一個軟體版本出現故障時幫助系統實現冗餘。
當我們談論系統設計時，我們往往會忘記冗餘的這些多重定義，而只關注基礎架構。為了說明冗餘為什麼如此重要，讓我們研究一個例子。
事件日誌理應是構建大型系統的一種流行方法。在這類系統中，有一個有序日誌，所有更改（寫操作）都會流經該日誌，然後將更改應用於掛起該日誌的某些系統。可以是讀取的資料副本，工作流系統可以對更改執行操作，等等。在此模式的簡單版本中，一件事是正確的：日誌中的每個主機和每個使用者都以相同的順序看到相同的更改。
該體系結構的一個優勢是，它可以為基礎結構故障提供大量冗餘。通用事件日誌系統（例如Kafka）可以輕鬆處理單個主機的故障。克服單個副本的故障也很容易，因為該體系結構使保持多個副本同步非常容易。
現在，考慮一下日誌中發生的事件之一是毒丸的情況。這只是意味著消費者不知道如何處理它。也許它說是非法的（“我不能減少這個無符號0！”），或者是沒有道理的（“ X列中的資料是什麼？我從未聽說過X列！”）。也許它說的只有在軟體的未來版本或過去的版本中才有意義。當面對毒藥時，複製基本上有兩種選擇：忽略它或停止。
忽略它可能導致資料丟失，而停止複製則會導致寫操作不可用。沒有人贏。這裡的問題是缺乏冗餘：在相同的狀態下執行相同的（確定性）軟體每次都將具有相同的不良結果。
此問題不僅適用於事件日誌體系結構。眾所周知，複製的狀態機也遇到相同的問題。主/備份複製也是如此。這不是一個體繫結構的問題，而是總體上分散式系統設計的問題。
在設計系統時，值得提出以下問題：您從冗餘中得到了什麼，以及哪些故障可以保護您免受損害。


 

相關文章