写点什么

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

2021 年 10 月 11 日

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

评论

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

下一个阶段,就真的容易了吗?

ke_lv

生活

一文带你搞懂RPC核心原理

松花皮蛋me

微服务 RPC 远程调用

Web3极客日报#134

谢锐 | Frozen

区块链 独立开发者 技术社区 Rebase Web3 Daily

思维偏差与产品设计的关联思考

石君

产品设计 思维方式 安全产品设计

实战营第一战:FizzBuzz

escray

学习 CSD 认证实战营

如何成为一个高效的问题解决者?

汪锋

五十年前的一桩公案:数据库关系模型的流行史(下)

青菜年糕汤

数据库 分布式数据库 数据库规范 关系型数据库 数据库设计

我看拼多多黄峥:旧世界瓦解冰消

池建强

拼多多 黄峥

架构师们必备的三三制需求分析思维模型

常平

轻轻一扫,立刻扣款,付款码背后的原理你不想知道吗?

楼下小黑哥

支付宝 微信支付 支付系统 付款码

File类的文件操作

Howe

Java File 文件 io

用 Vim 编辑 Markdown 时直接粘贴图片

mzlogin

vim markdown

源码浅析 - CocoaLumberjack 3.6 之 DDLog

Edmond

ios log4j CocoaLumberjack SourceCode DDLog

缘起:很久很久以前

escray

学习 测试驱动开发实战营

聊天机器人为什么这么难?

青菜年糕汤

人工智能 自然语言处理 搜索引擎 chatbot 聊天机器人

Web3极客日报#135

谢锐 | Frozen

区块链 独立开发者 技术社区 Rebase Web3 Daily

译文MapReduce:大型集群上的简化数据处理

海神名

mapreduce 译文 MIT 分布式计算

leetcode20.有效的括号

Damien

算法 LeetCode

五十年前的一桩公案:数据库关系模型的流行史(上)

青菜年糕汤

数据库 分布式数据库 数据库规范 关系型数据库 数据库设计

企业如何选择物联网中台

老任物联网杂谈

物联网中台 IOT Platform 物联网平台

虚拟化Pod性能比物理机还要好,原因竟然是这样!

亨利笔记

Kubernetes 容器 k8s vSphere pod

哲少荐书:这才是心理学

Jackey

心理学 读书

python中的GIL锁和互斥锁问题

半面人

Python

写在2020年五四青年节

耿老的竹林

个人成长

Java并发编程系列——线程池

孙苏勇

Java Java并发 并发编程 多线程 线程池

Netty 源码解析(五): Netty 的线程池分析

猿灯塔

游戏夜读 | 做游戏选什么专业?

game1night

我的关注清单

lmymirror

知识管理 关注清单 RSS

python oop 指南

志学Python

Python python 爬虫 oop

中台是为了复用?未必!浅谈产业中台建设的特点与误区

孤岛旭日

架构 中台 企业中台 企业架构 产业互联网

我在极客大学算法训练营的收获

熊斌

极客时间 极客大学

亚马逊云科技 Webinar 电商专场

亚马逊云科技 Webinar 电商专场

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