重庆工程网站建设,网站集约化建设纪要,网站开发会计分录,wordpress 247背景 Facebook 的软件系统栈一般包括两层#xff1a;上层是数据平面#xff0c; 下层是控制平面。
facebook software stack
数据平面包括大量的服务#xff0c;他们需要存储和处理海量数据。控制平面用来支撑数据平面#xff0c;起到一些控制作用#xff1a;调度、配置…背景 Facebook 的软件系统栈一般包括两层上层是数据平面 下层是控制平面。
facebook software stack
数据平面包括大量的服务他们需要存储和处理海量数据。控制平面用来支撑数据平面起到一些控制作用调度、配置、命名、切片等等。控制平面通常是有状态的比如控制的元信息为了存储这些元信息控制平面需要有自己的存储。控制平面对存储有以下要求
容错零依赖、可持久化、高可用。 丰富的 API事务范围查询二级索引。 在 17 年的时候 Facebook 使用几种组件来充当控制平面的存储包括
MySQLAPI 丰富表达能力强但是不支持容错。 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 负责共享日志的读写。则一个典型的写流程如下
客户端发起一个写请求 DelosTable 层将其转发给 DelosRuntime DelosRuntime 将该请求序列化后追加到共享日志 各个服务器侦听到该追加后读取其内容以同一种顺序将其应用到本地状态机 在该架构中有两个关键的设计点
共享日志层提供了具有线性一致性保证的极简 API 基于该简明 API上层可以方便的提供不同存储接口的实现 虚拟共识 到此为止该架构设计看起来相当简单但我们知道复杂性只能被转移但不可能凭空消失。可以看到最复杂的共识协议被隐藏在了共享日志后面于是问题随之而来
我们需要如何快速实现一个满足共识协议的的共享日志组件 随着技术的发展如果我们之后想用更好的共识协议该如何进行替换 为了解决这些问题Delos 提出了虚拟共识Virtual Consensus。通过抽象出一层虚拟共识协议Delos 的共享日志组件可以快速复用现有实现比如 Zookeeper之后为了提高性能也可以借助此该层对下层进行不停机迁移。
在 Delos 中虚拟共识协议的承载层被称为 VirtualLog。对上db 层基于 VirtualLog 层进行实现对下VirtualLog 被映射成一组物理共享日志称为 Loglets。每个 loget 提供和共享日志同样的 API外加一个 seal 命令。一旦被 sealLoglet 便不再接受追加。为了存储 VirtualLog 逻辑空间到 Loglets 物理空间的映射Delos 引入了新的组件MetaStore。
MetaStore 是一个带版本的简单 KV 存储。通过存储的不同版本的 Loglet 的切换VirtualLog 就自然的将流量打到新的 Loglet 上。如下图展示了 VirtualLog 向 MetaStore put 一个新版本ver0 - ver1的映射信息将流量无宕机的从 Zookeeper 切换到了 LogDevice 的过程 。 virtualizing consensus via the VirtualLog
定制 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 。 the 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 模式。前者能够获取更好的本地读性能并且让数据库实例和日志实例生命周期绑定。后者将数据库层和日志层分离可以避免不同层的资源争夺并允许各自按需伸缩。 converged vs disaggregated
下图是一个替换 NativeLoglet 后的性能提升对比 NativeLoglet compare
StripedLoglet 为了进一步提升性能在 VirtualLog 的抽象下Delos 利用分片思想又造出了一种叫做 StripedLoglet 的实现。该实现在底层组合了多个 Loglets 实例当 Append 请求到来时将其 round robin 的打到各个底层 Loglet 系统中从而极大提升性能。
此外StripedLoglet 允许多个 DelosRuntime 使用不同策略进行并行 Append并且允许暂时的空洞存在之后使用类似滑动窗口的机制进行捎带 ACK从而进一步提升性能。
底层多个 Loglet 系统可以视情况共享一个集群或分散到多个集群. striped loglet
The Last ThingVirtualLog Triming 此外值得一说的细节是VirtualLog 提供的 Trim 操作。得益于虚拟化的抽象Delos 可以通过删除映射将老的日志进行移除。当然一种更好的做法是将老的日志移动到 BackupLoget 的冷集群中然后改变映射对外提供一种无限日志的抽象进而允许按年龄对不同日志段进行细粒度的存储控制。
另一方面通过修改 MetaStore 中的映射Delos 允许修改单个日志记录对某些有问题的日志进行删除以避免系统 hang 住或者反复重启宕机。这是之前的一致性协议无法做到的。 trimming the VirtualLog
结语 Delos 位于 Facebook 系统的底层用于控制面的存储它采用分层的设计使得
在项目之初可以在某些层复用现有系统进行快速上线投入使用。 在上线之后允许不停机的替换更高性能的组件、实验更新的一致性协议。
summary
虚拟共识之于分布式系统有点像虚拟内存之于单机系统通过分层解耦使得设计者在系统构建时有更多腾挪空间。至于该思想是否能够实至名归还得等待时间和实践的检验。
