在這個博客系列中，我們將探討最終的一致性，如果沒有合適的詞彙表，這個術語很難定義。這是許多分布式系統使用的一致性模型，包括XDB Enterprise Edition。為了理解最終的一致性，我們需要知道兩個概念：暗示切換隊列和反熵，這兩個概念都需要特別注意。
第一部分
什麼是暗示的切換隊列？
儘管有一個很酷的名字，暗示切換（HH）隊列並沒有得到很多關注。HH隊列有一項非常重要的工作，但是除非您是系統管理員，否則很少直接與它交互。讓我們深入研究一下暗示的切換隊列到底是什麼，以及為什麼它對您很重要。
為了討論HH隊列，我們必須稍微討論一下分布式計算。像XDB Enterprise這樣的系統作為分布式系統存在的一個原因是消除單點故障。InfluxDB Enterprise使用複製因子（Replication Factor，RF）來確定任何一組數據應該存在多少個副本。將RF設置為1以上意味著系統有更高的機會成功地為請求提供服務，並且在數據節點中斷期間不會返回錯誤，這意味著我們不再只有一個可能丟失或不可用的數據副本。分布式系統也提出了獨特的挑戰：我們如何知道數據在整個系統中是一致的，尤其是在存儲多個數據副本時？
首先，我們必須理解最終一致性所作的一些承諾。擾流板警報：系統中的數據最終必須一致。當我們從分布式系統請求信息時，有時我們收到的答案可能不會一致地返回。當數據在整個系統中存儲和複製時，我們收到的答案有一些「漂移」，但隨著時間的推移，這種「漂移」應該被消除。在實踐中，這意味著最近的時間範圍可能在其結果中具有最大的變化，但是這種變化被消除，因為系統通過確保在任何地方都可以獲得相同信息的機制工作。
如果我們保證系統最終是一致的，我們如何解釋失敗的寫入？數據節點離線的原因有很多，從磁碟空間耗盡到普通的舊硬體故障。如果一個節點在離線時丟失了數據點，它就永遠不可能是一致的，因此，我們對最終一致性的承諾將變成謊言。
失敗的寫入也會影響整個系統的複製係數。維護指定的RF是我們必須遵守的另一個承諾，如果數據節點脫機，這也是寫入的另一個可能的失敗點。
例子
讓我們研究一下最簡單的示例：具有2個數據節點和一個RF=2的資料庫的XDB Enterprise。數據通過某個收集代理（例如Telegraf）到達您喜愛的負載平衡器，負載平衡器將寫操作（也讀取，但在本例中我們將使用寫操作）分發到底層數據節點。通常，負載平衡器以循環方式分發寫操作。接收數據的數據節點存儲並複製數據（將其發送到另一個數據節點），瞧：RF達到2。
注意：圖中未顯示的是元節點，您可以在這裡閱讀。
我們仍然需要一個失敗或延遲寫入的解決方案。假設系統中的一個節點在物理上過熱並離線。如果沒有備份，任何不成功的寫入都會被完全刪除，再也看不到。
進入HH隊列。
HH隊列是一個持久的、基於磁碟的隊列。它是XDB企業的一個基本部分，它試圖確保最終的一致性，這是一種機制，確保所有的數據節點最終在它們之間擁有一組一致的數據。對於xdbenterprise，HH隊列是實現最終一致性和確保最終實現每個資料庫的數據複製因子的一個重要部分。
現在，讓我們重溫一下集群中的一個數據節點離線的場景。節點脫機的原因有很多：硬體缺陷、磁碟空間限制，甚至是定期維護。如果沒有暗示的切換隊列，不成功的寫操作在存儲之前就死了，但是現在我們有了一個安全的地方讓它們著陸。
任何不成功的寫入都會被定向到HH隊列，當節點恢復聯機時，它會檢查HH隊列中是否有掛起的寫入。然後節點可以完成寫操作，直到隊列耗盡。Bam最終實現了一致性。
摘要
這是一個最終一致的集群內部發生的情況，但是外部有一些考慮因素：當數據成功寫入一個節點，但無法正確複製時，用戶看到成功還是失敗？HH隊列中的健康模式是什麼樣的？如果HH隊列不斷地充滿和耗盡，對整個系統健康意味著什麼？在下一篇文章中，我們將討論如何解決和識別XDB企業集群中的問題模式。
謝謝大家關注，轉發，點讚和點在看。