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

by

• Eran Stiller

摘要：

Facebook工程团队最近发布了一篇博客文章，阐述了他们是如何构建其通用的键值存储的，也就是ZippyDB。ZippyDB是Facebook最大的键值存储，已经投入生产环境超过了六年的时间。它为应用程序在各个方面提供了灵活性，包括可调整的持久性、一致性、可用性以及低延迟保证等方面。

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