【系統設計】分佈式鍵值數據庫

鍵值存儲 ( key-value store )，也稱爲 K/V 存儲或鍵值數據庫，這是一種非關係型數據庫。每個值都有一個唯一的 key 關聯，也就是我們常說的 鍵值對。

常見的鍵值存儲有 Redis, Amazon DynamoDB，Microsoft Azure Cosmos DB，Memcached，etcd 等。

你可以在 DB-Engines 網站上看到鍵值存儲的排行。

設計要求

在這個面試的系統設計環節中，我們需要設計一個鍵值存儲，要滿足下面的幾個要求

每個鍵值的數據小於 10kB。
有存儲大數據的能力。
高可用，高擴展性，低延遲。

單機版 - 鍵值存儲

對於單個服務器來說，開發一個鍵值存儲相對來說會比較簡單，一種簡單的做法是，把鍵值都存儲在內存中的哈希表中，這樣查詢速度非常快。但是，由於內存的限制，把所有的數據放到內存中明顯是行不通的。

所以，對於熱點數據（經常訪問的數據）可以加載到內存中，而其他的數據可以存儲在磁盤。但是，當數據量比較大時，單個服務器仍然會很快達到容量瓶頸。

分佈式 - 鍵值存儲

分佈式鍵值存儲也叫分佈式哈希表，把鍵值分佈在多臺服務器上。在設計分佈式系統時，理解 CAP（一致性，可用性，分區容錯性）定理很重要。

CAP 定理

CAP 定理指出，在分佈式系統中，不可能同時滿足一致性、可用性和分區容錯性。讓我們認識一下這三個定義：

一致性：無論連接到哪一個節點，所有的客戶端在同一時間都會看到相同的數據。
可用性：可用性意味着任何請求數據的客戶端都會得到響應，即使某些節點因故障下線。
分區容錯性：分區表示兩個節點之間的網絡通信中斷。分區容錯性意味着，當存在網絡分區時，系統仍然可以繼續運行。

通常可以用 CAP 的兩個特性對鍵值存儲進行分類：

CP（一致性和分區容錯性）系統：犧牲可用性的同時支持一致性和分區容錯。

AP（可用性和分區容錯性）系統：犧牲一致性的同時支持可用性和分區容錯。

CA（一致性和可用性）系統：犧牲分區容錯性的同時支持一致性和可用性。

由於網絡故障是不可避免的，所以在分佈式系統中，必須容忍網絡分區。

讓我們看一些具體的例子，在分佈式系統中，爲了保證高可用，數據通常會在多個系統中進行復制。假設數據在三個節點 n1, n2, n3 進行復制，如下：

理想情況

在理想的情況下，網絡分區永遠不會發生。寫入 n1 的數據會自動複製到 n2 和 n3，實現了一致性和可用性。

現實世界的分佈式系統

在分佈式系統中，網絡分區是無法避免的，當發生分區時，我們必須在一致性和可用性之間做出選擇。

在下圖中，n3 出現了故障，無法和 n1 和 n2 通信，如果客戶端把數據寫入 n1 或 n2，就沒辦法複製到 n3，就會出現數據不一致的情況。

如果我們選擇一致性優先（CP系統），當 n3 故障時，就必須阻止所有對 n1 和 n2 的寫操作，避免三個節點之間的數據不一致。涉及到錢的系統通常有極高的一致性要求。

如果我們選擇可用性優先（AP系統），當 n3 故障時，系統仍然可以正常的寫入讀取，但是可能會返回舊的數據，當網絡分區恢復後，數據再同步到 n3 節點。

選擇合適的 CAP 是構建分佈式鍵值存儲的重要一環。

核心組件和技術

接下來，我們會討論構建鍵值存儲的核心組件和技術：

數據分區
數據複製
一致性
不一致時的解決方案
故障處理
系統架構圖
數據寫入和讀取流程

數據分區

在數據量比較大場景中，把數據都存放在單個服務器明顯是不可行的，我們可以進行數據分區，然後保存到多個服務器中。

需要考慮到的是，多個服務器之間的數據應該是均勻分佈的，在添加或者刪除節點時，需要移動的數據應該儘量少。

一致性哈希非常適合在這個場景中使用，下面的例子中，8臺服務器被映射到哈希環上，然後我們把鍵值的 key 也通過哈希算法映射到環上，然後找到順時針方向遇到的第一個服務器，並進行數據存儲。

使用一致性哈希，在添加和刪除節點時，只需要移動很少的一部分數據。

數據複製

爲了實現高可用性和可靠性，一條數據在某個節點寫入後，會複製到其他的節點，也就是我們常說的多副本。

那麼問題來了，如果我們有 8 個節點，一條數據需要在每個節點上都存儲嗎？

並不是，副本數和節點數沒有直接關係。副本數應該是一個可配置的參數，假如副本數爲 3，同樣可以藉助一致性哈希環，按照順時針找到 3 個節點，並進行存儲，如下

一致性

因爲鍵值數據在多個節點上覆制，所以我們必須要考慮到數據一致性問題。

Quorum 共識算法可以保證讀寫操作的一致性，我們先看一下 Quorum 算法中 NWR 的定義。

N = 副本數, 也叫複製因子，在分佈式系統中，表示同一條數據有多少個副本。

W = 寫一致性級別，表示一個寫入操作，需要等待幾個節點的寫入後纔算成功。

R = 讀一致性級別，表示讀取一個數據時，需要同時讀取幾個副本數，然後取最新的數據。

如下圖，N = 3

注意，W = 1 並不意味着數據只寫到一個節點，控制寫入幾個節點的是 N 副本數。

N = 3 表示，一條數據會寫入到 3 個節點，W = 1 表示，只要收到任何節點的第一個寫入成功確認消息（ACK）後，就直接返回寫入成功。

這裏的重點是，對 N、W、R的值進行不同的組合時，會產生不同的一致性效果。

當 W + R > N 的時候，通常是 N = 3, W = R = 2，對於客戶端來講，整個系統能保證強一致性，一定能返回更新後的那份數據。
當 W + R <= N 的時候，對於客戶端來講，整個系統只能保證最終一致性，所以可能會返回舊數據。

通過 Quorum NWR，可以調節系統一致性的程度。

一致性模型

一致性模型是設計鍵值存儲要考慮的另外一個重要因素，一致性模型定義了數據一致性的程度。

強一致性： 任何一個讀取操作都會返回一個最新的數據。
弱一致性： 數據更新之後，讀操作可能會返回最新的值，也有可能會返回更新前的值。
最終一致性： 這是弱一致性的另外一種形式。可能當前節點的值是不一致的，但是等待一段時間的數據同步之後，所有節點的值最終會保持一致。

強一致性的通常做法是，當有副本節點因爲故障下線時，其他的副本會強制中止寫入操作。一致性程度比較高，但是犧牲了系統的高可用。

而 Dynamo 和 Cassandra 都採用了最終一致性，這也是鍵值存儲推薦使用的一致性模型，當數據不一致時，客戶端讀取多個副本的數據，進行協調並返回數據。

不一致的解決方案：版本控制

多副本數據複製提供了高可用性，但是多副本可能會存在數據不一致的問題。

版本控制和向量時鐘（vector clock ）是一個很好的解決方案。向量時鐘是一組 [server，version] 數據，它通過版本來檢查數據是否發生衝突。

假設向量時鐘由 D([S1, v1], [S2, v2], ..., [Sn, vn]) 表示，其中 D 是數據項，v1 是版本計數器，下面是一個例子

客戶端把數據 D1 寫入系統，寫入操作由 Sx 處理，服務器 Sx 現在有向量時鐘 D1[(Sx, 1)]。
客戶端把 D2 寫入系統，假如這次還是由 Sx 處理，則版本號累加，現在的向量時鐘是 D2([Sx, 2])。
客戶端讀取 D2 並更新成 D3，假如這次的寫入由 Sy 處理，現在的向量時鐘是D3([Sx, 2], [Sy, 1]))。
客戶端讀取 D2 並更新成 D4，假如這次的寫入由 Sz 處理，現在的向量時鐘是 D4([Sx, 2], [Sz, 1]))。
客戶端讀取到 D3 和 D4，檢查向量時鐘後發現衝突（因爲不能判斷出兩個向量時鐘的順序關係），客戶端自己處理解決衝突，然後再次寫入。假如寫入是 Sx 處理，現在的向量時鐘是 D5([Sx, 3], [Sy, 1], [Sz, 1])。

注意，向量時鐘只能檢測到衝突，如何解決，那就需要客戶端讀取多個副本值自己處理了。