本文整理自OSDI 2020 Virtual Consensus in Delos 论文演讲,探讨了分布式系统中控制面的存储组件的实现,提出了一种基于分层抽象思想的分布式架构。其核心在于提出了一种逻辑协议层,使得物理层能够按需进行实现、移植和迁移,有点相似于单机系统中虚拟内存之于物理内存的味道。web
背景
Facebook 的软件系统栈通常包括两层:上层是数据平面, 下层是控制平面。数据库
数据平面包括大量的服务,他们须要存储和处理海量数据。控制平面用来支撑数据平面,起到一些控制做用:调度、配置、命名、切片等等。控制平面一般是有状态的,好比控制的元信息,为了存储这些元信息,控制平面须要有本身的存储。控制平面对存储有如下要求:性能优化
-
容错:零依赖、可持久化、高可用。 -
丰富的 API:事务,范围查询,二级索引。
在 17 年的时候, Facebook 使用几种组件来充当控制平面的存储,包括:服务器
-
MySQL:API 丰富,表达能力强,可是不支持容错。 -
ZooKeeper:容错,零依赖,可是 API 表达能力弱。
能够看出,他们都不能很好的同时知足控制平面对存储的需求。此外,做为单体架构,上述组件都比较难改形成同时支持容错和丰富 API 的系统。此外,还有一大问题,团队当时所面临的工期很是紧。最终,他们交出的答卷是 —— Delos。微信
架构
Delos 是一个基于共享日志(shared log)的控制面存储系统。db 层的实例经过 append 和 read 与共享日志进行交互,从而保持对外状态的一致性。根据近几十年的研究,使用共享日志做为 API,能够很好的向 db 层隐藏共识协议的大量细节。架构
读写流程
存储服务能够分为两层,db API 层和共享日志 runtime 层。如上图,以表格存储为例,在上层,DelosTable 负责提供表格存储的 API;在下层,DelosRuntime 负责共享日志的读写。则,一个典型的写流程以下:app
-
客户端发起一个写请求 -
DelosTable 层将其转发给 DelosRuntime -
DelosRuntime 将该请求序列化后追加到共享日志 -
各个服务器侦听到该追加后,读取其内容,以同一种顺序将其应用到本地状态机
在该架构中,有两个关键的设计点:编辑器
-
共享日志层提供了具备线性一致性保证的极简 API -
基于该简明 API,上层能够方便的提供不一样存储接口的实现
虚拟共识
到此为止,该架构设计看起来至关简单,但咱们知道,复杂性只能被转移,但不可能凭空消失。能够看到,最复杂的共识协议被隐藏在了共享日志后面,因而问题随之而来:分布式
-
咱们须要如何快速实现一个知足共识协议的的共享日志组件? -
随着技术的发展,若是咱们以后想用更好的共识协议,该如何进行替换?
为了解决这些问题,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 的过程 。
定制 Loglet
在知足基本需求后,为了进一步提高性能,Delos 想本身定制 Loglet,以知足如下特色:
-
简单:simple -
快速:fast -
容错:fault tolerant
NativeLoglet
只实现其中两点,比较容易;若要三者皆得,有点困难。Delos 经过分治策略,将其分解为两个组件:
-
MetaStore:进行容错 -
Loglet:专一性能
此时,全部一致性的来源便都移到了 MetaStore 之上。而 MetaStore 功能相对简单,只需保存空间映射,并提供容错的 reconfiguration 源语(即对映射进行操做,好比 loglet 切换),且 reconfiguration 是个低频操做。所以 MetaStore 的实现无需关注性能优化,只须要按照 Lamport 最初的 Paxos 进行实现便可,能够保证 MetaStore 实现的简洁性。
同时,将 Loglet 职能弱化,再也不须要提供彻底的容错机制,只需提供一个高可用的 seal 命令便可。如此一来,当一个 Loget 不可用时,VirtualLog 只需将其 seal,而后将流量切向其余 Loglet 便可。
据此,Delos 实现了新的 Loglet 实例——NativeLoglet 。
直观感受来讲,NativeLoglet 相似一个弱化版的 LogDevice。其交互流程以下:
-
正常运行时,集群中某个 LogServer 充当 Sequencer -
全部 DelosRuntime 发出的 Append 请求都要经过 Sequencer 定序后,追加到各个 LogServer -
当 Sequencer 所在 LogServer 宕机后,DelosRuntime 直接向全部 LogServer 发送 CheckTail 请求,以 quorum 协议肯定 tail -
全部 DelosRuntime 均可以发起 seal 请求,对 NativeLoglet 进行 seal
注意,NativeLoget 中全部 LogServer 能够和 DelosRuntime 部署在一块(称做 Converged 模式),也能够单独部署(称做 Disaggregated 模式)。前者可以获取更好的本地读性能,而且让数据库实例和日志实例生命周期绑定。后者将数据库层和日志层分离,能够避免不一样层的资源争夺,并容许各自按需伸缩。
下图是一个替换 NativeLoglet 后的性能提高对比:
StripedLoglet
为了进一步提高性能,在 VirtualLog 的抽象下,Delos 利用分片思想又造出了一种叫作 StripedLoglet 的实现。该实如今底层组合了多个 Loglets 实例,当 Append 请求到来时,将其 round robin 的打到各个底层 Loglet 系统中,从而极大提高性能。
此外,StripedLoglet 容许多个 DelosRuntime 使用不一样策略进行并行 Append,而且容许暂时的空洞存在,以后使用相似滑动窗口的机制,进行捎带 ACK,从而进一步提高性能。
底层多个 Loglet 系统能够视状况共享一个集群或分散到多个集群。
The Last Thing:VirtualLog Triming
此外值得一说的细节是,VirtualLog 提供的 Trim 操做。得益于虚拟化的抽象,Delos 能够经过删除映射,将老的日志进行移除。固然,一种更好的作法是,将老的日志移动到 BackupLoget 的冷集群中,而后改变映射,对外提供一种无限日志的抽象,进而容许按年龄对不一样日志段进行细粒度的存储控制。
另外一方面,经过修改 MetaStore 中的映射,Delos 容许修改单个日志记录,对某些有问题的日志进行删除,以免系统 hang 住或者反复重启宕机。这是以前的一致性协议没法作到的。
结语
Delos 位于 Facebook 系统的底层(用于控制面的存储),它采用分层的设计,使得:
-
在项目之初,能够在某些层复用现有系统,进行快速上线,投入使用。 -
在上线以后,容许不停机的替换更高性能的组件、实验更新的一致性协议。
虚拟共识之于分布式系统,有点像虚拟内存之于单机系统,经过分层解耦,使得设计者在系统构建时有更多腾挪空间。至于该思想是否可以实至名归,还得等待时间和实践的检验。
参考
-
OSDI 20 该论文的讲解视频:https://www.youtube.com/watch?v=wd-GC_XhA2g
-
谷歌工程文章:https://engineering.fb.com/2019/06/06/data-center-engineering/delos/
-
论文 Virtual Consensus in Delos:https://research.fb.com/publications/virtual-consensus-in-delos/
本文分享自微信公众号 - 分布式点滴(distributed-system)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。