写点什么

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

评论

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

卧 底 人 类 高 质 量 A I 公 司

白洞计划

牛皮了!华为世界顶级Linux大牛总结出了3788页进阶笔记

Java~~~

Java Linux 架构 面试 运维

云时代,用对工具就能让云上运维工作事半功倍!

行云管家

云计算 云服务 混合云 云时代 云运维

无代码是什么?

低代码小观

无代码开发 无代码 无代码平台

华为3位大咖吐血整理出600多页Spring微服务架构设计

Java~~~

Java spring 架构 面试 微服务

安卓主板RK3288 RK3128 RK3399有哪些特点?

双赞工控

安卓主板 rk3288主板 rk3399主板 rk3128主板

MySQL到ClickHouse的高速公路-MaterializeMySQL引擎

华为云数据库小助手

sql GaussDB dba 华为云数据库 DAS

爆料!前华为微服务专家纯手打500页落地架构实战笔记,已开源

Java~~~

Java spring 架构 面试 微服务

InfoQ引航计划|合集排版规范

InfoQ写作社区官方

引航计划

瞬间登上牛客网热榜榜首!腾讯内部68W字Netty全栈宝典简直太香了

Java 编程 架构 面试 Netty

fil挖矿步骤教程是什么?fil挖矿规则是什么?

fil挖矿步骤教程是什么 fil挖矿规则是什么

脱钩!打工人都觉得香的Java程序员306道面试秘笈,爆肝

Java~~~

Java spring 架构 面试 微服务

接口管理进阶-环境变量的使用

CodeNongXiaoW

大前端 测试 后端 接口文档 接口管理

架构实战训练营模块六作业

Clarke

IM技术分享:万人群聊消息投递方案的思考和实践

JackJiang

即时通讯 IM 群聊

信息安全等级保护四级常见问题解答

行云管家

网络安全 信息安全 堡垒机 等级保护

Paxos理论介绍(1): 朴素Paxos算法理论推导与证明

OpenIM

燃炸!字节跳动成功上岸,只因刷爆LeetCode算法面试题

Java~~~

Java 架构 面试 算法 LeetCode

重磅升级!融云推出 IM+RTC+X「全」通信解决方案

融云 RongCloud

开发者 音视频 通信 即时通讯

Python代码阅读(第22篇):从源字典映射出新字典

Felix

Python 编程 Code Programing 阅读代码

阿里五位大佬总结操作系统+程序员必知硬核知识离线版pdf火了

Java~~~

Java 架构 面试 操作系统 网络

一上来就主从、集群、哨兵,这谁受得了

阿Q说代码

redis 命令 8月日更 五大基础类型

如何做好Clickhouse集群的监控覆盖?

BUG侦探

大数据 Clickhouse 监控系统

ipfs挖矿用什么app?ipfs挖矿收益计算器怎么看?

ipfs挖矿用什么app ipfs挖矿收益计算器怎么看

宇宙级计算机大佬吐血整理出2224页计算机系统文档(离线版)

Java~~~

Java 架构 面试 TCP 操作系统

InfoQ引航计划|文章排版规范

InfoQ写作社区官方

熟悉Linux tail 命令

林十二XII

漫游语音识别技术——带你走进语音识别技术的世界

声网

语音识别

低代码是什么?

低代码小观

低代码 低代码开发平台

前阿里P8狂总结出1000页Java面试核心原理+框架篇笔记

Java~~~

Java spring 架构 面试 微服务

百度智能云天工物联网支持多种类数据传输!MQTT助力数据、语音、视觉应用智能化

百度开发者中心

产品 最佳实践 前沿技术 企业资讯

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