洪孝利的評價推薦

Facebook 工程團隊最近發布了一篇博客文章，闡述了如何構建其通用的鍵值存儲的，也就是 ZippyDB。ZippyDB 是 Facebook 最大的鍵值存儲，已經投入生產環境超過了六年的時間。它為應用程序在各個方面提供了靈活性，包括可調整的持久性、一致性、可用性以及低延遲保證等方面。ZippyDB 的使用場景包括分布式文件系統的元數據、用于內部和外部目的的事件計數，以及用于各種應用特性的產品數據。

Facebook 的軟件工程師 Sarang Masti 對創建 ZippyDB 的動機進行了深入分析：

一個 ZippyDB 部署（叫做“tier”）由分布到全世界范圍多個區域（region）的計算和存儲資源組成。每個部署都以多租戶的方式托管多個用例。ZippyDB 會將屬于某個用例的數據劃分為分片（shard）。根據配置，它會跨多個區域為每個分片創建副本，從而實現容錯性，這個過程可以使用 Paxos 或異步副本來實現。

圖片來源：https://engineering.fb.com/2021/08/06/core-data/zippydb/

每個分片副本的子集都是某個 quorum 組的一部分，在這里數據會被同步復制，從而能夠在出現故障的時候提供高持久性和可用性。如果以 follower 的形式配置了其他副本的話，將會采用異步復制的方式。Follower 能夠讓應用程序擁有多個區域內的副本以支持寬松一致性的低延遲讀取，同時能夠保持較小的 quorum 大小以實現更低的寫入延遲。這種分片內副本角色配置的靈活性能夠讓應用程序根據自身的需要平衡持久性、寫入的性能和讀取的性能。

ZippyDB 為應用程序提供了可配置的一致性和持久性等級，它們可以在讀取和寫入 API 中以可選項的形式進行指定。對于寫入來講，ZippyDB 默認會將數據持久化到大多數副本的 Paxos 的日志中并將數據寫入到主 RocksDB 上。這樣的話，對于主節點的讀取能夠始終看到最新的寫入。除此之外，它還支持一個更低延遲的快速確認（fast-acknowledge）模式，在這種模式下，在主節點上排隊進行副本操作的時候，寫入就會進行確認。

對于讀取來講，ZippyDB 支持最終一致、讀取自己的寫入（read-your-write，該模式指的是系統能夠保證一旦某個條目被更新，同一個客戶端發起的任意讀取請求都會返回更新后的數據，參見該文章的闡述——譯者注）和強讀模式。“對于‘讀取自己的寫入’模式，客戶端會緩存服務器在進行寫入時得到的最新序列號，并且會在隨后的讀取查詢中使用該版本號”。ZippyDB 在實現強讀取的時候，會將讀取操作路由到主節點上，從而避免與 quorum 進行對話。“在某些極端的情況下，主節點尚未得到更新的消息，這時候對主節點的強讀就變成了對 quorum 的檢查和讀取。”

圖片來源：https://engineering.fb.com/2021/08/06/core-data/zippydb/

ZippyDB 支持事務和條件性的寫入，從而能夠適用于要對一組鍵進行原子讀取 - 修改 - 寫入操作的使用場景。Masti 介紹了 ZippyDB 的實現：

所有事務在分片上默認是序列化的，我們不支持更低的隔離級別。這簡化了服務器端的實現，并且便于在客戶端推斷出并行執行事務的正確性。事務使用樂觀并發控制來探測和解決沖突，作用原理如上圖所示。

ZippyDB 中的分片，通常被稱為物理分片或 p 分片，是服務器側的數據管理單位。應用程序將其核心空間（key space）劃分為μshard（微分片）。每個 p-shard 通常托管著幾萬個μshard。根據 Masti 的說法，“這個額外的抽象層允許 ZippyDB 在客戶端不做任何改變的情況下透明地重新分片（reshard）數據”。

ZippyDB 利用 Akkio 實現 p-shard 和μshard 之間的映射，從而得到了進一步優化。Akkio 將μshard 放置在信息通常被訪問的地理區域。通過這種方式，Akkio 有助于減少數據集的重復，這樣就為低延遲訪問提供一個比在每個區域放置數據更有效的解決方案。

原文鏈接：

https://www..com/news/2021/09/facebook-zippydb/

 ??