了解 Redis 的同學都知道它是一個純內存的資料庫，憑藉優秀的並發和易用性打下了互聯網項的半壁江山。Redis 之所以高性能是因為它的純內存訪問特性，而這也成了它致命的弱點 —— 內存的成本太高。所以在絕大多數場合，它比較適合用來做緩存，長期不被訪問的冷數據被淘汰掉，只有熱的數據緩存在內存中，這樣就不會浪費太多昂貴的內存空間。

但是 Redis 的誘惑太大了，用它來做持久存儲使用起來太方便了。要是內存的價格低廉，真恨不得把所有的數據都堆到 Redis 中，但是技術的選擇總是要考慮到現實世界的成本問題。那如何才能享受到 Redis 作為持久層易用性的同時還可以節省內存成本呢？

LevelDB 來了！

它是 Google 開源的 NOSQL 存儲引擎庫，是現代分散式存儲領域的一枚原子彈。在它的基礎之上，Facebook 開發出了另一個 NOSQL 存儲引擎庫 RocksDB，沿用了 LevelDB 的先進技術架構的同時還解決了 LevelDB 的一些短板。你可以將 RocksDB 比喻成氫彈，它比 LevelDB 的威力更大一些。現代開源市場上有很多資料庫都在使用 RocksDB 作為底層存儲引擎，比如大名鼎鼎的 TiDB。

但是為什麼我要講 LevelDB 而不是 RocksDB 呢？其原因在於 LevelDB 技術架構更加簡單清晰易於理解。如果我們先把 LevelDB 吃透了再去啃一啃 RocksDB 就會非常好懂了，RocksDB 也只是在 LevelDB 的基礎上添磚加瓦進行了一系列優化而已。等到我們攻破了 RocksDB 這顆氫彈，TiDB 核動力宇宙飛船已經在前方不遠處等著我們了。

Redis 緩存有什麼問題？

當我們將 Redis 拿來做緩存用時，背後肯定還有一個持久層資料庫記錄了全量的冷熱數據。Redis 和持久層資料庫之間的數據一致性是由應用程序自己來控制的。應用程序會優先去緩存中獲取數據，當緩存中沒有數據時，應用程序需要從持久層載入數據，然後再放進緩存中。當數據更新發生時，需要將緩存置為失效。

function getUser(String userId) User {
User user = redis.get(userId);
if user == null {
user = db.get(userId);
if user != null {
redis.set(userId, user);
}
}
return user;
}

function updateUser(String userId, User user) {
db.update(userId, user);
redis.expire(userId);
}

有過這方面開發經驗的朋友們就知道寫這樣的代碼還是挺繁瑣的，所有的涉及到緩存的業務代碼都需要加上這一部分邏輯。

嚴格來說我們還需要仔細考慮緩存一致性問題，比如在 updateUser 方法中，資料庫正確執行了更新，但是緩存 redis 因為網路抖動等原因置為失效沒有成功，那麼緩存中的數據就成了過期數據。如果你將設置緩存和更新持久存的先後順序反過來，也還是會有其它問題，這個讀者可以自行思考一下。

在多進程高並發場合也會導致緩存不一致，比如一個進程對某個 userId 調用 getUser() 方法，因為緩存里沒有，它需要從資料庫里載入。結果剛剛載入出來，正準備要設置緩存，這時候發生了內存 fullgc 代碼暫停了一會，而正在此時另一個進程調用了 updateUser 方法更新了資料庫，將緩存置為失效（其實緩存里本來就沒有數據）。然後前面那個進程終於 fullgc 結束要開始設置緩存了，這時候進緩存的就是過期的數據。

LevelDB 是如何解決的？

LevelDB 將 Redis 緩存和持久層合二為一，一次性幫你搞定緩存和持久層。有了 LevelDB，你的代碼可以簡化成下面這樣

function getUser(String userId) User {
return leveldb.get(userId);
}

function updateUser(String userId, User user) {
leveldb.set(userId, user);
}

而且你再也不用當心緩存一致性問題了，LevelDB 的數據更新要麼成功要麼不成功，不存在中間薛定諤狀態。LevelDB 的內部已經內置了內存緩存和持久層的磁碟文件，用戶完全不用操心內部是數據如何保持一致的。

LevelDB 具體是什麼？

前面我們說道它是一個 NOSQL 存儲引擎，它和 Redis 不是一個概念。Redis 是一個完備的資料庫，而 LevelDB 它只是一個引擎。如果將資料庫比喻成一輛高級跑車，那麼存儲引擎就是它的發動機，是核心是心臟。有了這個發動機，我們再給它包裝上一系列的配件和裝飾，就可以成為資料庫。不過也不要小瞧了配件和裝飾，做到極致那也是非常困難，將 LevelDB 包裝成一個簡單易用的資料庫需要加上太多太多精緻的配件。LevelDB 和 RocksDB 出來這麼多年，能夠在它的基礎上做出非常一個完備的生產級資料庫寥寥無幾。

在使用 LevelDB 時，我們還可以將它看成一個 Key/Value 內存資料庫。它提供了基礎的 Get/Set API，我們在代碼里可以通過這個 API 來讀寫數據。你還可以將它看成一個無限大小的高級 HashMap，我們可以往裡面塞入無限條 Key/Value 數據，只要磁碟可以裝下。

正是因為它只能算作一個內存資料庫，它裡面裝的數據無法跨進程跨機器共享。在分散式領域，LevelDB 要如何大顯身手呢？

這就需要靠包裝技術了，在 LevelDB 內存資料庫的基礎上包裝一層網路 API。當不同機器上不同的進程要來訪問它時，都統一走網路 API 介面。這樣就形成了一個簡易的資料庫。如果在網路層我們使用 Redis 協議來包裝，那麼使用 Redis 的客戶端就可以讀寫這個資料庫了。

如果要考慮資料庫的高可用性，我們在上面這個單機資料庫的基礎上再加上主從複製功能就可以變身成為一個主從結構的分散式 NOSQL 資料庫。在主從資料庫前面加一層轉發代理（負載均衡器如 LVS、F5 等），就可以實現主從的實時切換。

如果你需要的數據容量特別大以至於單個機器的硬碟都容不下，這時候就需要數據分片機制將整個資料庫的數據分散到多台機器上，每台機器只負責一部分數據的讀寫工作。數據分片的方案非常多，可以像 Codis 那樣通過轉發代理來分片，也可以像 Redis-Cluster 那樣使用客戶端轉發機制來分片，還可以使用 TiDB 的 Raft 分散式一致性演算法來分組管理分片。最簡單最易於理解的還是要數 Codis 的轉發代理分片。

當數據量繼續增長需要新增節點時，就必須將老節點上的數據部分遷移到新節點上，管理數據的均衡和遷移的又是一個新的高級配件 —— 數據均衡器。

看到這裡讀者應該可以從整體上理解了分散式資料庫中 LevelDB 所處的地位。下一節我們開始全面了解一下 LevelDB 的內存資料庫特性。

推薦閱讀：

相关文章