写点什么

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:173629

评论

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

RabbitMQ怎么保证消息不被重复消费以及消息的可靠性

知识浅谈

RabbitMQ 9月月更

Qt|控件QPushButton讲解

中国好公民st

qt 按钮 9月月更

带你认识全新的华为云IoT路网数字化服务

华为云开发者联盟

云计算 后端 物联网 交通 企业号九月金秋榜

“密评”,听说过没

华为云开发者联盟

云计算 网络安全 开发 企业号九月金秋榜

如何创建 Angular library 并在生产环境中消费

汪子熙

JavaScript typescript angular library 9月月更

分布式系统中如何实现临界资源的互斥访问

华为云开发者联盟

云计算 后端 开发 企业号九月金秋榜

传媒产业的数字化怎样被小程序影响

Geek_99967b

小程序

大数据调度平台Airflow(五):Airflow使用

Lansonli

airflow 9月月更

校招 | StarRocks首次Open Day报名ING!

StarRocks

数据库

react面试如何回答才能让面试官满意

beifeng1996

React

前端如何学习算法?

大师兄

JavaScript 前端算法 9月月更

Pipy 同一 IP 多个 SSL 域名

Flomesh

Service Mesh 服务网格

来自大厂 10+ 前端面试题附答案(整理版)

loveX001

JavaScript 前端

阿里云大数据助力知衣科技打造AI服装行业核心竞争力

阿里云大数据AI技术

人工智能 大数据 模型训练 客户案例

以Vue为代表的提升小程序开发效率框架及工具

Geek_99967b

小程序

linux入门学第一天

乌龟哥哥

9月月更

写给自己的react面试题总结

beifeng1996

前端 React

羊了个羊闯关游戏开发(链改代币分红)

开发微hkkf5566

MySQL DDL执行方式-Online DDL介绍

京东科技开发者

Java MySQL 数据 ddl DML

云原生数字化转型与金融信创建设,鱼和熊掌可兼得

BoCloud博云

云计算 云原生 信创

人脸关键点的应用场景及重难点解析丨Dev for Dev 专栏

声网

算法 Dev for Dev 人工智能’

阿里前端面试题

loveX001

JavaScript 前端

火山语音7篇论文入选国际顶会Interspeech

科技热闻

最新MLPerf基准测试:基于阿里云GPU云服务器的AIACC在图像识别封闭式场景下夺冠

阿里云弹性计算

图像识别 GPU实例 AIACC

Github上标星103K的Spring Security实战手册,直接霸榜

程序知音

Java spring 程序员 spring security 后端技术

算法基础(三)| 二分图解及代码模板

timerring

算法 二分查找 9月月更

慢查询 MySQL 定位优化技巧,从10s优化到300ms

程序知音

Java MySQL 数据库 后端技术 MySQL 数据库

一文读懂Jina生态的Dataclass

Jina AI

多模态机器学习 多模态 跨模态

峰会倒计时3天!硅谷传奇投资人登陆专场,围炉共话分析型数据库的爆发式增长

StarRocks

数据库

本地服务调用K8S环境中的SpringCloud微服务实战

程序员欣宸

Kubernetes 9月月更

VS Code摸鱼神器,让你快速开发AI模型

华为云开发者联盟

人工智能 企业号九月金秋榜

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