Facebook Delos 中的虛擬共識協議

本文整理自OSDI 2020 Virtual Consensus in Delos 論文演講，探討了分佈式系統中控制面的存儲組件的實現，提出了一種基於分層抽象思想的分佈式架構。其核心在於提出了一種邏輯協議層，使得物理層能夠按需進行實現、移植和遷移，有點相似於單機系統中虛擬內存之於物理內存的味道。

背景

Facebook 的軟件系統棧通常包括兩層：上層是數據平面， 下層是控制平面。

facebook software stack

數據平面包括大量的服務，他們須要存儲和處理海量數據。控制平面用來支撐數據平面，起到一些控制做用：調度、配置、命名、切片等等。控制平面一般是有狀態的，好比控制的元信息，爲了存儲這些元信息，控制平面須要有本身的存儲。控制平面對存儲有如下要求：

1. 容錯：零依賴、可持久化、高可用。
2. 豐富的 API：事務，範圍查詢，二級索引。

在 17 年的時候，  Facebook 使用幾種組件來充當控制平面的存儲，包括：

1. MySQL：API 豐富，表達能力強，可是不支持容錯。
2. ZooKeeper：容錯，零依賴，可是 API 表達能力弱。

能夠看出，他們都不能很好的同時知足控制平面對存儲的需求。此外，做爲單體架構，上述組件都比較難改形成同時支持容錯和豐富 API 的系統。此外，還有一大問題，團隊當時所面臨的工期很是緊。最終，他們交出的答卷是 —— Delos。

架構

Delos 是一個基於共享日誌（shared log）的控制面存儲系統。db 層的實例經過 append 和 read 與共享日誌進行交互，從而保持對外狀態的一致性。根據近幾十年的研究，使用共享日誌做爲 API，能夠很好的向 db 層隱藏共識協議的大量細節。

design based sharedlog

讀寫流程

read write procedure via shared log

存儲服務能夠分爲兩層，db API 層和共享日誌 runtime 層。如上圖，以表格存儲爲例，在上層，DelosTable 負責提供表格存儲的 API；在下層，DelosRuntime 負責共享日誌的讀寫。則，一個典型的寫流程以下：

1. 客戶端發起一個寫請求
2. DelosTable 層將其轉發給 DelosRuntime
3. DelosRuntime 將該請求序列化後追加到共享日誌
4. 各個服務器偵聽到該追加後，讀取其內容，以同一種順序將其應用到本地狀態機

在該架構中，有兩個關鍵的設計點：

1. 共享日誌層提供了具備線性一致性保證的極簡 API
2. 基於該簡明 API，上層能夠方便的提供不一樣存儲接口的實現

虛擬共識

到此爲止，該架構設計看起來至關簡單，但咱們知道，複雜性只能被轉移，但不可能憑空消失。能夠看到，最複雜的共識協議被隱藏在了共享日誌後面，因而問題隨之而來：

1. 咱們須要如何快速實現一個知足共識協議的的共享日誌組件？
2. 隨着技術的發展，若是咱們以後想用更好的共識協議，該如何進行替換？

爲了解決這些問題，Delos 提出了虛擬共識（Virtual Consensus）。經過抽象出一層虛擬共識協議，Delos 的共享日誌組件能夠快速複用現有實現，好比 Zookeeper；以後爲了提升性能，也能夠藉助此該層對下層進行不停機遷移。

在 Delos 中，虛擬共識協議的承載層被稱爲 VirtualLog。對上，db 層基於 VirtualLog 層進行實現；對下，VirtualLog 被映射成一組物理共享日誌，稱爲 Loglets。每一個 loget 提供和共享日誌一樣的 API，外加一個 seal 命令。一旦被 seal，Loglet 便再也不接受追加。爲了存儲 VirtualLog 邏輯空間到 Loglets 物理空間的映射，Delos 引入了新的組件：MetaStore。

MetaStore 是一個帶版本的簡單 KV 存儲。經過存儲的不一樣版本的 Loglet 的切換，VirtualLog 就天然的將流量打到新的 Loglet 上。以下圖展現了 VirtualLog 向 MetaStore put 一個新版本（ver0 -> ver1）的映射信息，將流量無宕機的從 Zookeeper 切換到了 LogDevice 的過程 。

virtualizing consensus via the VirtualLog

定製 Loglet

在知足基本需求後，爲了進一步提高性能，Delos 想本身定製 Loglet，以知足如下特色：

1. 簡單：simple
2. 快速：fast
3. 容錯：fault tolerant

NativeLoglet

只實現其中兩點，比較容易；若要三者皆得，有點困難。Delos 經過分治策略，將其分解爲兩個組件：

1. MetaStore：進行容錯
2. Loglet：專一性能

此時，全部一致性的來源便都移到了 MetaStore 之上。而 MetaStore 功能相對簡單，只需保存空間映射，並提供容錯的 reconfiguration 源語（即對映射進行操做，好比 loglet 切換），且 reconfiguration 是個低頻操做。所以 MetaStore 的實現無需關注性能優化，只須要按照 Lamport 最初的 Paxos 進行實現便可，能夠保證 MetaStore 實現的簡潔性。

同時，將 Loglet 職能弱化，再也不須要提供徹底的容錯機制，只需提供一個高可用的 seal 命令便可。如此一來，當一個 Loget 不可用時，VirtualLog 只需將其 seal，而後將流量切向其餘 Loglet 便可。

據此，Delos 實現了新的 Loglet 實例——NativeLoglet 。

the NativeLoglet

直觀感受來講，NativeLoglet 相似一個弱化版的 LogDevice。其交互流程以下：

1. 正常運行時，集羣中某個 LogServer 充當 Sequencer
2. 全部 DelosRuntime 發出的 Append 請求都要經過 Sequencer 定序後，追加到各個 LogServer
3. 當 Sequencer 所在 LogServer 宕機後，DelosRuntime 直接向全部 LogServer 發送 CheckTail 請求，以 quorum 協議肯定 tail
4. 全部 DelosRuntime 均可以發起 seal 請求，對 NativeLoglet 進行 seal

注意，NativeLoget 中全部 LogServer 能夠和 DelosRuntime 部署在一塊（稱做 Converged 模式），也能夠單獨部署（稱做 Disaggregated 模式）。前者可以獲取更好的本地讀性能，而且讓數據庫實例和日誌實例生命週期綁定。後者將數據庫層和日誌層分離，能夠避免不一樣層的資源爭奪，並容許各自按需伸縮。

converged vs disaggregated

下圖是一個替換 NativeLoglet 後的性能提高對比：

NativeLoglet compare

StripedLoglet

爲了進一步提高性能，在 VirtualLog 的抽象下，Delos 利用分片思想又造出了一種叫作 StripedLoglet 的實現。該實如今底層組合了多個 Loglets 實例，當 Append 請求到來時，將其 round robin 的打到各個底層 Loglet 系統中，從而極大提高性能。

此外，StripedLoglet 容許多個 DelosRuntime 使用不一樣策略進行並行 Append，而且容許暫時的空洞存在，以後使用相似滑動窗口的機制，進行捎帶 ACK，從而進一步提高性能。

底層多個 Loglet 系統能夠視狀況共享一個集羣或分散到多個集羣。

striped loglet

The Last Thing：VirtualLog Triming

此外值得一說的細節是，VirtualLog 提供的 Trim 操做。得益於虛擬化的抽象，Delos 能夠經過刪除映射，將老的日誌進行移除。固然，一種更好的作法是，將老的日誌移動到 BackupLoget 的冷集羣中，而後改變映射，對外提供一種無限日誌的抽象，進而容許按年齡對不一樣日誌段進行細粒度的存儲控制。

另外一方面，經過修改 MetaStore 中的映射，Delos 容許修改單個日誌記錄，對某些有問題的日誌進行刪除，以免系統 hang 住或者反覆重啓宕機。這是以前的一致性協議沒法作到的。

trimming the VirtualLog

結語

Delos 位於 Facebook 系統的底層（用於控制面的存儲），它採用分層的設計，使得：

1. 在項目之初，能夠在某些層複用現有系統，進行快速上線，投入使用。
2. 在上線以後，容許不停機的替換更高性能的組件、實驗更新的一致性協議。

summary

虛擬共識之於分佈式系統，有點像虛擬內存之於單機系統，經過分層解耦，使得設計者在系統構建時有更多騰挪空間。至於該思想是否可以實至名歸，還得等待時間和實踐的檢驗。

參考

1. OSDI 20 該論文的講解視頻：https://www.youtube.com/watch?v=wd-GC_XhA2g

2. 谷歌工程文章：https://engineering.fb.com/2019/06/06/data-center-engineering/delos/

3. 論文 Virtual Consensus in Delos：https://research.fb.com/publications/virtual-consensus-in-delos/

本文分享自微信公衆號 - 分佈式點滴（distributed-system）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。