Dropbox EB级云存储架构解析

全文概览

Dropbox作为全球领先的云存储平台，服务覆盖7亿用户，存储内容超1万亿份文件，其核心存储系统“Magic Pocket”支撑着海量数据的高可用与持久化需求。本文聚焦Dropbox如何通过键值存储、异地多活架构及仅追加写技术，构建达到4个9可用性、11个9持久性的EB级对象存储系统。系统采用分层数据模型（哈希→块→桶→卷→范围），结合跨区域复制与纠删码技术，实现数据冗余与快速恢复。

本文将深入解析其架构设计、核心组件协作机制及对存储介质（如SSD）的创新要求，为云存储与分布式系统设计提供参考。

阅读收获

1. 掌握EB级云存储系统的分层架构设计逻辑，理解键值存储与仅追加写技术的工程实践。
2. 学习通过纠删码、跨区域复制等手段实现数据高持久性（11个9）与可用性（4个9）。
3. 洞察SSD在仅追加写场景下的优化方向（如磨损均衡与垃圾回收算法）。

---

Dropbox EB级云存储架构解析-1.png

About Dropbox

Dropbox 是一款领先的云存储和协作平台，旨在帮助个人、团队和企业安全地存储、同步和共享文件。

以下是 Dropbox 的一些主要特点和功能：

• 云存储: Dropbox 提供在线存储空间，用户可以将各种类型的文件（如文档、照片、视频等）上传到云端，随时随地通过电脑、手机或平板电脑进行访问。
• 文件同步: Dropbox 能够自动同步用户在不同设备上的文件更改。这意味着当您在一台设备上修改文件后，其他设备上的相应文件也会自动更新，保持最新状态。
• 文件共享: Dropbox 使得文件共享变得简单高效。用户可以轻松地与他人共享文件或文件夹，并可以设置不同的访问权限，例如只读或编辑。这非常适合团队协作和文件传输。

图片展示了Dropbox作为一个全球协作平台的规模。截至2024年6月30日，Dropbox拥有超过7亿注册用户，其中付费用户达到1822万，平台上的内容数量超过1万亿。Dropbox在全球范围内被广泛使用，并拥有庞大的用户基础和丰富的内容存储。

Note

类似于国内的百度云盘、阿里云盘等网盘存储服务。

---

Dropbox EB级云存储架构解析-2.png

整体概况

基于异地多活架构，构建高可用分布式存储服务，底层是键值 Blob 存储系统。

该系统保证了4个9的可用性，意味着系统运行时间非常高，故障时间极短。持久性更是达到了11个9以上，表示数据丢失的可能性极低，非常可靠。

键值 Blob 存储系统 的特点是什么？为什么会在云存储架构中被应用？

一、键值Blob存储系统的特点 • 可变大小的数据、可变数量的项目、抽象引用，通过硬件实现可提高存储系统效率和性能。 • 具有快速、简单、按字节寻址等特点，市场规模大且增长迅速，AI使用场景将进一步推动其增长。

二、在云存储架构中被应用的原因 • 像Twitter、Facebook等大规模Web应用程序都构建在键值存储之上，云存储架构可借鉴这种成功应用模式。 • 其特点满足云存储需求，如可变大小和数量的数据管理，有助于应对云存储中的数据多样性和大规模性。

---

Dropbox EB级云存储架构解析-3.png

数据类型和术语

图片定义了该存储系统中使用的一些关键数据类型和术语。它解释了以下概念：

• 哈希 (Hash): 充当数据块的唯一地址。
• 块 (Block): 代表实际存储的一个数据值。
• 桶 (Bucket): 是将多个块逻辑上组合在一起形成的，并且是仅允许追加写入的。
• 卷 (Volume): 是一个或多个桶的复制集合，这意味着数据在多个桶中进行了冗余备份。
• 范围 (Extent): 指的是实际存储在磁盘上的 xGB 数据，并且由 OSD（对象块桶存储设备）进行管理。

通过这些定义，我们可以了解到该存储系统采用了一种分层的数据组织方式，从最小的数据单元“块”开始，逐步组织成“桶”和“卷”，最终通过“范围”在物理磁盘上进行存储和管理。这种结构可能旨在提高数据的可管理性、可靠性和可扩展性。

Append Only 写入对SSD设计的要求

理解“仅追加写”技术，顾名思义，就是指新的数据只能被添加到存储单元的末尾，而不能直接覆盖或修改已经存在的数据。 如果需要更新或删除数据，通常的做法是写入新的数据块来表示更新，或者通过某种机制标记旧的数据块为无效。

对 SSD 设计的新要求和考虑：

• 磨损均衡 (Wear Leveling) 的优化： SSD 的写入次数是有限的。传统的覆盖写会集中对某些区域进行擦除和写入，导致这些区域过早损坏。仅追加写虽然避免了原地覆盖，但仍然需要考虑如何有效地管理和回收空间。需要更智能的磨损均衡算法，确保所有闪存块的写入次数相对均匀，延长 SSD 的寿命。
• 垃圾回收 (Garbage Collection) 的调整： 在仅追加写的模式下，当数据需要更新时，旧的数据块会被标记为无效，但仍然占据着存储空间。因此，需要高效的垃圾回收机制来识别和回收这些无效的数据块，以便为新的写入操作腾出空间。垃圾回收的策略需要适应这种新的写入模式，避免频繁的小块擦除，提高效率并减少写入放大。
• 写入放大 (Write Amplification) 的影响： 写入放大是指实际写入到闪存芯片的数据量大于主机请求写入的数据量。虽然仅追加写避免了原地覆盖带来的额外写入，但在垃圾回收过程中，仍然可能发生数据的搬移和重写。SSD 控制器需要优化垃圾回收算法，尽量减少写入放大，提高性能和寿命。
• 逻辑地址到物理地址的映射管理： 由于数据是追加写入，逻辑地址和物理地址之间的映射关系会更加动态。SSD 控制器需要更高效地管理这种映射关系，以便快速定位数据和进行垃圾回收。
• FTL (Flash Translation Layer) 的设计： FTL 是 SSD 控制器的核心组件，负责管理闪存的读写操作、磨损均衡和垃圾回收等。仅追加写技术需要 FTL 进行相应的调整和优化，以充分发挥其优势并克服潜在的挑战。

---

拓扑与核心组件

Dropbox EB级云存储架构解析-4.png

架构拓扑

图片描述了一个分布式存储系统的拓扑结构。该结构由以下几个层级组成：

• 口袋 (Pocket): 这是最顶层的组织单元，一个口袋包含至少两个区域。这可能代表了更高层次的地理分布或者故障隔离域。
• 区域 (Zone): 一个区域包含一个或多个单元 (Cells)。区域可能代表一个数据中心或者一个可用性区域。
• 单元 (Cell): 一个单元是包含多个存储机器的逻辑分组，并且是区域内进行扩展的基本单元。这意味着当需要增加存储容量或处理能力时，可以以单元为单位进行扩展。
• 存储机器: 这是实际存储数据的物理或虚拟机器。

图片还展示了一个区域的内部结构，包含前端 (Frontends) 用于接收和处理请求，以及跨区域复制 (Cross-zone Replication) 机制，用于保证数据的冗余和高可用性。每个单元内部包含多个存储机器，并且存储着块索引 (Block Index)，用于定位存储的数据块。

---

Storage @Dropbox Scaling Magic Pocket An Exabyte Scale Object Storage System-Fig-6.png

前端

图片介绍了存储系统中的“前端 (Frontends)”组件。以下是关键信息：

• 区域级运行： 前端服务在之前提到的“区域 (Zone)”级别运行，这意味着每个区域可能都有自己的前端实例。
• 水平可扩展的无状态服务： 前端被设计成可以水平扩展的，即可以通过增加更多的前端实例来提高处理能力。同时，它们是无状态的，这意味着每个前端实例都可以独立处理请求，无需依赖之前的会话信息，这有助于提高系统的可伸缩性和可靠性。
• 唯一的公共端点： 前端是整个存储系统对外提供的唯一入口点。所有的客户端请求都必须通过前端来访问系统。
• 处理高级别 API： 前端负责处理所有用户发起的存储操作，例如数据的写入 (PUT)、读取 (GET) 和删除 (DELETE) 等高级别 API 请求。

前端在整个存储系统中扮演着至关重要的角色，它作为用户与后端存储系统的桥梁，负责接收用户的请求，并将它们转发到相应的后端服务进行处理。其水平可扩展和无状态的设计保证了系统能够应对高并发的访问压力。

---

Storage @Dropbox Scaling Magic Pocket An Exabyte Scale Object Storage System-Fig-8.png

OSD 对象存储设备

图片介绍了“OSD (对象存储设备)”，它是该存储系统中的核心数据存储组件。关键信息包括：

• 单元本地化： OSD 的作用范围限定在一个“单元 (Cell)”内部，意味着每个单元都有自己的一组 OSD。
• 基于 HDD 的存储： 每个 OSD 机器通常包含大约 100 块机械硬盘 (HDD)。这表明该存储系统的持久层主要依赖于 HDD。
• 每磁盘一个守护进程： 对于每个 HDD，都有一个独立的 OSD 守护进程在运行。这可能意味着对每个磁盘的读写和管理是独立进行的。
• 键值存储： 每个 OSD 守护进程都像一个键值存储系统，其中“键”可能是数据块的唯一标识符（例如之前提到的哈希值），而“值”就是实际的数据块。
• 块的持久层： OSD 负责将数据块持久化存储在磁盘上。
• 通过 Extents 管理块： 数据块被组织和保存在“Extents”中，Extent 是磁盘上连续的数据存储区域，由 OSD 管理。

OSD 是存储系统中负责实际数据存储和管理的组件，它以 HDD 为基础，通过每个磁盘运行一个守护进程的方式，提供了一个分布式的键值存储服务，并由 Cell 内的 Master 和 Volume Managers 进行协调管理。

---

Storage @Dropbox Scaling Magic Pocket An Exabyte Scale Object Storage System-Fig-9.png

Master 组件

图片介绍了存储系统中的“Master”组件，它在每个“单元 (Cell)”中扮演着核心的管理和协调角色。关键要点包括：

• 单元本地化且唯一： 每个单元都有且只有一个 Master 实例，其作用范围仅限于该单元内部。
• 不影响关键 I/O 路径： Master 不直接参与数据的读取和写入操作，这意味着它的运行不会对正常的业务数据访问造成性能影响。
• 单元内的中央协调器： Master 负责协调和管理单元内的各种活动，包括：
  • 健康检查、故障检测与修复： 监控单元内各个组件的健康状态，检测到故障时采取相应的修复措施。
  • 平衡 OSD： 负责在单元内的各个 OSD（对象存储设备）之间平衡数据分布，确保存储资源的有效利用和性能优化。
  • 压缩 (Compaction)： 在仅追加写的系统中，会产生许多标记为删除或过时的数据。Master 可能负责协调数据的压缩过程，回收这些无效空间。
  • 纠删码 (Erasure Coding)： 这是一种数据冗余保护技术，通过编码方式在多个存储节点上存储冗余信息，即使部分节点发生故障，数据也能恢复。Master 可能负责管理纠删码的策略和执行。
  • 等等： 表明 Master 还承担着其他一些管理和协调任务。

图片中也展示了 Master 与 OSD（存储设备）、Replication Table（复制表）以及 Volume Managers（卷管理器）之间的交互，进一步说明了其在单元内的核心协调作用。

Master 是每个单元的“大脑”，负责维护单元的健康、平衡和数据可靠性，但它并不直接处理用户的数据读写请求。

---

Dropbox EB级云存储架构解析-8.png

卷管理器 (Volume Manager)

图片介绍了存储系统中的“卷管理器 (Volume Manager)”组件。关键信息包括：

• 单元本地化且数量众多： 每个单元 (Cell) 中存在数十个卷管理器，表明卷的管理是分布式的。
• 执行 Master 指令： 卷管理器执行由 Master 组件发起的任务，这体现了 Master 的控制和协调作用。
• 纠删码操作： 卷管理器负责对卷执行纠删码相关的操作，这是一种数据冗余技术，用于提高数据的可靠性。
• 卷的合并与重组： 卷管理器能够合并和重新打包卷，这可能涉及到存储空间的优化和数据布局的调整。
• 重建丢失的范围 (OSD 故障)： 当 OSD（对象存储设备）发生故障导致数据丢失时，卷管理器负责重建丢失的数据范围 (Extent)。
• 重建读取 (GET I/O 路径)： 在数据读取过程中，如果需要，卷管理器也参与数据的重建工作，例如当部分数据由于故障不可用时。

图片中也展示了卷管理器与 Master 和底层的存储设备（OSD）之间的交互。卷管理器接收来自 Master 的指令，并直接操作底层的存储设备来完成卷的管理和数据保护任务。

卷管理器是存储系统中负责卷的生命周期管理和数据可靠性的重要组件。它们在 Master 的协调下，执行诸如纠删码、数据重建和存储优化等关键任务，确保数据的安全性和可用性。

---

Dropbox EB级云存储架构解析-9.png

块索引 & 复制表

图片介绍了存储系统中的两个关键的元数据组件：块索引 (Block Index) 和 复制表 (Replication Table)。

• 块索引 (Block Index)：
  • 作用范围： 在整个“区域 (Zone)”级别上是唯一的。
  • 实现方式： 使用分片的 MySQL 数据库，意味着这个索引可以分布在多个数据库实例上以提高性能和可扩展性。
  • 功能： 主要负责将每个数据块映射到其所在的存储桶 (Bucket)。这个映射关系包含了数据块的哈希值、所在的单元 (Cell) 和存储桶，以及一个用于数据完整性校验的校验和 (Checksum)。
• 复制表 (Replication Table)：
  • 作用范围： 每个“单元 (Cell)”都有自己的复制表。
  • 实现方式： 同样使用 MySQL 数据库，但其规模比块索引要小得多。
  • 功能： 存储关于数据复制的信息。它将存储桶 (Bucket) 映射到其所属的卷 (Volume)，并提供关于卷的更详细信息，例如存储该卷数据的 OSD（对象存储设备）、卷的打开状态、类型以及一个称为“代 (Generation)”的标识符，可能用于版本控制或数据一致性管理。

块索引用于快速定位任何给定的数据块在哪个存储桶中，而复制表则记录了存储桶与卷以及卷与实际存储数据的 OSD 之间的关系，同时还包含一些关于卷状态的元数据。这两个组件对于存储系统的数据管理、检索和保证数据可靠性至关重要。

---

Dropbox EB级云存储架构解析-10.png

XZR (跨区域复制)

图片介绍了存储系统中的“XZR (跨区域复制)”机制。关键信息包括：

• 区域级别范围： 跨区域复制的作用范围是整个“区域 (Zone)”，这意味着它负责在不同的区域之间复制数据。
• 复制到配置的远程区域： XZR 的主要功能是将数据块从一个区域复制到预先配置好的远程区域。这对于灾难恢复和提高数据可用性至关重要，因为即使一个区域发生故障，数据仍然可以在另一个区域找到。
• 复制过程： 跨区域复制的过程包括：
  • 从本地区域获取需要复制的数据块。
  • 对远程区域执行一个 PUT 操作，将该数据块写入远程区域。

图片中也展示了“跨区域复制”组件与本地区域的“前端 (Frontends)”和“块索引 (Block Index)”进行交互。这表明当数据通过前端写入本地区域后，跨区域复制机制会获取相应的数据块（可能通过块索引定位），并将其发送到远程区域进行存储。

跨区域复制是提高存储系统可靠性和容灾能力的关键机制。通过将数据复制到不同的地理区域，即使某个区域发生故障，系统仍然可以保证数据的可用性。这与之前提到的高可用性和持久性保证相呼应。

---

Dropbox EB级云存储架构解析-11.png

PUT 写入工作流

图片描述了客户端发起一个“PUT”操作（即写入数据块）时，数据在存储系统中流转的步骤：

1. 写入块 (Put block)： 客户端将数据块发送给前端 (Frontend)。
2. 检查是否存在 (Check if exists)： 前端可能会查询块索引 (Block Index) 以检查是否已经存在具有相同哈希值的块。这可能用于去重或其他优化。
3. 查找卷 (Look up volume)： 前端会查询复制表 (Replication Table) 来确定数据块应该写入哪个卷以及对应的 OSD（对象存储设备）。
4. 写入 OSD (Write to OSDs)： 前端将数据块发送给目标 OSD 进行存储。根据复制策略，可能需要写入多个 OSD。
5. 写入块映射 (Write block mapping)： 前端更新块索引，记录新写入的数据块的哈希值与它所在的单元 (Cell)、存储桶 (Bucket) 和校验和 (Checksum) 之间的映射关系。
6. 响应 (Respond)： 前端在数据成功写入 OSD 并且块索引更新完毕后，向客户端发送响应，表明写入操作已完成。

PUT 操作涉及前端协调块索引和复制表来确定存储位置，将数据写入底层的 OSD，并更新块索引以跟踪数据的位置。这是一个确保数据持久化存储和后续能够被正确检索的关键流程。

延伸思考

这次分享的内容就到这里了，或许以下几个问题，能够启发你更多的思考，欢迎留言，说说你的想法~

1. 仅追加写架构如何平衡性能与存储成本？ （提示：需权衡数据碎片化、空间回收效率与硬件寿命）
2. 若AI训练数据量呈指数级增长，Magic Pocket的扩展性是否面临瓶颈？ （提示：需分析HDD+纠删码的组合能否应对随机写密集场景）
3. 跨区域复制的同步延迟如何影响全球用户的数据一致性体验？ （提示：需探讨最终一致性模型与强一致性方案的取舍）

原文标题：Storage @Dropbox Scaling Magic Pocket An Exabyte Scale Object Storage System

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-04-04，如有侵权请联系 cloudcommunity@tencent 删除dropbox架构数据云存储存储