撤消仲裁系統中的部分寫入

Question

假設一個仲裁系統有 5 個節點，寫入和讀取的仲裁數為 3。現在，假設客戶端發送一個寫入請求 w，並且 w 被復制到 2/5 個節點上。 由於我們沒有在至少 3/5 個節點上進行復制，我們告訴客戶端寫入不成功。 現在，緊接着，2 個未復制寫入的節點 go 關閉。 因此，在剩余的 3 個節點中，2 個有部分寫入，1 個沒有。 在這種情況下，系統如何確定部分寫入 w 需要撤消，因為它實際上並沒有成功完成？

Answer 1

在大多數系統中，3/5 表示該值已被選擇且不得撤消。

不同的協議和系統以不同的方式處理這個問題。

在ABD中，下一次讀取將從一個節點學習該值並將其傳播到其他兩個剩余節點。

同樣，在Paxos中，下一個提議者將從該節點學習值並將其傳播到其他兩個節點。 在基於 Paxos 的實際系統中，會有一個系統（可能是 Leader）會產生一個no-op提議，以確保及時傳播該值。

在像Raft這樣的領導者選舉/主副本系統中，領導者將確保傳播到副本。 那當然是除非它是死者之一。 在這種情況下，選舉過程通常要求新領導者是最新的，在這種情況下，這將包括有爭議的值。

Answer 2

這是您在構建分布式系統以檢查如何管理未發送到所有需要的節點的故障或事件時需要考慮的常見場景。

領導者有責任確保在事件被視為已提交之前將事件成功發送到定義的最小法定人數[應該有一個帶有該事件 ID 哈希碼的標志]，並且該事件不符合重試條件。

當請求從分布式系統中獲取數據時； 它總是交給領導者，領導者將通過它的哈希碼將請求委托給節點附近。 但在委托之前，Leader 必須確保 Commit Flag 為 TRUE（意味着事件被傳遞到最少定義的節點）。 否則，Leader 可以拋出異常。

此外，Leader 應該在事件上標記一個版本號並保留當前提交的標志版本號。 在檢索事件時，Leader 可以比較事件版本以確保所有節點都提供最新和最好的數據。

您可以從 Zookeeper 等系統中看到開箱即用的功能。