写点什么

Facebook 强一致性键值存储 ZippyDB 架构简介

  • 2021-10-11
  • 本文字数:1684 字

    阅读完需:约 6 分钟

Facebook强一致性键值存储ZippyDB架构简介

Facebook 工程团队最近发布了一篇博客文章,阐述了如何构建其通用的键值存储的,也就是 ZippyDB。ZippyDB 是 Facebook 最大的键值存储,已经投入生产环境超过了六年的时间。它为应用程序在各个方面提供了灵活性,包括可调整的持久性、一致性、可用性以及低延迟保证等方面。ZippyDB 的使用场景包括分布式文件系统的元数据、用于内部和外部目的的事件计数,以及用于各种应用特性的产品数据。


Facebook 的软件工程师 Sarang Masti 对创建 ZippyDB 的动机进行了深入分析:


ZippyDB 使用RocksDB作为底层的存储引擎。在 ZippyDB 之前,Facebook 的各个团队都直接使用 RocksDB 来管理他们的数据。这导致每个团队在解决类似的挑战时造成了工作的重复,比如一致性、容错、故障恢复、副本以及容量管理等。为了解决这些不同团队的需求,我们创建了 ZippyDB,以提供一个高度持久化和一致性的键值数据存储,通过将所有的数据转移到 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 有助于减少数据集的重复,这样就为低延迟访问提供一个比在每个区域放置数据更有效的解决方案。


原文链接:

ZippyDB: The Architecture of Facebook’s Strongly Consistent Key-Value Store

2021-10-11 20:173944

评论

发布
暂无评论
发现更多内容

面试,到底在考察什么?

程序员架构进阶

面试 方法论

LAXCUS 大数据集群操作系统:一个分布式分时共享 E 级系统软件(七)

陈泽云

人工智能 大数据 算法

利用下班时间,我两星期完成了redis入门与进阶

小松漫步

数据库 redis

[Pulsar 社区周报] 2020-10-31 ~ 2020-11-06

Apache Pulsar

大数据 开源

基于Fabric的性能测试与调优实践

华为云开发者联盟

区块链 算法 测试 fabric 华为云

Oracle、NoSQL和NewSQL 数据库技术对比

VoltDB

数据库 大数据 数据分析 物联网

架构师Week4作业

lggl

作业

氪信团队再夺冠!易观数科第四届OLAP算法大赛前三甲诞生!

易观大数据

数据库 算法 OLAP

我就是增发、健身、养猫、社交通通拥有的锦鲤本鲤

脑极体

第六周总结

balsamspear

极客大学架构师训练营

Serverless 是一种思想状态

donghui

Serverless

第六周课后练习

balsamspear

极客大学架构师训练营

2020双11:看阿里背后的黑科技!

人工智能 云计算 大数据 运维 黑科技

【Mycat】作为Mycat核心开发者,怎能不来一波Mycat系列文章?

冰河

分布式事务 分布式数据库 系统架构 分布式存储 mycat

高交会第一天,高新技术成焦点

13530558032

Pulsar Summit Asia 2020 | 场景案例论坛(上):多行业,多场景

Apache Pulsar

大数据 开源 Apache Pulsar

mongodb 源码实现系列 - 网络传输层模块实现四

杨亚洲腾讯科技

MySQL 数据库 mongodb 高性能 分布式数据库mongodb

甲方日常 49

句子

工作 随笔杂谈 日常

极客大学 - 架构师训练营 第八周

9527

链表交集问题与DataNode宕机HDFS处理时序

garlic

极客大学架构师训练营

再拔头筹,FusionInsight为华为云大数据打造硬实力

华为云开发者联盟

大数据 数据仓库 数据湖 FusionInsight 华为云

什么?还不懂c++vector的用法,你凭什么勇气来的!

良知犹存

c++

LAXCUS 大数据集群操作系统:一个分布式分时共享 E 级系统软件(六)

陈泽云

人工智能 大数据 算法

mPaaS 客户端问题排查之漫长的 3s 等待之谜

阿里云金融线TAM SRE专家服务团队

mPaaS

三千字轻松入门TensorFlow 2

计算机与AI

tensorflow 学习

秋风到,ModelArts“ AI市场算法Fast-SCNN指南”秋膘贴起来

华为云开发者联盟

AI 算法 开发 OBS modelarts

曾陷“数据风暴”危机的赛默飞世尔如何化险为夷的?

华为云开发者联盟

数据库 大数据 云服务 华为云 RDS

WE大会上,科学家们是怎样治愈“小破球”的?

脑极体

面经手册 · 第17篇《码农会锁,ReentrantLock之AQS原理分析和实践使用》

小傅哥

Java AQS CAS unsafe CLH

架构师Week4总结

lggl

作业

护航11.11,如何筑牢安全防御系统?

京东科技开发者

云计算 云安全 DDoS

Facebook强一致性键值存储ZippyDB架构简介_语言 & 开发_Eran Stiller_InfoQ精选文章