19種分散式系統設計模式 - Nishant

1. 布隆過濾器
布隆過濾器是一種節省空間的概率資料結構，用於測試元素是否是集合的成員。它用於我們只需要知道元素是否屬於它應該所在的地方（快取）。

在BigTable（和 Cassandra）中，任何讀取操作都必須從組成 Tablet 的所有 SSTable 中讀取。如果這些 SSTables 不在記憶體中，則讀取操作最終可能會執行許多磁碟訪問。為了減少磁碟訪問次數，BigTable 使用了布隆過濾器。

2. 一致的雜湊
一致的雜湊允許您輕鬆擴充套件，從而可以有效地複製資料，從而實現更好的可用性和容錯性。
通過對資料項的鍵進行雜湊以產生其在環上的位置，然後順時針遍歷環以找到位置大於該項位置的第一個節點，將由鍵標識的每個資料項分配給一個節點。與節點關聯的節點是資料項的位置。

一致性雜湊的主要優點是增量穩定性；一個節點離開或到達叢集隻影響其直接鄰居，其他節點不受影響。

3. 法定人數
在分散式環境中，仲裁是在宣佈操作總體成功之前需要成功執行分散式操作的伺服器的最小數量。

• Cassandra，為了確保資料的一致性，每個寫入請求都可以配置為只有在資料已寫入至少一個仲裁（或大多數）副本節點時才能成功。
• 對於leader選舉，Chubby使用Paxos，它使用quorum來保證強一致性。
• Dynamo將寫入複製到系統中其他節點的草率仲裁，而不是像 Paxos 這樣的嚴格多數仲裁。所有讀/寫操作都在首選項列表中的第一個 NN 健康節點上執行，這可能並不總是在遍歷一致雜湊環時遇到的第一個 NN 節點。

4. 領導者和追隨者
為了在管理資料的系統中實現容錯，需要在多個伺服器上覆制資料。
在叢集中選擇一臺伺服器作為領導者。領導者負責代表整個叢集做出決策，並將決策傳播到所有其他伺服器。
三到五個節點的叢集，就像在實現共識的系統中一樣，領導者選舉可以在資料叢集本身內實現，而不依賴於任何外部系統。領導者選舉發生在伺服器啟動時。每臺伺服器在啟動時都會開始選舉領導者，並嘗試選舉領導者。除非選出領導者，否則系統不接受任何客戶端請求。

5.心跳
Heartbeat 機制用於檢測現有的leader是否失敗，從而可以開始新的leader選舉。

6. Fencing
在leader-follower 設定中，當leader 失敗時，不可能確定leader 已經停止工作。例如，慢速網路或網路分割槽可以觸發新的領導者選舉，即使之前的領導者仍在執行並認為它仍然是活動的領導者。
Fencing 是在之前活躍的領導者周圍設定一個柵欄，這樣它就不能訪問叢集資源，從而停止服務任何讀/寫請求。
使用了以下兩種技術：

• 資源防護：系統阻止以前活躍的領導者訪問執行基本任務所需的資源。
• 節點防護：系統阻止先前活動的領導者訪問所有資源。執行此操作的常用方法是關閉或重置節點。

7. 預寫日誌（WAL）

預寫日誌是針對作業系統中檔案系統不一致問題的一種複雜解決方案。受資料庫管理系統的啟發，這種方法首先將要執行的操作的摘要寫到“日誌”中，然後再將它們實際寫入磁碟。在崩潰的情況下，作業系統可以簡單地檢查這個日誌並從它停止的地方開始。

8. 分段日誌

將日誌拆分為多個較小的檔案，而不是單個大檔案，以便於操作。
單個日誌檔案在啟動時讀取時可能會增長併成為效能瓶頸。較舊的日誌會定期清理，對單個大檔案進行清理操作很難實現。
單個日誌被分成多個段。日誌檔案在指定的大小限制後滾動。使用日誌分段，需要有一種直接的方法將邏輯日誌偏移（或日誌序列號）對映到日誌段檔案。

9. 高水位線High-Water mark
跟蹤領導者上的最後一個日誌條目，該條目已成功複製到法定數量的追隨者。日誌中此條目的索引稱為高水位線索引。領導者僅將資料公開至高水位線索引。

Kafka：為了處理不可重複讀取並確保資料一致性，Kafka 代理會跟蹤高水位線，這是特定分割槽共享的最大偏移量。消費者只能在高水位線之前看到訊息。

10. 租賃
租約就像一把鎖，但即使在客戶端離開時它仍然有效。客戶要求租用一段有限的時間，之後租約到期。如果客戶端想要延長租約，它可以在租約到期之前更新租約。

Chubby客戶端與領導者保持有時間限制的會話租約。在此時間間隔內，領導者保證不會單方面終止會話。

11. Gossip協議
Gossip 協議是點對點通訊機制，其中節點定期交換關於自己和他們知道的其他節點的狀態資訊。
每個節點每秒啟動一次 gossip 輪次，以與另一個隨機節點交換有關自己和其他節點的狀態資訊。

每秒鐘每臺伺服器與一個隨機選擇的伺服器交換資訊

12. Phi 累積故障檢測
該演算法利用歷史心跳資訊使閾值自適應。通用 Accrual Failure Detector 不會告訴伺服器是否處於活動狀態，而是輸出有關伺服器的懷疑級別。

Cassandra使用 Phi Accrual Failure Detector 演算法來確定叢集中節點的狀態。

13. 腦裂
分散式系統具有兩個或多個活動領導者的常見場景稱為裂腦。
腦裂是通過使用Generation Clock來解決的，Generation Clock只是一個單調遞增的數字來指示伺服器的世代。
每次選舉新的領導者時，世代數都會增加。這意味著如果舊領導者的代號為“1”，則新領導者的代號為“2”。這個世代號包含在從領導者傳送到其他節點的每個請求中。這樣，節點現在可以通過簡單地信任具有最高數量的領導者來輕鬆區分真正的領導者。

• Kafka：為了處理腦裂（我們可以有多個活動的控制器代理），Kafka 使用“紀元數”，它只是一個單調遞增的數字來指示伺服器的世代。
• HDFS：ZooKeeper 用於確保任何時候只有一個 NameNode 處於活動狀態。每個事務 ID 都會保留一個 epoch 編號，以反映 NameNode 的生成

14.校驗和Checksum
在分散式系統中，在元件之間移動資料時，從節點獲取的資料可能會損壞。
計算校驗和並將其與資料一起儲存。
為了計算校驗和，使用了 MD5、SHA-1、SHA-256 或 SHA-512 等加密雜湊函式。雜湊函式獲取輸入資料併產生一個固定長度的字串（包含字母和數字）；這個字串稱為校驗和。
當系統儲存一些資料時，它會計算資料的校驗和，並將校驗和與資料一起儲存。當客戶端檢索資料時，它會驗證從伺服器接收到的資料是否與儲存的校驗和相匹配。如果沒有，那麼客戶端可以選擇從另一個副本中檢索該資料。

HDFS和Chubby將每個檔案的校驗和與資料一起儲存

15. CAP 定理
CAP 定理指出，分散式系統不可能同時提供以下所有三個理想屬性：
一致性 (C)、可用性 (A) 和分割槽容差 (P)
根據 CAP 定理，任何分散式系統都需要從三個屬性中選擇兩個。三個選項是 CA、CP 和 AP。

• Dynamo：在 CAP 定理術語中，Dynamo 屬於 AP 系統的類別，旨在以犧牲強一致性為代價實現高可用性。
• BigTable：根據 CAP 定理，BigTable 是一個 CP 系統，即具有嚴格一致的讀寫。

16. PACELEC 定理
PACELC 定理指出，在複製資料的系統中：

• 如果存在分割槽（'P'），分散式系統可以在可用性和一致性（即'A'和'C'）之間進行權衡；
• else（'E'），當系統在沒有分割槽的情況下正常執行時，系統可以在延遲（'L'）和一致性（'C'）之間進行權衡。

定理的第一部分（PAC）與CAP定理相同，ELC是擴充套件。整個論文假設我們通過複製保持高可用性。因此，當出現故障時，CAP 定理佔上風。但如果不是，我們仍然需要考慮複製系統的一致性和延遲之間的權衡。

17. 提示切換Hinted Handoff
如果節點出現故障，系統會保留它們錯過的所有請求的提示（或註釋）。一旦故障節點恢復，請求將根據儲存的提示轉發給它們。
當一個節點當機時，領導者在本地磁碟上的一個文字檔案中寫入一個提示。該提示包含資料及其所屬的節點資訊。當領導者意識到它持有提示的節點已經恢復時，它會將每個提示的寫入請求轉發給該節點。

18.讀取修復
在分散式系統中，資料跨多個節點複製，一些節點最終可能會擁有陳舊的資料。
在讀取操作期間修復陳舊資料，因為此時我們可以從多個節點讀取資料進行比較並找到具有陳舊資料的節點。這種機制稱為讀取修復。一旦知道具有舊資料的節點，讀取修復操作會將較新版本的資料推送到具有較舊版本的節點。

Cassandra和Dynamo使用“讀取修復”將最新版本的資料推送到具有舊版本的節點。

19. 默克爾樹Merkle
讀取修復在處理讀取請求時消除了衝突。但是，如果副本明顯落後於其他副本，則可能需要很長時間才能解決衝突。
副本可以包含大量資料。天真地分割整個範圍來計算校驗和進行比較是不太可行的；有太多的資料要傳輸。相反，我們可以使用 Merkle 樹來比較範圍的副本。
Merkle 樹是雜湊的二叉樹，其中每個內部節點是其兩個子節點的雜湊，每個葉節點是原始資料的一部分的雜湊。

比較 Merkle 樹在概念上很簡單：

1. 比較兩棵樹的根雜湊。
2. 如果它們相等，則停止。
3. 遞迴左右孩子。

為了反熵和解決後臺衝突，Dynamo使用 Merkle 樹。