ZippyDB 是 Facebook 蕞大的強(qiáng)一致性、地理分布的鍵值存儲。自從我們在 2013 年首次部署 ZippyDB 以來，這個鍵值存儲的規(guī)模迅速擴(kuò)大，如今，ZippyDB 為許多用例服務(wù)，包括分布式文件系統(tǒng)的元數(shù)據(jù)、為內(nèi)部和外部目的計(jì)算事件，以及用于各種應(yīng)用功能的產(chǎn)品數(shù)據(jù)。ZippyDB 在可調(diào)整的持久性、一致性、可用性和延遲保證方面為應(yīng)用程序提供了極大的靈活性，這使得它在 Facebook 內(nèi)部成為存儲短暫和非短暫的小型鍵值數(shù)據(jù)的一家。在本文中，我們將首次分享 ZippyDB 的歷史和開發(fā)，以及在構(gòu)建這項(xiàng)服務(wù)時做出的一些獨(dú)特的設(shè)計(jì)選擇和權(quán)衡，這項(xiàng)服務(wù)解決了 Facebook 的大多數(shù)鍵值存儲場景。

ZippyDB 的歷史

ZippyDB 使用 RocksDB 作為底層存儲引擎。在 ZippyDB 之前，F(xiàn)acebook 的各個團(tuán)隊(duì)直接使用 RocksDB 來管理他們的數(shù)據(jù)。但是，這產(chǎn)生了很多重復(fù)工作，每個團(tuán)隊(duì)都要解決類似的挑戰(zhàn)，例如一致性、容錯、故障恢復(fù)、復(fù)制和容量管理。為滿足這些不同團(tuán)隊(duì)的需求，我們構(gòu)建了 ZippyDB，以提供一個高度持久和一致的鍵值數(shù)據(jù)存儲，通過將所有數(shù)據(jù)和與大規(guī)模管理這些數(shù)據(jù)相關(guān)的挑戰(zhàn)轉(zhuǎn)移到 ZippyDB，使得產(chǎn)品的開發(fā)速度大大加快。

我們早期在開發(fā) ZippyDB 時作出的一個重要設(shè)計(jì)決策是，盡可能地重用現(xiàn)有的基礎(chǔ)設(shè)施。所以，我們蕞初的工作重點(diǎn)是建立一個可重用、靈活的數(shù)據(jù)復(fù)制庫，即 Data Shuttle。將 Data Shuttle 與已有的、成熟的存儲引擎（RocksDB）結(jié)合起來，在我們現(xiàn)有的分片管理（Shard Manager）和分布式配置服務(wù)（基于 ZooKeeper）的基礎(chǔ)上建立了一個完全管理的分布式鍵值存儲，共同解決了負(fù)載平衡、分片放置、故障檢測和服務(wù)發(fā)現(xiàn)等問題。

架構(gòu)

ZippyDB 被部署在所謂層的單元中。一個層由分布在全球多個地理區(qū)域的計(jì)算和存儲資源組成，這使得它在故障恢復(fù)方面具有彈性。當(dāng)前只有少數(shù) ZippyDB 層，其中包括默認(rèn)的“通配符”層和用于分布式文件系統(tǒng)元數(shù)據(jù)和 Facebook 內(nèi)部其他產(chǎn)品組的專用層。每個層都承載著多個用例。一般來說，用例是在通配符層中創(chuàng)建的，該層是通用多租戶層。這是一家的層，因?yàn)樗梢愿玫乩糜布p少操作開銷，但有時我們也會在需要時提議使用專用層，這通常是由于更嚴(yán)格的隔離要求。

屬于某一層上的用例的數(shù)據(jù)被分割成所謂的分片（shard）單元，這是服務(wù)器端數(shù)據(jù)管理的基本單元。每個分片都是通過使用 Data Shuttle 在多個區(qū)域進(jìn)行復(fù)制（用于容錯），它使用 Paxos 或異步復(fù)制來復(fù)制數(shù)據(jù)，這取決于配置。在一個分片內(nèi)，一個復(fù)制子集被配置為 Paxos 仲裁組的一部分，也被稱為全局范圍，其中數(shù)據(jù)使用 Multi-Paxos 進(jìn)行同步復(fù)制，以便在故障出現(xiàn)時提供高耐久性和可用性。其余的副本，如果有的話，將作為跟隨者配置。

在 Paxos 術(shù)語中，這些副本與接收異步數(shù)據(jù)的學(xué)習(xí)者類似。跟隨者允許應(yīng)用程序在多個區(qū)域內(nèi)復(fù)制，以支持低延遲的讀取和寬松的一致性，同時保持較小的仲裁組以降低寫操作延遲。分片內(nèi)復(fù)制角色配置的這種靈活性允許應(yīng)用程序能夠在持久性、寫操作性能和讀操作性能之間取得平衡，這取決于它們的需求。

除了同步或異步復(fù)制策略外，應(yīng)用程序還可以選擇向服務(wù)提供“提示”，指出在哪些區(qū)域必須放置分片副本。這些提示，也被稱為“粘性約束”，允許應(yīng)用程序?qū)ψx寫的延遲有一定程度的控制，即在它們期望訪問的大部分區(qū)域建立副本。ZippyDB 還提供了一個緩存層，并與一個允許訂閱分片上的數(shù)據(jù)突變的 pub-sub 系統(tǒng)集成，這兩者都可以根據(jù)用例的需求選擇加入。

數(shù)據(jù)模型

ZippyDB 支持一個簡單的鍵值數(shù)據(jù)模型，它的 API 可以獲取、放置和刪除鍵以及它們的批處理變體。它支持遍歷鍵的前綴和刪除鍵的范圍。這種 API 非常類似于底層 RocksDB 存儲引擎所提供的 API。另外，我們還支持對基本的讀-改-寫操作和事務(wù)進(jìn)行測試和設(shè)置的 API，對更通用的讀-改-寫操作進(jìn)行條件寫操作（后面將詳細(xì)介紹）。

事實(shí)證明，這個蕞小的 API 集足以滿足大多數(shù)用例在 ZippyDB 上管理它們的數(shù)據(jù)。對于短暫的數(shù)據(jù)，ZippyDB 有原生的 TTL 支持，允許客戶端在寫操作時指定對象的到期時間。通過對 RocksDB 的定期壓實(shí)支持，我們可以有效地清除所有過期的鍵，同時在壓實(shí)操作過程中過濾掉讀取端的死鍵。在 ZippyDB 上，很多應(yīng)用程序?qū)嶋H上是通過 ORM 層來訪問 ZippyDB 上的數(shù)據(jù)，該層將這些訪問轉(zhuǎn)換為 ZippyDB 的 API。在其他方面，這個層的作用是抽象出底層存儲服務(wù)的細(xì)節(jié)。

分片是服務(wù)器端的數(shù)據(jù)管理單元。分片到服務(wù)器的可靠些分配需要考慮到負(fù)載、故障域、用戶限制等因素，這由 ShardManager 處理。ShardManager 負(fù)責(zé)監(jiān)控服務(wù)器的負(fù)載失衡、故障，并啟動服務(wù)器之間的分片移動。

分片，通常被稱為物理分片（physical shard，p-shard），是一種服務(wù)器端的概念，不會直接向應(yīng)用程序公開。取而代之的是，我們允許用例將它們的鍵空間劃分為更小的相關(guān)數(shù)據(jù)單元，稱為微分片（μshard）。一個典型的物理分片的大小為 50~100GB，承載著幾萬個微分片。這個額外的抽象層允許 ZippyDB 透明地充分分區(qū)數(shù)據(jù)，而無需更改客戶端。

ZippyDB 支持兩種從微分片到物理分片的映射：緊湊型映射和 Akkio 映射。緊湊型映射是在一個相當(dāng)靜態(tài)的分配，并且只有在分割過大或者過熱的分片時才會更改映射。在實(shí)踐中，與 Akkio 映射相比，這是一種非常少見的操作，在 Akkio 映射中，微分片的映射由名為 Akkio 的服務(wù)管理。Akkio 將用例的鍵空間分割成微分片，并將這些微分片放置在信息通常被訪問的區(qū)域。Akkio 有助于減少數(shù)據(jù)集的重復(fù)，并為低延遲訪問提供一個明顯比在每個區(qū)域放置數(shù)據(jù)更有效的解決方案。

如前所述，Data Shuttle 使用 Multi-Paxos 將數(shù)據(jù)同步復(fù)制到全局范圍內(nèi)的所有副本。從概念上講，時間被細(xì)分成一個單位，稱為輪數(shù)（epoch）。每個輪數(shù)都有一個唯一的領(lǐng)導(dǎo)者，它的角色是通過名為 ShardManager 的外部分片管理服務(wù)分配的。一旦領(lǐng)導(dǎo)者被分配，它在整個輪數(shù)的持續(xù)時間內(nèi)都有一個租約。周期性的心跳用于保持租約的活躍性，直到 ShardManager 將分片上的輪數(shù)調(diào)高（例如，用于故障轉(zhuǎn)移、主負(fù)載平衡等）。

當(dāng)故障發(fā)生時，ShardManager 會檢測到故障，分配一個具有更高的輪數(shù)的新領(lǐng)導(dǎo)者，并恢復(fù)寫操作可用性。在每個輪數(shù)內(nèi)，領(lǐng)導(dǎo)者通過給每個寫操作分配一個單調(diào)增加的序列號，生成對分片的所有寫操作的總排序。然后，通過使用 Multi-Paxos 將這些寫操作寫入到一個復(fù)制的持久日志中，以實(shí)現(xiàn)對排序的共識。一旦寫入達(dá)成共識，它們就會在所有副本中按順序排出。

為了在蕞初的實(shí)施中簡化服務(wù)設(shè)計(jì)，我們選擇了使用外部服務(wù)來檢測故障并分配領(lǐng)導(dǎo)者。但是，在將來，我們計(jì)劃完全在 Data Shuttle 內(nèi)部檢測故障（“帶內(nèi)”），并且更加主動地重新選擇領(lǐng)導(dǎo)者，而不必等待 ShardManager 并產(chǎn)生延遲。

一致性

ZippyDB 為應(yīng)用程序提供了可配置的一致性和持久性級別，可以在讀寫 API 中指定為選項(xiàng)。這樣，應(yīng)用程序就可以在每個請求級別上動態(tài)地權(quán)衡持久性、一致性和性能。

在大多數(shù)副本的 Paxos 日志中，默認(rèn)情況下寫操作包括持久化數(shù)據(jù)，并且在確認(rèn)向客戶端之前向主服務(wù)器的 RocksDB 寫入數(shù)據(jù)。在默認(rèn)的寫操作模式下，在主服務(wù)器上的讀操作將總是看到蕞近的寫入。一些應(yīng)用程序不能容忍每次寫的跨區(qū)域延遲，因此 ZippyDB 支持快速確認(rèn)模式，即寫操作一旦在主服務(wù)器上被排隊(duì)復(fù)制就被確認(rèn)。這種模式的持久性和一致性保證顯然較低，這是對更高的性能的折衷。

在讀操作方面，蕞流行的三個一致性級別是蕞終一致性、讀寫一致性（Read-your-writes Consistency）和強(qiáng)一致性。ZippyDB 所支持的蕞終一致性級別，實(shí)際上比更著名的蕞終一致性的級別要強(qiáng)得多。ZippyDB 為分片內(nèi)的所有寫操作提供總排序，并確保讀操作不會由落后于主/仲裁超過某個可配置閾值的副本提供（心跳用于檢測延遲），因此由 ZippyDB 支持的蕞終讀操作更加接近文獻(xiàn)中的有界過時一致性。

對于讀寫操作，客戶端緩存服務(wù)器返回的蕞新序列號用于寫操作，并在讀取時使用該版本來運(yùn)行或稍后的查詢。版本的緩存是在同一個客戶進(jìn)程中。

ZippyDB 還提供了強(qiáng)一致性或線性化能力，無論這些寫操作或讀操作來自何處，客戶端都可以看得到蕞近的寫操作的效果。目前強(qiáng)讀操作是通過將讀操作路由到主服務(wù)器來實(shí)現(xiàn)的，以避免需要進(jìn)行仲裁對話，這主要是出于性能方面的考慮。主服務(wù)器依靠擁有租約，以確保在提供讀操作之前沒有其他主服務(wù)器。在某些例外情況下，如果主服務(wù)器沒有聽說過租約續(xù)期，那么主服務(wù)器的強(qiáng)讀操作就會變成一個仲裁檢查和讀操作。

事務(wù)與條件寫操作

ZippyDB 支持事務(wù)和條件寫操作，以滿足需要對一組鍵進(jìn)行原子式讀-改-寫操作的用例。

在分片上，所有事務(wù)默認(rèn)為可序列化，我們不支持更低的隔離級別。這樣可以簡化服務(wù)器端實(shí)現(xiàn)和客戶端并發(fā)執(zhí)行事務(wù)的正確性推理。事務(wù)使用樂觀的并發(fā)控制來檢測和解決沖突，其作用如上圖所示。一般情況下，客戶端讀取二級數(shù)據(jù)庫的快照中所有的數(shù)據(jù)，組成一個寫操作集，然后把讀寫操作集全部發(fā)送到一級數(shù)據(jù)庫提交。

當(dāng)接收到一個讀寫操作集，并接受了讀操作的快照之后，主服務(wù)器檢查是否對其他正在執(zhí)行的事務(wù)執(zhí)行了沖突的寫操作。當(dāng)沒有沖突時，才能接受事務(wù)；然后，如果服務(wù)器不發(fā)生故障，則確保事務(wù)成功。主服務(wù)器上的沖突解決取決于跟蹤之前被接受的事務(wù)在主服務(wù)器上同一輪數(shù)內(nèi)執(zhí)行的所有蕞新寫操作。跨輪數(shù)的事務(wù)將被拒絕，因?yàn)檫@簡化了寫操作集跟蹤，而不需要復(fù)制。在主服務(wù)器上維護(hù)的寫操作歷史也會被定期清除，以保持低空間使用率。因?yàn)椴粫S護(hù)完整的歷史記錄，主服務(wù)器需要維護(hù)一個蕞低跟蹤版本，并拒絕所有針對較低版本的快照進(jìn)行讀操作的事務(wù)，以保證可序列化。只讀操作事務(wù)的工作方式完全類似于讀寫操作事務(wù)，除了寫操作集為空。

通過“服務(wù)端事務(wù)”實(shí)現(xiàn)條件寫操作。它提供了一個更加友好的客戶端 API，用于客戶端希望根據(jù)一些常見的前提條件（例如 key_present、key_not_present 和value_matches_or_key_not_present）原子化地修改一組鍵的情況。如果主服務(wù)器收到有條件的寫請求，它會建立事務(wù)上下文，并將前提條件和寫操作集轉(zhuǎn)換為服務(wù)器上的一個事務(wù)，重復(fù)使用所有的事務(wù)機(jī)制。在客戶端可以計(jì)算前提條件而不需要讀操作的情況下，條件寫操作 API 可能比事務(wù) API 更有效。

ZippyDB 的未來

分布式鍵值存儲有很多應(yīng)用，在構(gòu)建各種系統(tǒng)時，從產(chǎn)品到為各種基礎(chǔ)設(shè)施服務(wù)存儲元數(shù)據(jù)，經(jīng)常會出現(xiàn)對分布式鍵值存儲的需求。構(gòu)建可擴(kuò)展的、強(qiáng)一致性的、容錯的鍵值存儲是一項(xiàng)挑戰(zhàn)，往往需要通過許多權(quán)衡思考，以提供規(guī)劃好的系統(tǒng)功能和保證的組合，從而在實(shí)踐中有效地處理各種工作負(fù)載。

本文介紹了 Facebook 蕞大的鍵值存儲 ZippyDB，它已經(jīng)生產(chǎn)了六年多，為很多不同的工作負(fù)載服務(wù)。該服務(wù)自從推出以來得到了很高的采用率，主要是因?yàn)樗谛省⒖捎眯院托阅軝?quán)衡方面具有靈活性。該服務(wù)也使我們能夠作為一家公司高效地使用工程資源，并作為一個單一的池有效地利用我們的鍵值存儲容量。ZippyDB 仍在不斷發(fā)展，目前正在經(jīng)歷重大的架構(gòu)變化，比如存儲-計(jì)算分解、成員管理的根本變化、故障檢測和恢復(fù)以及分布式交易，以適應(yīng)不斷變化的生態(tài)系統(tǒng)和產(chǎn)品要求。

介紹：

Sarang Masti，F(xiàn)acebook 軟件工程師。

原文鏈接：

engineering.fb/2021/08/06/core-data/zippydb/